August 2013 - launchd-dev - lists.macosforge.org

Re: [launchd-dev] Starting Agents in specific GUI sessions
by NuSkooler 21 Aug '13

21 Aug '13

Thank you again for all of your replies! My current plan for OS X is to register my Agent with launchd to start at user login (e.g. once per session) and use the clean exit code members of the plist to keep it alive unless explicitly shut down cleanly (In other words, keep it alive in case it crashes; else let it exit) As I mentioned, on Windows we do spawn some "Agent" processes on demand in user(s) session spaces. I may be able to modify this slightly, but if not, from what I understand this is the appropriate approach: daemon (launchd spawned as daemon) -> {IPC} -> agent_shim (launchd spawned as login agent) -> execute real_agent (will be in users context) This seems like a fair approach, if needed. As far as questions about "asuser": In 10.8 at least, this will create a process as the user, but in the context of the launchd that launchctl talked to. The rules for this can be seen in the launchctl code, but basically if EUID or UID are root, use the root/system launchd, else use the current users's launchd. TL;DR, it doesn't allow you to change the session the process is launched in, only the user it's run as. Bryan

1 0

Re: [launchd-dev] Starting Agents in specific GUI sessions
by NuSkooler 21 Aug '13

21 Aug '13

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(a)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. > >

4 6

Re: [launchd-dev] Starting Agents in specific GUI sessions
by NuSkooler 19 Aug '13

19 Aug '13

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

5 4

Starting Agents in specific GUI sessions
by NuSkooler 16 Aug '13

16 Aug '13

I am working on a large project that includes a kernel module (that talks with the daemon), a centralized daemon (that runs as root/privileged) and agents that interact with a user logged into a graphical session. In the Windows world, when the daemon needs to show UI it simply creates a new instance of a agent in the targeted session using CreateProcessAsUser() and friends. On OS X however, this type of functionality does not seem to be present. I've found discussions around the "bsexec" option of launchctl but this appears to no longer function in 10.7+. Are there new APIs/ways of doing this? I know the session ID (derived from audit session information/etc.) but do not see away to connect the dots. I know about registering plist's in /Library/LaunchAgents in order to have the agents start at login, but there are still times in which I need to start/stop new instances of agents "on the fly" from the daemon space. Thanks, Bryan Ashby

2 1

LaunchAgent suddenly appears in Dock bouncing when CGImageSourceCopyPropertiesAtIndex is called
by Kevin Meaney 13 Aug '13

13 Aug '13

Hi all, I've got a launch agent working and communicating with it using a terminal command nicely. I'm using NSXPCConnection classes. If I call CGImageSourceCopyPropertiesAtIndex within the launchagent then the launchagent appears in the dock bouncing. Calling CGImageSourceCopyProperties doesn't cause the same issue. I have tried adding to the LaunchAgent's bundle plist the key LSUIElement with a value of YES. This doesn't change the behaviour. The LaunchAgent continues to work properly and the dictionary obtained from calling CGImageSourceCopyPropertiesAtIndex is saved to disk which is what I wanted to happen. I'm linking against frameworks Foundation and ImageIO. Any thoughts as to why? Kevin

3 6