Re: [launchd-dev] Starting Agents in specific GUI sessions
Thanks again for your replies -- Maybe I didn't describe this well enough: - The daemon is non-graphical of course and runs with or without a login session as root. - I *do* have GUI applications (the "agents") that are to show UI. As mentioned, the "backup plan" is to use the plist system where they are registered to load at login (/Library/LaunchAgents/*.plist). This works for *most* of the cases. I know how to manually launch an application that's either registered or not *in the current session* via launchctl. The issue is launching one "in to" another specific session.
Please don't have your daemon launch an app; that's an exercise fraught with compatibility liability.
Can you elaborate here more? I know they are different worlds, but we do this on Windows without any issue. I already know and track sessions, know when a user logs in or out, etc.
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.
Again this is what I'm calling my "back up plan". It does work most of the time, but there are edge cases in which it would be extremely desirable to programmatically (from the daemon) launch said GUI agents into a users session. In the end, I think I can make this work with the /Library/LaunchAgents plists perhaps with some KeepAlive logic, but it will require quite a few works arounds in our code base, and it seems odd that there are no clean APIs to programmatically target a session and launch a GUI agent in it from a privileged (e.g. root) service/daemon. Bryan
The supported and correct way is to use a Launch Agent for what you are attempting. What you do on Windows shouldn't be applied directly on the Mac for technical and security model reasons. -Shawn On Aug 16, 2013, at 9:44 AM, NuSkooler <nuskooler@gmail.com> wrote:
Thanks again for your replies --
Maybe I didn't describe this well enough:
- The daemon is non-graphical of course and runs with or without a login session as root.
- I *do* have GUI applications (the "agents") that are to show UI. As mentioned, the "backup plan" is to use the plist system where they are registered to load at login (/Library/LaunchAgents/*.plist). This works for *most* of the cases.
I know how to manually launch an application that's either registered or not *in the current session* via launchctl. The issue is launching one "in to" another specific session.
Please don't have your daemon launch an app; that's an exercise fraught with compatibility liability.
Can you elaborate here more? I know they are different worlds, but we do this on Windows without any issue. I already know and track sessions, know when a user logs in or out, etc.
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.
Again this is what I'm calling my "back up plan". It does work most of the time, but there are edge cases in which it would be extremely desirable to programmatically (from the daemon) launch said GUI agents into a users session.
In the end, I think I can make this work with the /Library/LaunchAgents plists perhaps with some KeepAlive logic, but it will require quite a few works arounds in our code base, and it seems odd that there are no clean APIs to programmatically target a session and launch a GUI agent in it from a privileged (e.g. root) service/daemon.
Bryan _______________________________________________ launchd-dev mailing list launchd-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/launchd-dev
On Aug 16, 2013, at 9:44 AM, NuSkooler <nuskooler@gmail.com> wrote:
I *do* have GUI applications (the "agents")
I'm sure that part of the trouble here is the ambiguity which has been baked in to the documentation through history. The word "agent" in particular is a frequent sower of confusion.
On Aug 16, 2013, at 9:44 AM, NuSkooler <nuskooler@gmail.com> wrote:
I *do* have GUI applications (the "agents")
I'm sure that part of the trouble here is the ambiguity which has been baked in to the documentation through history. The word "agent" in particular is a frequent sower of confusion.
This relative up to date documentation has a decent description of what Apple means by the various terms, Agents, Daemons, Login Items etc. https://developer.apple.com/library/mac/documentation/MacOSX/Conceptual/BPSy... Kevin
On 16 Aug 2013, at 17:44, NuSkooler <nuskooler@gmail.com> wrote:
Can you elaborate here more?
Historically, folks who've attempted to do this break with every major release of the OS. Things that have broken them in the past include: o introduction of multiple users in 10.0 o introduction of fast user switching in 10.3 o introduction of launchd in 10.5 o changes to launchd session management in 10.6 o introduction of multiple GUI login sessions (via Screen Sharing) in 10.7 o security session management changes in 10.8 In contrast, the approach I've described works on 10.5 and later, and the analogous approach--which uses a login item rather than a GUI launchd agent--works on all versions of OS X (actually, as far back as System 7).
I know they are different worlds, but we do this on Windows without any issue. I already know and track sessions, know when a user logs in or out, etc.
Alas, your Windows experience will only take you so far on the Mac, and this is one of the places that things just don't match up. Share and Enjoy -- Quinn "The Eskimo!" <http://www.apple.com/developer/> Apple Developer Relations, Developer Technical Support, Core OS/Hardware
participants (5)
-
Jerry Krinock
-
Kevin Meaney
-
NuSkooler
-
Quinn "The Eskimo!"
-
Shawn Erickson