Periodic jobs and launchd in OS X.4

[darelon]

[Not completely sure which forum this should be in—apologies to the moderators if this is the wrong one…]

In Mac OS X.4, Apple moved the scheduling of the daily, weekly and monthly maintenance jobs from cron to the shiny new launchd system, as can be seen from /etc/crontab:# The periodic and atrun jobs have moved to launchd jobs
# See /System/Library/LaunchDaemons
#
# minute hour mday month wday who command
Unfortunately, these jobs are still running on a fixed schedule in the middle of the night as before. Many computers will usually be shutdown at that time, resulting in the periodic jobs to be skipped most or all of the time.

For those users who previously used e.g. anacron to make sure any overdue periodic jobs were run after starting or waking the system: below are a Perl script and a launchd job specification that may be used instead.

The Perl script:
#!/usr/bin/perl
#
# kick_periodic_jobs
#
# Kick off overdue daily, weekly or monthly periodic jobs
#

use Time::gmtime;
use File::stat;

$daily_logfile = "/var/log/daily.out";
$weekly_logfile = "/var/log/weekly.out";
$monthly_logfile = "/var/log/monthly.out";

# Check daily periodic job

$daily_log_age = -M $daily_logfile;
$daily_log_age = 1 if not defined $daily_log_age;

system("periodic daily") if $daily_log_age >= 1;

# Check weekly periodic job

$weekly_log_age = -M $weekly_logfile;
$weekly_log_age = 7 if not defined $weekly_log_age;

system("periodic weekly") if $weekly_log_age >= 7;

# Check monthly periodic job

$current_year = gmtime()->year;
$current_mon = gmtime()->mon;
$current_mday = gmtime()->mday;

if (-e $monthly_logfile) {
$monthly_log_year = gmtime(stat($monthly_logfile)->mtime)->year;
$monthly_log_mon = gmtime(stat($monthly_logfile)->mtime)->mon;
$monthly_log_mday = gmtime(stat($monthly_logfile)->mtime)->mday;
}
else {
$monthly_log_year = 1;
$monthly_log_mon = 1;
$monthly_log_mday = 1;
}

system("periodic monthly") if $monthly_year < $current_year && $monthly_log_mon < $current_mon && $monthly_log_mday <= $current_mday;

#EOF

You can install above script anywhere you want—I used /usr/local/bin/kick_periodic_jobs. Remember to make it executable; probably best to change the owner/group to root/wheel and set rwxr--r-- permissions.

If you save it elsewhere, also make sure to enter the correct path to the script in the ProgramArguments key in the launchd job specification.

The launchd job specification should be saved in /Library/LaunchDaemons as e.g. local.periodic.kick.plist, with owner/group set to root/wheel and rw-r--r-- as permissions:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>local.periodic.kick</string>
<key>UserName</key>
<string>root</string>
<key>ProgramArguments</key>
<array>
<string>/usr/local/bin/kick_periodic_jobs</string>
</array>
<key>StartInterval</key>
<integer>600</integer>
</dict>
</plist>

To add this to the list of jobs known by launchd:

$ sudo launchctl load <path of job plist file>

You can check the list of loaded jobs with:

$ sudo launchctl list


Hope this may be of use to some, at least as a sketch of integrating a small piece of 'old' functionality with the new launchd system.

Ciao,
Roeland.

[olealf]

Thanks for pointing that one out!

However, I read in another forum that launchd's "StartInterval" option to schedule jobs at a certain interval, does not behave like anacron. If launchd "misses" a task because the machine was shut down at the time it will NOT run the task. Anacron will.

So if this is really true, is anacron still the way to solve that problem or are there any other means?

[darelon]

In general, anacron would still be preferred to run any missed jobs. As you point out, there is no such functionality in launchd (yet).

In a specific case of e.g. the standard periodic jobs, you could also implement anacron's behaviour with launchd and a frequently run helper script. The above is just an example—you could have done the same with good old cron, but it was a nice small excercise to learn something about the new launchd functionality. :)

[hayne]

I just saw the following (from an Apple employee) on the macosx-admins mailing list:

There are a couple of problems with periodic tasks at the moment. Calendar-based periodic tasks (such as the daily, weekly and monthly scripts, and any similar launch daemons you create yourself) will, unfortunately, run only once at the scheduled time after the machine boots, and then not again until another reboot. Plus there's another issue (see below) regarding their startup possibly being delayed if your machine has been asleep. The most serious side effect of this is that the "daily" script will only one once per reboot, not every day.

So for now, adding your tasks to cron in the usual way is the way to go until this is fixed. Cron still works fine.

Until this launchd issue gets fixed, you probably want to put the periodic daily/weekly/monthly scripts back into cron the way they were in Panther, otherwise they won't run when you expect. Add this to /etc/crontab:

15 3 * * * root periodic daily
30 4 * * 6 root periodic weekly
30 5 1 * * root periodic monthly


I spoke with one of the authors of launchd about these issues- he's not on this list - and he offered this:

Yes, the calendar based periodic bug is known (4093051) and has a fix waiting to get approved for a software update. It is obviously an embarrassing bug that had just the right amount of contributing factors that lead to it being undetected before we shipped. We are sorry and we hope to adjust our development process to find bugs like this in the future. But as you have discovered, we have left cron intact, so that legacy jobs may be supported.

Modifying the plist that corresponds to cron shouldn't have been necessary. We do run cron at boot. That is what the "RunAtLoad" flag is for. I wish I could know why Jerry felt he needed to modify the plist. "It should just work."

I'm not sure what he means by a "wake event." ...but in any case, there is another bug (4058640) that he should be aware of when using either of the interval based launch mechanisms. launchd let's the kernel maintain all the timers, and as a consequence, any timer bug in the kernel, therefore affects any program that uses said mechanism (launchd included). In this case, the kernel will delay a timer from firing the amount of time that the computer is asleep. Thus, if you sleep your computer for an hour during the day, and then leave it running overnight, a job scheduled to fire at 2am will actually run at 3am. Also, please note, the drift only happens for the amount of time slept between when the timer was setup and when it goes off next. If the computer never goes to sleep thereafter, all subsequent alarms will occur at the correct time.

[darelon]

Thanks for the interesting info, Hayne. Let's hope the fixes make it into the first update.

[tjj]

It appears that this/these bugs are still unquashed in 10.4.3.
I have a single launchd item running which does not fire more than once when the startcalendarinterval is set, and, if the trigger is the startinterval, it works as designed except that waking from sleep the time my powerbook has slept is presumably added to the timer. :mad:

Anyone with other experience?

And thanks to hayne for digging out this info.

[tjj]

hrmm,
found this (http://discussions.apple.com/thread.jspa?messageID=1206539#1206539)
thread at discussions.apple.
launchd appears not to work as advertized (yet) in the man pages. This is consistent with the behavior observed here.

Happy New Year:)

[carol]

The kicker script is a neat solution. Thanks!
I would like to suggest a change in the last part of the script. That way the monthly job will run when expected.
Darelons last lines:

system("periodic monthly") if $monthly_year < $current_year && $monthly_log_mon < $current_mon && $monthly_log_mday <= $current_mday;

#EOF
My suggestion is to change this to:

$monthly_log_mon += -12 if $monthly_log_year < $current_year;
system("periodic monthly") if $monthly_log_mon < $current_mon && $monthly_log_mday <= $current_mday;

#EOF