Keep in mind that the multiple GUI logins via fast user switching is an edge case that 90% of your users will never encounter. I will take your word for it . I was of the notion that i have to support multiple users for my application. Also i had one more scenario and this is while Uninstalling . The scenario is If i install my application on One User and i log in to other User via Fast User Switching and Other user being the System Administrator (root) and Uninstall for all Users being in root ... i get these log messages
(com.mycmpny.appname) Throttling respawn: Will restart in 10 seconds. (com.mycmpny.appname) Throttling respawn: Will restart in 10 seconds. (com.mycmpny.appname) Throttling respawn: Will restart in 10 seconds. i have used the below code for removing the job from launchd su -l $userName -c "launchctl unload -S Aqua /Library/LaunchAgents/com.mycmpny.appname.plist This code works fine for normal and Admin Users though. First of all I want to ask you if it is a valid Usecase. If so how should i be removing the job form launchd. Thanks, Arjun On Thu, Jun 18, 2009 at 9:58 PM, Quinn <eskimo1@apple.com> wrote:
At 18:44 +0530 8/6/09, Arjun SM wrote:
I am getting this message when i am trying to launch my application which is a LaunchAgent. This message comes only when multiple Users are logged in.
Yeah, your script, as its written, is never going to work. The problem is that, except when run as root, launchctl finds the right launchd to talk to by looking it up in the Mach bootstrap namespace. Your script is always running in one user's namespace, so will always end up talk to that user's launchd (which ends badly because of permissions).
The launchd story is a quite weak when it comes to installing and upgrading agents where there are users logged in. This is a well known problem <rdar://problem/5476420> but, alas, I don't have any good news to share with you on this front.
This problem breaks down as follows:
o upgrade -- There /is/ a reasonable way to handle the upgrade scenario. Most agents are running on behalf of a daemon. In that case you can overwrite the agent on disk and then tell the daemon to signal all of the agents to quit. They will be relaunched by their respective launchd's, this time running the new code. You have to be a little careful, but this approach works reasonably well.
o first install -- There isn't a good way to handle the first install case. You can start the agent in the GUI context that you're running in, but starting agents in other existing GUI contexts is tricky. In general I'd recommend you /not/ try to solve this. Non-foreground GUI users will have to log out and log back in to pick up your agent. If that's a problem (for example, you're installing security software), force a restart in that case.
Keep in mind that the multiple GUI logins via fast user switching is an edge case that 90% of your users will never encounter.
S+E -- Quinn "The Eskimo!" <http://www.apple.com/developer/> Apple Developer Relations, Developer Technical Support, Core OS/Hardware
_______________________________________________ launchd-dev mailing list launchd-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/launchd-dev