launchd jobs run at wrong time under OS X Yosemite - plist

Question

I have a number of launchd agents that were working fine until I upgraded to Yosemite. The jobs continue to work when run manually. The jobs do not when they're supposed but do run automatically occasionally. I don't know what triggers them to run themselves when they do, but it is not always at the same time of day and it can happen when I'm in the middle of doing something (not when I wake the computer up from sleep).
I've boiled it down to the simplest job I can think of, just an AppleScript command that displays the time the job was run (so I can tell that the time is wrong). I've pasted the plist at the bottom of this post. LaunchControl believes that the job is loaded and it shows up in launchctl list:
$ launchctl list | grep "PID\|show time"
PID Status Label
- 0 0 - tmp show time
I'm usually at my computer at the time the job is scheduled to run.
Here's the plist:
<?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>Label</key>
<string>0 - tmp show time</string>
<key>ProgramArguments</key>
<array>
<string>/usr/bin/osascript</string>
<string>-e</string>
<string>display dialog (current date) as string</string>
</array>
<key>RunAtLoad</key>
<false/>
<key>StartCalendarInterval</key>
<dict>
<key>Hour</key>
<integer>7</integer>
<key>Minute</key>
<integer>45</integer>
</dict>
</dict>
</plist>

Answer 1

I was having the same issue - it worked the day before I upgraded to Yosemite and broke the next day. Manually running still worked but the timed launch would run many hours later. I noticed a lot of these items in the logs:
2/18/15 8:05:36.000 AM kernel[0]: BUG in process suhelperd[454]: over-released legacy external boost assertions (1 total, 1 external, 0 legacy-external)
suhelperd is the software updater helper daemon
I went into System Preferences / App Store and shut off all the automatic updates.
This morning my agent ran perfectly on time again and those entries in the log were gone.

Answer 2

Potential solution
I was running LaunchControl and I noticed it displaying this warning about one of my jobs:
Program arguments contain globbing symbols but shell globbing is not supported by launchd. This might be intentional
The globbing symbols in question weren't being used for globbing; they were part of a URL: http://www.weather.com/weather/hourbyhour/graph/New+York+NY+10014:4:US?pagenum=2. Though this job has been around since before Yosemite came out, removing it seems to have virtually solved the problem, though I'm not confident that it has done so 100% yet.
Workaround
Since no one has what they know to be a complete solution, I'm leaving this workaround up:
I still don't know what's going on, but here's a somewhat unpleasant workaround. I noticed that loading and unloading broke the logjam, so added an entry to crontab to unload and then reload some launchd item. So effectively I'm using cron (which you're supposed to avoid in favor of launchd under Mac OS whenever possible) to prod launchd. I ran crontab -e and then stuck this in the file:
50 * * * * launchctl unload '/Users/kuzzooroo/Library/LaunchAgents/foo bar.plist' && launchctl load '/Users/kuzzooroo/Library/LaunchAgents/foo bar.plist'

Answer 3

I've been unable to find a reliable way to get this work purely within launchd, but here's the workaround that seems to be working for me: remove the StartCalendarInterval section from the plist, and run crontab -e to create a cron job to launch the task in question:
50 * * * * launchctl start start.example.taskName
Of course, you could just skip launchd and use cron directly to launch your job. For my particular situation, that doesn't work (I'm doing git pull based on some ssh credentials that are loaded into memory, which launchd / launchctl handles correctly but which standalone cron doesn't), but cron is great for lots of situations.

Answer 4

"cron" doesn't work if your crontab entry specifies a time when your computer is asleep. What I had to do was change my job to read a "stamp-file" that contains the date of last run. If today's date matches the stamp date, the job quits. But if different, it rewrites the stamp with today's date, and does its job. At least that way, it does its job only ONCE, but "cron" fires it up every 30 minutes. My crontab looks like this: 15,45 * * * * /Users/etc.