On 19 Aug 2013, at 14:23, Jerry Krinock <je...@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. _______________________________________________ launchd-dev mailing list launchd-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/launchd-dev
