[launchd-dev] Starting Agents in specific GUI sessions
Quinn "The Eskimo!"
eskimo1 at apple.com
Wed Aug 21 02:29:26 PDT 2013
On 19 Aug 2013, at 14:23, Jerry Krinock <jerry at ieee.org> wrote:
> Nuskooler's issue was that his/her daemon needed to *occasionally* display GUI.
That's fine. The GUI launchd agent doesn't need to be heavyweight; you can make a tiny tool that simply listens for messages from the daemon and then launches the main GUI when necessary.
> Is the GUI launchd agent which you recommend a separate thing, in addition to the daemon, or do you mean that the daemon itself should be a GUI launchd agent?
It must be a separate process (because all the environmental context things are per-process). Whether you use the same binary as the daemon (having it do different things based on command line arguments) is purely a question of packaging. Personally I would have a separate binary (because it makes it easier to make the agent lightweight, per the previous point).
> If this GUI launchd agent is a separate thing, should it be installed at startup, or does the daemon install it when needed?
It should be installed when you install your product. It's launched by the system when a new login session is created and terminated when that login session is destroyed. This means there can be multiple instances running, for example, in the fast user switching case.
> Is there any API by which a daemon, or any program for that matter, can install another agent? In other words, is there a launchctl(2) equivalent to launchctl(1)?
That'd be launchctl(3), but I get what you mean (-:
There are limited APIs for job management in the Server Management framework, but not sufficient to replace launchctl entirely.
Also, I have to stress that not even launchctl is enough to satisfy all install, upgrade and uninstall scenarios. You can read about it in this old thread.
<https://lists.macosforge.org/pipermail/launchd-dev/2010-February/000741.html>
Over the years I've tried various workarounds for this (like the "bsexec" stuff in the afore-mentioned post) but none of them are satisfactory. Specifically, they:
o always seemed like a hack
o never worked with pre-login launchd agents
o have broken on recent systems [1]
I'll repeat the take-home message from that post:
[...] there's only one way to solve the "first install problem"
that's guaranteed to be compatible in the long term: force a restart.
> If not, is that intentional?
It definitely a matter of priorities.
Share and Enjoy
--
Quinn "The Eskimo!" <http://www.apple.com/developer/>
Apple Developer Relations, Developer Technical Support, Core OS/Hardware
[1] When 10.7 decoupled the security context from the Mach bootstrap namespace, switching instead to the audit session ID.
More information about the launchd-dev
mailing list