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 logged in 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.

   I understand the convince and elegance that you are going for,

but it might not be worth it. I am a bit prejudiced in this area as

I worked on InstaDMG for a long time, but you should be aware that

there are cases where the volume that your package is being

installed to is not the root volume, so loading Kexts automatically

should only be done with great care (a similar argument for the toolbar).

   And there are just so many variables in this area that I am not

sure that it is really worth doing. While it is brutal, and we

should aim for better, I am with Greg on this one and I think that a

reboot is the best option.

--

   Karl Kuehn

      larkost@softhome.net

I agree that this is really the best.  While I was *able* to get my daemons and agents to launch reliably, it took me several tries to get scripts correct enough that it would work for command line, ARD, and GUI installation for a local system volume only.  Rebooting in testing will also help you find problems your daemon might have after installation.  For example, StartupItems would let you create dependencies, but launchd doesn't do that.  So if you have a dependency on network being available, you might find your daemon needs to be able to determine if the network is available before doing other things. (A problem I still need to solve part of, *sigh*) Karl, do you have any tips on setting up the dev machines for this sort of package?  By this I mean, if my package rebooted my computer every time I tested it, it would increase my downtime for testing script changes.  I run the scripts individually as much as I can before running them as part of a package, but that is about it.