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

[Grant Erickson]

On Wed Jun 24 04:14:23 PDT 2009 Quinn <eskimo1 at apple.com> 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