Re: [launchd-dev] Starting Agents in specific GUI sessions
Thanks for the reply -- Our product is a Parental Controls product. The kernel module is responsible for traffic capture that, if it's interesting is then proxied to/from the user space (running as root on *nix, system on Windows, etc.) daemon. The daemon in turn occasionally needs to display UI to users. A user may be in any graphical session on the box (e.g. Windows or OS X Fast User Switching, Screen Sharing, ...). The UI itself is more than just notifications. We allow decisions to be made by the user, prompt to login to our product in some situations, etc. The "backup plan" on OS X is to use the /Library/LaunchAgents plist system so start agents at user login. This works for most of the cases, but there are times such as in our update process that we need to stop all agents -> update them -> restart them. Hope that helps clarify, Bryan On Thu, Aug 15, 2013 at 6:35 PM, Jerry Krinock <jerry@ieee.org> wrote:
Hello, Bryan. Processes launched by agents can spawn other processes, and these other processes may be GUI processes. Processes may also install and load additional launch agents. Non-GUI processes (processes without a connection to the window server) can show rudimentary alerts using the CFUserNotification API.
Maybe we need to know a little more about what you're trying to do.
On 2013 Aug 16, at 08:33, NuSkooler <nuskooler@gmail.com> wrote:
… daemon … occasionally needs to display UI to users … more than just notifications
I would say that you should write a little app (.app) to do that, and your daemon should launch it as needed. If this is for Mac OS X 10.7 or later, you should consider XPC. Someone who knows more about XPC than I do please correct me and elaborate.
there are times such as in our update process that we need to stop all agents -> update them -> restart them
In other words, you need to do in a program what a sysadmin can do "manually" using the launchctl(1) command-line tool. I have some old code in a public repository at github.com which has methods which do this brute force, by invoking launchctl via NSTask. But before you do something like that, I vaguely recall reading somewhere that there may now be proper API for this. But I can't find any reference to it. Does anyone know of such an API in Mac OS X, or was I just dreaming? Jerry P.S. You didn't mention sandboxing. I think the install/update/start/stop LaunchAgents stuff is unlikely to be allowed if you're sandboxed.
On 16 Aug 2013, at 17:17, Jerry Krinock <jerry@ieee.org> wrote:
I would say that you should write a little app (.app) to do that, and your daemon should launch it as needed.
Please don't have your daemon launch an app; that's an exercise fraught with compatibility liability. The most straightforward solution to this problem is to install a tiny GUI launchd agent [1]. It can then communicate with the daemon, allowing the daemon to know about all the login sessions and send messages to the agent in one specific session or all sessions. If the agent needs to display GUI, it can either do so directly or launch an app to do so. It's safe for a GUI launchd agent to launch an app because it is, by definition, running in a GUI login context. Share and Enjoy -- Quinn "The Eskimo!" <http://www.apple.com/developer/> Apple Developer Relations, Developer Technical Support, Core OS/Hardware [1] I'm using the terms from Technote 2083 "Daemons and Agents", which I recommend you read. <https://developer.apple.com/library/mac/#technotes/tn2083/_index.html>
On 2013 Aug 16, at 09:24, Quinn The Eskimo! <eskimo1@apple.com> wrote:
The most straightforward solution to this problem is to install a tiny GUI launchd agent [1].
Thank you, Quinn. Nuskooler's issue was that his/her daemon needed to *occasionally* display GUI. 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? If this GUI launchd agent is a separate thing, should it be installed at startup, or does the daemon install it when needed? 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)? If not, is that intentional? Thanks, Jerry [1] https://developer.apple.com/library/mac/#technotes/tn2083/_index.html
On 19 Aug 2013, at 14:23, Jerry Krinock <jerry@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.
On 21 août 2013, at 11:29, Quinn The Eskimo! <eskimo1@apple.com> wrote:
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.
What about the "launchctl asuser" command? Seems helpful here, although it still feels kind of like a hack. Thomas
On 21 Aug 2013, at 11:25, Thomas Clement <tclementdev@gmail.com> wrote:
What about the "launchctl asuser" command?
Last I checked (which was on 10.7.x), "asuser" does not set the security context correctly. Share and Enjoy -- Quinn "The Eskimo!" <http://www.apple.com/developer/> Apple Developer Relations, Developer Technical Support, Core OS/Hardware
participants (4)
-
Jerry Krinock
-
NuSkooler
-
Quinn "The Eskimo!"
-
Thomas Clement