RE: [launchd-dev] launch_msg(): Socket is not connected
RE: [launchd-dev] launch_msg(): Socket is not connected
- Subject: RE: [launchd-dev] launch_msg(): Socket is not connected
- From: Grant Erickson <email@hidden>
- Date: Wed, 02 Sep 2009 12:01:00 -0700
- Organization: Nuovation System Designs, LLC
- Thread-topic: [launchd-dev] launch_msg(): Socket is not connected
On Wed Jun 24 04:14:23 PDT 2009 Quinn <email@hidden> wrote:
> At 23:31 +0530 18/6/09, Arjun SM wrote:
>> I will take your word for it . I was of the notion that i have to
>> support multiple users for my application.
>
> Well, there's a difference between supporting multiple users and
> supporting all of the edge cases brought about by multiple users. I
> totally agree that you should support multiple GUI users in general.
> However, that presents some unique install, upgrade and uninstall
> problems, and I think it's better that you solve those problems in a
> nice simple manner (forcing a restart in the multiple user case, for
> example) than do some convoluted hack that will break in mysterious
> ways in the future.
>
> But hey, Mac OS X is a very open platform so you get to choose how to
> spend your development time.
>
> And yes, we do recognise that this is a nasty wrinkle in the whole
> launchd story and we hope to fix this eventually.
It would appear that I just ran into this same problem with my preflight and
postflight scripts for my agent / preference pane package.
I solved the installer-side issue of launchctl running with root/admin
credentials as Arjun did by using sudo/su; however, from this thread, it
sounds like the:
launch_msg(): Socket is not connected
is a fatal dead end for the {pre/post}flight approach. My scripts
effectively amount to:
preflight:
if "${LaunchctlExecutable}" list | /usr/bin/grep
"${LaunchctlLabelRegex}" 2>&1 > /dev/null; then
sudo -u "${USER}" "${LaunchctlExecutable}" remove
"${LaunchctlLabel}"
fi
postflight:
if [ -r "${LaunchctlPath}" ]; then
sudo -u "${USER}" "${LaunchctlExecutable}" load -S
"${LaunchctlSession}" "${LaunchctlPath}"
fi
Has anyone had any luck setting KeepAlive to true in their job description
and then using a kqueue in their agent to monitor either its Info.plist or
the executable itself and then quit and let launchctl restart it when it
detects a version change or unlink of said files?
It seems like this would also address the multi-user case which, while rare,
still needs to be solved and is NOT addressed with the {pre,post}flight
approach.
I realize, of course, that I can set the restart flag in the package;
however, from a user experience perspective that's less than ideal and is
not entirely compatible with Sparkle (as near as I can tell).
Regards,
Grant
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Installer-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden