[launchd-dev] launch_msg(): Socket is not connected

[Arjun SM]

>> 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 at 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 at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/launchd-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/launchd-dev/attachments/20090618/9ec76448/attachment.html>