Everyday, iCal says my iCloud password is wrong

Here's a little more info.

This morning, when my iCal opened I get this in the log:

11/13/11 9:00:02.980 AM iCal: ServerNotifications: Setting delegate to APSD

11/13/11 9:00:03.000 AM iCal: ServerNotification: configureService called with nil password

11/13/11 9:00:03.291 AM iCal: AOSKit ERROR: Cannot refresh account bag, missing acct info (user=myaccount@mac.com, hasPassword=0)

11/13/11 9:00:03.302 AM [0x0-0x19c19c].com.apple.iCal: The operation couldn\u2019t be comple

11/13/11 9:00:03.302 AM [0x0-0x19c19c].com.apple.iCal: ted. (AOSErrorDomain error 5002.)

11/13/11 9:00:03.302 AM [0x0-0x19c19c].com.apple.iCal: (null)

11/13/11 9:00:04.388 AM iCal: Account refresh failed with error: Error Domain=CoreDAVHTTPStatusErrorDomain Code=401 "The operation couldn’t be completed. (CoreDAVHTTPStatusErrorDomain error 401.)" UserInfo=0x7feac81321a0 {CalDAVErrFromRefresh=YES, CoreDAVHTTPHeaders=<CFBasicHash 0x7fead492ee50 [0x7fff7e11ef40]>{type = immutable dict, count = 7,

entries =>

0 : Case Insensitive Key: Server = <CFString 0x7fead491d910 [0x7fff7e11ef40]>{contents = "iCloudCalendarServer 1F53"}

1 : Case Insensitive Key: Content-Type = <CFString 0x7fff7e115b60 [0x7fff7e11ef40]>{contents = "text/html"}

2 : Case Insensitive Key: X-Responding-Server = <CFString 0x7fead4931df0 [0x7fff7e11ef40]>{contents = "nk11p03me-caldav016 7"}

3 : Case Insensitive Key: X-Transaction-Id = <CFString 0x7fead491b310 [0x7fff7e11ef40]>{contents = "8c5ef1d2-0e10-11e1-a05d-984be174d6fc"}

6 : Case Insensitive Key: Date = <CFString 0x7fead494edb0 [0x7fff7e11ef40]>{contents = "Sun, 13 Nov 2011 16:00:03 GMT"}

9 : Case Insensitive Key: Www-Authenticate = <CFString 0x7fead4e29870 [0x7fff7e11ef40]>{contents = "x-mobileme-authtoken realm="MMCalDav", basic realm="MMCalDav""}

10 : Case Insensitive Key: Content-Length = <CFString 0x7fead4929160 [0x7fff7e11ef40]>{contents = "141"}

}

, AccountName=iCloud}

So, I did nothing more than quit iCal and launch it again. The second time, this appear in the log:

11/13/11 9:00:12.041 AM iCal: ServerNotifications: Setting delegate to APSD

11/13/11 9:00:12.103 AM iCal: ServerNotification: configureService called with nil password

11/13/11 9:00:12.264 AM iCal: CardDAV Account already configured for myaccount@mac.com at p03-contacts.icloud.com

11/13/11 9:00:13.528 AM iCal: Subscription request completed

11/13/11 9:00:13.535 AM iCal: Subscription request completed

I'm beginning to think this could be a sandboxing issue. I'll investigate further.

Mea culpa!

The "problem" turned out to be Lion's new security model. For years I've had iCal set up to start every morning via a simple cron job. The legacy cron tool, however, now seems to have be a bootstrap jail or some other execution environment that doesn't have access to the keychain. Thus, when iCal was launched by cron (even though I was actually going through the /usr/bin/open tool), it couldn't communicate with the keychain. This also explains why quitting iCal and starting it again would fix the problem.

I switch to using launchd directly by installing a launchd property list in ~/Library/LaunchAgents. Now iCal launches automatically without any problems. If anyone is interested in doing something similar, here's my agent plist file that opens iCal every morning at 9:01:

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">

<plist version="1.0">

<dict>

<key>StartCalendarInterval</key>

<array>

<dict>

<key>Minute</key>

<integer>1</integer>

<key>Hour</key>

<integer>9</integer>

</dict>

</array>

<key>Label</key>

<string>name.bucanek.ical</string>

<key>LimitLoadToSessionType</key>

<string>Aqua</string>

<key>ProgramArguments</key>

<array>

<string>/usr/bin/open</string>

<string>/Applications/iCal.app</string>

</array>

<key>RunAtLoad</key>

<false/>

</dict>

</plist>