Running startup jobs at the wrong time under OS X Yosemite
I have several launcher agents that worked great until I switched to Yosemite. Jobs continue to run when manually started. Jobs are not performed when expected, but they are automatically started automatically. I don't know what makes them start themselves when they do this, but it's not always at the same time of day, and it can happen when I'm in the middle of something (not when I wake up the computer from sleep ).
I boiled it down to the simplest job I can think of, just an AppleScript command displaying the job time (so I can tell the time is wrong). I have pasted a plist at the bottom of this post. LaunchControl thinks the job is loaded and it appears in launchctl list
:
$ launchctl list | grep "PID\|show time"
PID Status Label
- 0 0 - tmp show time
I am usually on my computer while doing a job.
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>
source to share
Potential solution
I was running LaunchControl and I noticed this warning about one of my jobs:
The programmatic arguments contain wildcards, but the globing wrapper is not supported by launchd. It may be intentional
The globe symbols in question are not used for fitting; they were part of the URL-address: http://www.weather.com/weather/hourbyhour/graph/New+York+NY+10014:4:US?pagenum=2
. While this has been working since before Yosemite came out, removing it seems to have practically solved the problem, although I'm not sure if she did it 100%.
Bypass
Since nobody else has what is known to be a complete solution, I leave this workaround:
I still don't know what's going on, but here's a somewhat nasty workaround. I noticed that loading and unloading broke the logge, so added an entry in the crontab for unloading and then reloading some launchd item. So efficiently I use cron (which you should avoid in favor of launchd under Mac OS whenever possible) for prod launchd. I ran crontab -e
and then got stuck in a file:
50 * * * * launchctl unload '/Users/kuzzooroo/Library/LaunchAgents/foo bar.plist' && launchctl load '/Users/kuzzooroo/Library/LaunchAgents/foo bar.plist'
source to share
I had the same problem - it worked the day before I switched to Yosemite and broke down the next day. It still worked in manual mode, but the timed trigger would start many hours later. I noticed a lot of these items in the logs:
2/18/15 8: 05: 36,000 AM kernel [0]: ERROR in suhelperd process [454]: Overly released obsolete external add-ons (1 general, 1 external, 0 obsolete external)
suhelperd - software update helper daemon
I went to System Preferences / App Store and turned off all automatic updates.
My agent did a great job this morning on time and those log entries disappeared.
source to share
I haven't been able to find a reliable way to get this working within the framework launchd
, but here is a workaround that seems to work for me: remove the section StartCalendarInterval
from the plist and run crontab -e
to create a cron job to run the given task:
50 * * * * launchctl start start.example.taskName
Of course, you can just skip launchd
and use cron
to get your work started. In my specific situation, this doesn't work (I do git pull
based on some ssh credentials that are loaded into memory, which are launchd
/ are launchctl
processed correctly, but which cron
are not standalone ), but cron
great for a lot of situations.
source to share
"cron" does not work if your crontab entry specifies the time your computer sleeps. I needed to modify my work to read the "stamp file" that contains the date of the last run. If today's date matches the stamp date, the job ends. But if it is different, it rewrites the stamp with today's date and does its job. At least that way, it only does its job once, but "cron" runs it every 30 minutes. My crontab looks like this: 15.45 * * * * / Users, etc.
source to share