site_archiver@lists.apple.com Delivered-To: installer-dev@lists.apple.com _______________________________________________ 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

...

Yes, there are lots. As a simple example: why are you assuming that there is

...

only one person logged in, or that there is even one person loggedin to the

...

computer. Both cases are valid.

I guess i will have to ps -x | grep loginwindow and execute "launchctl

bsexec" for every instance of loginwindow? if there's no users logged

in, the loop will never be executed. Otherwise, it'll execute for

every user who's logged in (well, just like in that example on that

link).

...

We don't know exactly what you are trying to do, backing out a step or two

...

might be a really good idea. There are a lot of people on this list that can

...

probably better help you out if you give them the information they need to

...

help you.

It's an NKE Kext , which is autoloaded by a "starter"-daemon and whose

status is displayed by an agent in a status bar. After installing, i

want these daemon and agent to be launched immediately, without

reboot.

FYI: Everything I'm going to say is only based on my experience working with my program's installation, NOT anything definitive on how launchctl *ought to* behave.   My program starts a daemon and a GUI-user-only launch agent that displays any bad news from the daemon (i.e. "computer shutting down in 60 seconds, do you want to log out?"). An example of when there could be 0 users logged in is when you are installing with ARD. When working with launchctl from a script in a package, it's important to know who you are.  The package can be installed through ARD, command line, or GUI and each scenario affects who you are when the script runs.  You only get a $SUDO_USER environment variable in the IntallationCheck script (maybe VolumeCheck), you won't get it in preflight/postflight/etc. If you are installing a daemon, you will require authentication on your package.  This should make the $USER in your scripts root.  Good for starting / stopping a daemon, not good for starting an agent.  I ended up guessing who was installing the package based on the contents of $HOME and the output of 'who'. # this is some of my unload code from preinstall/preupgrade, but the load code is about the same - i had to retype it so it might not be perfectly typed. # In the postinstall, I check if the plist file got installed before even trying to load the daemons and agents. if [ ! $USER = "root" ] ; then         su $USER -c 'launchctl unload -w /Library/LaunchAgents/com.tripplite.myproject.myagent.plist ||: #don't hang else home_user=""; for user in `who | grep console | awk {'print $1'}` do         user_in_home="`echo "${HOME}" | grep $user`"         if [ -n "${user_in_home}" ] ; then     home_user=$user         fi done if [ -n "${home_user}" ] ; then         echo "Stopping MyAgent for $home_user."         su $home_user -c 'launchctl unload -w /Library/LaunchAgents/com.tripplite.myproject.myagent.plist ||: #don't hang fi fi By my experience, launchctl isn't going to let you switch user and load something for any user other than $USER or the user who started the package.  It always errored out for me if I tried to launch an agent for a user that was fast user switched or any user that hadn't run the package.  Granted, it's been since 10.6.3 since I've tried it. I get around this by not installing the package if too many GUI users are logged in, which might or might not be appropriate for you.  Depends on how important it is for your agent to be running.  It's not perfect, but it does increase the likelihood that I will not have some GUI users with agents running and some who did not get to launch the agent.  There's a race condition because I can't prevent anyone from logging in from the time that I do the check to the time that I start the agent. # I do this in InstallationCheck so that I can present an error message from InstallationCheck.strings for name in `who | grep console | awk {'print $1'}` do if [ ! $name = $USER ] ; then if [ ! $name = $SUDO_USER ] ; then exit 112 ; # Return String 16 fi fi done What I can say about the correctness of this solution is that: 1.  It works.  It has been working fine for ARD, command line, and GUI installs, tested on 10.5.8 & 10.6.3 2.  Nobody ever told me it was an unacceptable solution when I was discussing it on the list back around March. Hope this helps or was interesting.