site_archiver@lists.apple.com Delivered-To: installer-dev@lists.apple.com Organization: Nuovation System Designs, LLC Thread-index: Acor/7XJFhJ3DVHpoEKZw8jRSE73UQ== Thread-topic: [launchd-dev] launch_msg(): Socket is not connected User-agent: Microsoft-Entourage/12.20.0.090605 On Wed Jun 24 04:14:23 PDT 2009 Quinn <eskimo1@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 _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.a... This email sent to site_archiver@lists.apple.com