[launchd-dev] Understanding bootstrap idea in different versions of MacOS

[Quinn "The Eskimo!"]

On 24 Jan 2011, at 18:35, eveningnick eveningnick wrote:

> Could you please explain, how to 'talk' to the right launchd and what
> is the difference in the way of 'talking' in different versions of OS
> X?

For the initial install cycle my standard hack is to use "launchctl bsexec".  This allows you to start a process in a specific bootstrap context.  So, let's say you're installing from the root context (perhaps you're a system management package that's installing its agent in response to a command received over the network), you can do the following:

1. install the agent plist in /Library/LaunchAgents

2. find all the loginwindow processes

3. exclude those running as root [1]

4. for each remaining loginwindow process, do the following

launchctl bsexec <pid> chroot -u <user> / launchctl load /Library/LaunchAgents/<plist>

The "launchctl bsexec" causes the chroot to run in the bootstrap namespace of the loginwindow whose <pid> you supply.

The chroot sets both the EUID and RUID of the "launchctl load" to the specified <uid>.  Without this the "launchctl load" runs as root and ends up talking to the global launchd.

The "launchctl load" just loads the agent into the correct context.

The issues with this approach are legion, including the following that spring immediately to mind:

o It relies on there being a loginwindow for each GUI context, and that the loginwindows EUID is the user associated with that context.

o It is subject to nasty race conditions.

o You can't target a loginwindows running at the login screen (which is fine if you're creating a GUI launchd agent, but is a serious problem if you're creating a pre-login launchd agent).

All in all, it's a horrible hack and I'd rather folks didn't use it.  Indeed, if the choice is between a) forcing a restart, and b) doing this, I'm not sure what I'd recommend.

Keep in mind that this is only necessary for the first install of your agent.  After that you should use the IPC channel between your daemon and its agents to keep everything up-to-date.

S+E
--
Quinn "The Eskimo!"                    <http://www.apple.com/developer/>
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

[1] These are loginwindow processes sitting at the login screen, and targetting that namespace is hard.