launchd and scheduled jobs

Stewart--

I don't really have any advice for you with regard to launchd, since I just started playing around with it this morning. But cron is not disabled. It's still there, and seems to work the same. Unless you've heard somthing different...

charlie

Launchd does work well... there's just a few things you need to know when scheduling jobs.
See this link for a discusson: http://discussions.apple.com/thread.jspa?threadID=241734&tstart=0

iBook G4, iMac G5 Mac OS X (10.4.3)

Hi Stewart, I'm not sure about earlier versions, but I'm running 10.4.3 and launchd works as designed and runs your jobs immediately after waking up if yor computer has been asleep during the time they were supposed to run...
I tested this last night and the 3 jobs I had scheduled all ran when I woke up the Mac this morning.
The thing to remember when testing this stuff is not to setup a job just 5 minutes in the future as launchd seems to miss it if your using the StartCalendarInterval tag.

Hi Stewart:

I can't speak to 10.4.3, but in 10.4.2, I just rebuilt my /etc/crontab file the way I wanted it, because cron still is a part of 10.4.2, and my Mac stays on 24x7.

Looking at the "OEM" version of Tiger's crontab, it appears that what they did was basically make a crontab file full of comment lines, so I guess when cron parsed it, there was nothing there telling cron that it had to launch something.

So, if you make a bonafide crontab file, I think (in 10.4.3) you'll be okay. If you don't recall the format for the crontab file, or don't have access to an old legacy one from 10.2 or so (I never had 10.3 so don't know whether they used cron or launchd), I can post mine here, if you'd like, that you could use as a model. I'll check back sometime later this week and see if you'd like me to post it here.

Anyhow, after I made a new crontab file, I had asked on this forum how to disable the launchd daily/weekly/monthly stuff. Although it isn't important to do so, I figured, why run it more often than once daily/weekly/monthly, at what I understood would be random times of day, if the jobs would even be run at all, based on all the reports about undesired behavior caused by reboot, sleep, etc.?

Some smart person on this forum told me that I could take the three com.apple.periodic-daily/weekly/monthly.plist files and save them off somewhere else other than in /System/Library/LaunchDaemons. So I just tarballed 'em (tar -cvvvzf com.apple.periodic-\*.plist.tgz com.apple.periodic-monthly.plist com.apple.periodic-weekly.plist com.apple.periodic-daily.plist) and left the tarball right there in /System/Library/LaunchDaemons, then deleted the originals. If I ever need 'em again I can just "tar -xvvvzf com.apple.periodic-\*.plist.tgz".

So as near as I can tell, I don't even have to fuss about whether the daily/weekly/monthly jobs are being launched by launchd, and as near as I can tell, the daily/weekly/monthly jobs are being run daily, weekly, and monthly, as appropriate, and at the desired times of day, by cron and crontab.

Quicksilver G4 Mac OS X (10.4.2)

Quicksilver G4

Quicksilver G4

Actually, this (your events run when your system wakes back up) isn't entirely true.

To paraphrase a message I sent to the Darwin kernel mailing list:

While investigating while launchd(8) events (and accordingly kqueue(2) EVFILT_TIMER events) don't take time spent asleep into account, I've come upon a perplexing question.
By examination of timercallinterrupt(), it appears that the first timer interrupt that occurs after awakening from sleep should also fire all NOTE_ABSOLUTE timers that would have expired while the machine was asleep.
However, if I write a simple test program that uses kqueue(2) to sleep for five minutes, if I let the routine run for about a minute, put the machine to sleep until after the time the timer should have expired, then wake the machine back up, the timer runs for another four minutes after awakening before the timer fires (meaning the routine needs to run for a NET five minutes.)
This makes perfect sense, as the system timers are implemented using the PPC decrementer, which of course doesn't run while the system is asleep.
I thought that perhaps there wasn't a queued event that was firing earlier to "collect" the expired timers, so I set one timer for five minutes and another for one, and repeated the test. The five minute timer still took a net five minutes to fire, not five absolute minutes.
This explains why users are never seeing their "monthly" periodic scripts run; because you have to accumulate a month's worth of system runtime before the timer will fire. For users that don't reboot their systems, assuming 12 hours on and 12 hours asleep, those users would go around TWO months without the monthly periodic script being run. Reboots for system upgrades throw this all off further, as the timers are all reloaded with the time remaining until the periodic scripts should run, making the question of whether the timers will fire and when almost completely indeterministic.

a bit of a safer option, if possible, would be to:

crontab -e

as the user running the job, such that you don't have to muck about with /etc/crontab.

as for launchd, there is a nice article over at macdevcenter regarding cron, crontab, and launchd (which i think is quite nice now that it works). It covers the basics as well as old vs. new approaches to recurring tasks:

http://www.macdevcenter.com/pub/a/mac/2005/11/15/terminal5.html

cheers,
b


DP867 MDD and 12 1Ghz PB