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

[Arjun SM]

Any update for the below query ??

~Arjun

On Thu, Jun 18, 2009 at 11:31 PM, Arjun SM <arjun.sm at gmail.com> wrote:

> >> 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/20090623/57cc58cb/attachment.html>