May 2011 - launchd-dev - lists.macosforge.org

Install and load a launch daemon without a reboot
by Jeremy Reichman 20 Oct '11

20 Oct '11

What is considered the current best practice for installing and then running a launch daemon, while avoiding a reboot? I didn't see exactly what I was looking for in my list archive or found it in any documentation on installation packages. I have reviewed TN2083, specifically the "Starting a Daemon" section. That answers most of my question but it would be helpful to have confirmation. Besides the conditions listed in TN2083, I'd like my installer to behave well when installed to a disk other than the current startup volume. I need to target Mac OS X 10.5 and 10.6. It looks as if I'd need to test for the right conditions and then run launchctl to load the property list. Roughly -- not production code -- it looks like I'd need a postinstall and postupgrade script to do the following: # Test if the destination volume for the payload and the root volume path are the same if [ "$3" = "$4" ] ; then # Quick test to see if the script is run by root if [ `/usr/bin/whoami` = "root" ] ; then /bin/launchctl load "$3/Library/LaunchDaemons/com.vendor.launchdaemon.plist" fi fi exit 0 Is that the right approach? Thanks! -- Jeremy

7 22

Why no key to "Run once on restart"
by Jerry Krinock 24 May '11

24 May '11

It seems that a fairly popular trigger would be a job that runs once, when the computer is restarted or user logs in. But I don't see a key for this in launch.plist(5). To get that effect, I'm using the two keys StartOnMount + LaunchOnlyOnce. The former does the job because a filesystem must be mounted when a computer restarts, and the latter keeps it from starting multiple times in case another filesystem is mounted before it exits. This works, but is indirect and kludgey. Is there a better way to do this? The reason I want to do this is to restart a syncing task which may take a minute or so and thus could be interrupted by system shutdown. When my task begins, it loads this new "standby" StartOnMount+LaunchOnlyOnce agent to re-run the same task when the system starts up. But when my task ends normally, it unloads this agent. Therefore it only ever spawns if my task was interrupted. Thank you, Jerry Krinock

2 2

Reading WatchPaths file into Virtual Memory attempts to spawn Program
by Jerry Krinock 08 May '11

08 May '11

I discovered behavior which causes *some* of the "sleepiness" I've reported in launchd WatchPaths. [1] Consider a launchd agent which has WatchPaths. If the program indicated by its ProgramArguments *reads* one of the watched files by invoking -[NSData dataWithContentsOfFile:options:error:] with options = NSMappedRead (aka NSDataReadingMapped), this file *reading* causes launchd to immediately try and re-launch the program. Since the program is already running (I guess), it logs one of these: com.apple.launchd.peruser.501 (MyJobLabel) Throttling respawn: Will start in <N> seconds where <N> is a random number between the job's (ThrottleInterval - 60) and ThrottleInterval. [2] I don't know why I was using NSMappedRead; it was some very old code. NSMappedRead is "A hint indicating the file should be mapped into virtual memory, if possible". When I changed that option to 0, the respawn no longer occurs. This is apparently one reason why launchd's WatchPaths sometimes goes to sleep on me after the job is run; it's been throttled. But I think I've also seen WatchPaths go to sleep indefinitely when my ThrottleInterval was only 5 minutes, so there's probably more to the story. The documentation for launchd's WatchPath states "This optional key causes the job to be started if any one of the listed paths are modified." I think that the word "modified" used in the context of a file is rather vague, since there are two data forks and different kinds of metadata. Does mapping a file into virtual memory constitute "modified"? Should I file a bug on either the documentation or this behavior? Thanks, Jerry Krinock [1] http://lists.macosforge.org/pipermail/launchd-dev/2011-May/000916.html [2] One would think that the random-ness might be related to the clock seconds when the read occurs, but it is not. The "Throttling respawn" message performs as stated; the program is indeed relaunched in <N> seconds. This message seems to be logged whenever one of the WatchPaths is touched while the ProgramArguments program is running. But it is not logged if one of the WatchPaths is touched multiple times before the program is launched. Rather strange.

1 0

Agent sometimes just stops working until unloaded/reloaded
by Jerry Krinock 05 May '11

05 May '11

It's been almost a year, with no reply, and I still see the problem, so I thought I'd ask again if anyone has ever seen a randomly-occuring bad state in launchd wherein a LaunchAgent with a WatchedPath will fail silently; i.e. not run its program when the WatchedPath changes, even though the ThrottleInterval since the last run has expired. Unloading and reloading the agent immediately knocks it out of this bad state. It's still pretty much the same as I posted last year: http://lists.macosforge.org/pipermail/launchd-dev/2010-June/000774.html Additional information is that it always seems to trigger correctly at least once after loading the job. The second and third times seem to be critical; if it can make it through these, it will continue working for a long time. Also, I think maybe the job is more likely to die if the WatchedPath is changed several times during my 300-second ThrottleInterval. Any clues or suggestions to debug this would be appreciated. P.S. I sure wish there was an API whereby you could find out more about the current status of a job; i.e. information like "was triggered but is currently throttled", etc. Or if it would make a peep when triggered during the throttle interval. Sincerely, Jerry Krinock

1 0