Comments on: Taming Launchd

By: Nathaniel

Nathaniel — Mon, 01 Jan 2007 16:54:33 +0000

I’m pretty sure Launchd Editor came first. I remember using it for a while, and being really excited when Lingon came out.

By: Adam Knight

Adam Knight — Sun, 31 Dec 2006 05:43:13 +0000

For the record, Launchd Editor was first, and the idea was only to create the file correctly rather than be a complete solution. I’ve pondered doing the whole schebang at some point, however. Perhaps in ‘07 I’ll make a second, more full version that does those things.

By: Paul Kim

Paul Kim — Sun, 31 Dec 2006 04:12:04 +0000

Thanks for the mention though the irony of using me as the poster boy for launchd is that I am currently considering ditching it. The problem? Well, one thing that is mentioned in the tech note that Mark posted above is that after logout, the user context is disabled. It wasn’t immediately obvious to me but after talking to Apple support, the user’s launchd and everything it launches runs in this context and when the user re-logs in. The side effect is that none of these processes are able to get rights to any mach ports. While Hazel does not create any ports directly, it ends up using Launch Services and other subsystems that need mach ports so it throws all sorts of errors in this situation.

There’s a good chance I will have to write my own daemon and stop using launchd which is too bad since it’s works well for my needs. While there’s a chance it will be fixed in Leopard, I imagine a good percentage of my users will be on Tiger for some time. It’s unfortunate since the new daemon would be another moving part that I would have to write and maintain but them’s the breaks.

Oh, and to Tom’s point about polling: Hazel does poll as well. Certain conditions are time based and so having rules run only when a change in the folder occurs is not sufficient. This is also why, among other reasons, Folder Actions (which Hazel gets compared to now and then) are not a suitable replacement for Hazel since if there’s no activity in the folder, time based rules will not get run.

By: Tom Harrington

Tom Harrington — Sat, 30 Dec 2006 23:48:01 +0000

When considering launchd one should beware that per-user agents (those whose plists reside in one of the LaunchAgents folders) are in many cases much less useful than one might expect.

If you set up a LaunchAgents entry, launchd will start the process when the user logs in. If it’s a persistent process– one which starts up and keeps running instead of one that starts up, does some work, and exits– then launchd will stop it (via SIGTERM) when they log out.

That actually works OK, as far as described. However launchd doesn’t quite clean things up normally on log-out. The upshot is that if you log in, log out, and then back in, your LaunchAgents entries will not start up on the second login (or any subsequent logins).

I had originally intended to use launchd with MondoMouse, but on discovering this limitation (confirmed by Apple engineers) I had to abandon the plan and go with a login item instead (and thanks to Uli for his sample code that made this easier). Paul Kim was able to use launchd with Hazel because Hazel’s launchd-started jobs are not persistent– they start up, do something useful, and then start

Also for what it’s worth– unless I’m very much mistaken, Hazel’s launchd usage doesn’t involve any sort of polling-like behavior to check watched folders. I’m pretty sure launchd makes use of Mac OS X (BSD’s really) kqueue system to receive notifications of filesystem changes without the need for regular checking.

By: Mark Dalrymple

Mark Dalrymple — Sat, 30 Dec 2006 23:19:45 +0000

Beware, launchd is pretty broken in Tiger, especially for per-user agents. Sometimes they’ll start in the wrong context (like if you ssh into a machine - see tn2083), sometimes they won’t shut down properly, and keep running (and re-launching) after you log out. Plus there are race conditions if you’re using watchPaths or queueDirectories. If you stay running, you won’t get any additional notifications, even if you use ServiceIPC, so you end up using kqueue() to watch the things that launchd is watching, Just In Case. Also some of the launchd API is wishful thinking, and isn’t actually implemented. (see Launchd and domain sockets)

Also watch out for launchd editor if you use unix domain sockets, it’ll corrupt your plist file. My bug report is still sitting there. I’ve since abandoned launchd and launchd editor for what I was originally intending to use it.