Agent started two different was, two different bootstraps?
Hello again, I've got a persistent oddity. I have a drag-install application that automatically installs a couple of launch agents with configuration plists (in ~/Library/LaunchAgents/). The processes and my GUI Cocoa application all communicate using distributed objects via Mach ports. When the agents get installed the first time, I kick-start them using 'launchctl load ...'. The problem is this: The two launch agents are installed and started using launchctl load (running launchctl as the regular user). The Cocoa application then starts a helper process (using NSTask) which registers a named Mach port. Now at this point, I would think that all four processes should be running in the Auqa bootstrap (the Cocoa application, the agent, and the helper process). But the agent can't see/connect with the Mach port registered by the helper process. The application can see it, connect to it, and does its thing. But when one of the agents attempts to connect with the same helper process, they get an error. Here's the oddity: If I restart the computer things appear to work correctly. When they agents are started automatically as part of the user's login procedure, they all communicate with each other just fine. Am I loading the agents incorrectly? Is this a known problem, or do I have to try to develop a reproducible case and file a bug report?
-S, not -s, but otherwise, that is probably the solution. That should solve it for Leopard (until we make those directories "hot" and automagically load plists that get installed there. I make no promises and about when or if that will get implemented). davez On Jan 25, 2008, at 10:53 AM, Hamish Allan wrote:
On Jan 25, 2008 6:38 PM, James Bucanek <subscriber@gloaming.com> wrote:
I kick-start them using 'launchctl load ...'.
Using 'launchctl load -s Aqua ...'?
Hamish _______________________________________________ launchd-dev mailing list launchd-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/launchd-dev
Hamish Allan <mailto:hamish@gmail.com> wrote (Friday, January 25, 2008 11:53 AM -0000):
Using 'launchctl load -s Aqua ...'?
I wasn't specifying the session type. My logic being that all user agents should already be "locked in" to the Aqua bootstrap (in Leopard). In fact, when I tried to include LimitLoadToSessionType=Aqua in the plist, launchd ignores the plist entirely. I still can't decide if that's a bug or if I just completely misunderstand the meaning of LimitLoadToSessionType and/or the session type. Dave Zarzycki <mailto:zarzycki@apple.com> wrote (Friday, January 25, 2008 12:13 PM -0800):
-S, not -s, but otherwise, that is probably the solution.
I'll give that a try later and see what happens.
That should solve it for Leopard...
This is only for Leopard anyway. In Tiger, the agent gets installed as a login item. -- James Bucanek
On Jan 25, 2008 7:28 PM, James Bucanek <subscriber@gloaming.com> wrote:
I wasn't specifying the session type. My logic being that all user agents should already be "locked in" to the Aqua bootstrap (in Leopard).
I would also have assumed that launchctl, if not provided with a session type, would load using the "current" session type... but I already found out the hard way: http://lists.macosforge.org/pipermail/launchd-dev/2007-November/000064.html
In fact, when I tried to include LimitLoadToSessionType=Aqua in the plist, launchd ignores the plist entirely. I still can't decide if that's a bug or if I just completely misunderstand the meaning of LimitLoadToSessionType and/or the session type.
Well, TN2083 (http://developer.apple.com/technotes/tn2005/tn2083.html) states: "If you don't specify the LimitLoadToSessionType property, launchd assumes a value of Aqua." So there's definitely a bug somewhere, be it the documentation or the code... Hamish
Dave Zarzycki <mailto:zarzycki@apple.com> wrote (Friday, January 25, 2008 12:13 PM -0800):
-S, not -s, but otherwise, that is probably the solution.
Dave, Hamish, That seems to be the problem. If I load the agent using launchctl load com.qrecall.monitor.plist it doesn't work. It runs, but can't connect to any processes using Mach ports. If I unload it and reload it using launchctl load -S Aqua com.qrecall.monitor.plist it works! It connects and communicate just fine. As an experiment, I added <key>LimitLoadToSessionType</key> <string>Aqua</string> to the plist and tried to load it again, with and without specifying the sessiontype. Here's what I got: crocodile:LaunchAgents james$ launchctl load com.qrecall.monitor.plist nothing found to load crocodile:LaunchAgents james$ launchctl load -S Aqua com.qrecall.monitor.plist crocodile:LaunchAgents james$ So it appears issuing "launchctl load" as a user process is assuming some other kind of sessiontype. So I think there's definitely a bug here, although it's not the more overt bug I thought it was. 1) As Hamish pointed out, LimitLoadToSessionType defaults to Aqua. So in the absence of LimitLoadToSessionType, an agent should only be loaded in the Aqua bootstrap/sessiontype. 2) If you include the LimitLoadToSessionType=Aqua in the plist, 'launchctl load' ignores the plist with "nothing to load." I now realize that it's because the session types are different. 3) If you omit the LimitLoadToSessionType in the plist, 'launchctl load' loads the agent in whatever sessiontype it defaults to, which is in contradiction to (1). If this sounds reasonable, I'll file a bug report. In the meantime I'll add -S Aqua to my initial load command. -- James Bucanek
participants (3)
-
Dave Zarzycki
-
Hamish Allan
-
James Bucanek