Re: Launch agent runs as root immediately after install
site_archiver@lists.apple.com Delivered-To: installer-dev@lists.apple.com -Greg On Mar 19, 2010, at 12:30 PM, Nick Peelman wrote: Reboots and Logouts are terrible, and for what? To save the packager 5 minutes of logic? A reboot costs me 15 minutes, minimum. More depending on what i'm doing. That cost varies user to user, but its still a pain in the ass for anybody involved and reminds me too much of Windows. Macs can load (almost) everything (including kernel extensions) dynamically, and it says a lot about an application that can pop through its installer and be ready to go without a reboot; more concisely, it presents a MUCH better user experience. When VMWare got this right with Fusion 3 it made a big impact on my perception of things, and I was jaded by VMWare long ago. Xo has the right idea here; if you are concerned about the potential for multiple users, you handle those cases (via InstallationCheck) by only allowing the install to happen when one user is logged in. For a /Library/LaunchAgents this is the way it SHOULD be anyway, because you don't want to go unloading daemons or agents that may otherwise be in use, nor should you be running updates/installs and loading things for sessions that aren't yours (from the user's perspective, even if they're an admin). if (`who | grep console | wc | awk '{ print $1 }'` > 1) exit 112; Unless they change how they display the console sessions in the who command, or take away grep, wc, or awk, that's pretty bulletproof across versions, and if the install is being run by root remotely via SSH or via ARD it should fall through that without issue. launchctl logic hasn't changed *that* much between 10.5 and 10.6, for the most part load and unload work the same, the biggest change being how the -w flag is handled, and you shouldn't be using the -w flag anyway when loading/unloading. And i just want to point out that your method for starting up the process in userspace is absolutely overkill. All you need is: The bsexec is waaay nerdier, if that's what your going for, but variations of the above work for me (and many others), with lots of success. -nick -- Nick Peelman nick@peelman.us On Fri, Mar 19, 2010 at 2:50 PM, Greg Neagle <Greg.Neagle@disneyanimation.com> wrote: On Mar 19, 2010, at 11:39 AM, Greg Neagle wrote: This email sent to nick@peelman.us _______________________________________________ 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... I'm glad it works for you, but according to Apple DTS, it shouldn't, which makes me think if it does now, someday soon it won't. Apple recognizes the issues/problems here, but doesn't have any good/ clean solutions yet. If you can make this sort of thing work - that's fantastic. I, personally, wouldn't want to support all the edge cases around this, most of which can be resolved with a logout or reboot. We should continue to ask Apple for better tools to handle this "correctly', because I agree that avoiding unneeded logouts and reboots is a worthy goal. `su $USER -c 'launchctl unload /Library/LaunchAgents/ com.company.binary.plist'` Any other complicated launchctl hackery will work differently in 10.5 and 10.6, and may brake s/brake/break/ _______________________________________________ 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/nick %40peelman.us This email sent to site_archiver@lists.apple.com
participants (1)
-
Greg Neagle