Munki tools package should not require a restart about munki HOT 14 CLOSED

From [email protected] on June 01, 2010 09:49:06

For minor updates, no restart should be needed. But for major updates, it may be needed. Unfortunately, I'm not
certain we can tell when the update is major or minor because it depends on both which version is being
installed and which is currently installed.

Using launchctl to dynamically unload the launchd jobs munki requires is likely to kill the current munki session!
This is a little like changing out the engine of a flying plane...

from munki.

From [email protected] on September 15, 2010 21:45:05

So a restart isn't needed for the initial install?

from munki.

From [email protected] on September 16, 2010 11:43:38

A restart is needed even for the initial install so that all the launchd jobs get loaded. The restart might be able to be avoided with pre- and postflight scripting.

A better approach might be to separate out the munki tools into two or three packages:

1. The core munki tools in /usr/local/munki
2. The GUI tools -- currently only /Application/Utilities/Managed Software Update.app
3. The launchd plists.

#1 and #2 might be combined for simplicity.

Only a new version of #3 would require a restart. #1 and #2 could be installed without a restart, and these change far more frequently than #3. #3 also contains items more likely to be modified by the local administrator, and so, an admin might not want the installer to overwrite his or her changes.

from munki.

From [email protected] on September 16, 2010 14:31:01

So is there any chances munki would be distributed as separate packages in the future?

Referring to: http://groups.google.com/group/munki-dev/browse_thread/thread/194fa08f7427b488 It is quite easy to create your own divided distribution packages from the source, though...

from munki.

From [email protected] on September 16, 2010 14:50:17

Of course there's a chance. Here are the issues for me to resolve:

1, 2 and 3, or 1+2 and 3?

New build script/scripts to automatically build each pacakge.

Do I need a metapackage for newbies that installs everything? Or will it be OK to say: first install A, then install B?

from munki.

From [email protected] on September 17, 2010 03:39:30

I would suggest like this:

1. munki-core (items in /usr/local/munki and MSU.app)
   -these items are updated more frequently as they contain the main functionality

2. munki-launchd-essentials (LaunchAgents and LaunchDaemons except
   scheduler)
   -these items are updated not so often

3. munki-launchd-scheduler (LaunchDaemon for scheduled autoruns)
   -this file is for demo purposes only and probably people will replace it with their own type of scheduler

And you could also update your build scripts to use version number as an input argument (optional or required).

from munki.

From [email protected] on September 17, 2010 03:57:06

About the metapackaging, I would say it is not needed.
At least on my opinion, Munki is something not exactly for "newbies".
And if one really wants to know how all the necessary components interact with each other then separate pkgs would be the best way I guess.

from munki.

From [email protected] on March 07, 2011 20:04:29

Thus far I have had no problems installing Munki without a restart if I run these commands through ARD afterward...
launchctl load /Library/LaunchDaemons/com.googlecode.munki.managedsoftwareupdate-check.plist
launchctl load /Library/LaunchDaemons/com.googlecode.munki.managedsoftwareupdate-install.plist
launchctl load /Library/LaunchDaemons/com.googlecode.munki.managedsoftwareupdate-manualcheck.plist

Once those are run I'm able to use the command line tools right away with no problem.

• Trey

from munki.

From [email protected] on April 01, 2011 05:59:55

I've been thinking about this and I think I've come up with a solution

Could there be a very simple application called /usr/local/munki/munkiboostrapper that runs as a daemon every hour or so (obviously this could be configurable). If there is a file in /Library/Managed\ Installs/restart_munki with a timestamp older than the last time it remembers, it will unload all Munki daemons and then reload them (except for itself)? It will obviously have to do some sort of check to make sure munki isn't actively running at the time, but that shouldn't be too hard.

Thoughts?

from munki.

From [email protected] on April 01, 2011 08:40:38

I think the approach we will be taking is this:

munki tools will be split up into ~4 pkgs:

core tools (/usr/local/munki/managedsoftwareupdate and supporting files)
gui tools (Managed Software Update.app)
admin tools (makecatalogs, makepkginfo, munkiimport, any other admin-specific tools)
launchd files

The first three will (usually) not need a reboot when installed or upgraded.
The last (launchd_files) will need a reboot.

For convenience for new munki admins, the four pkgs will be part of a simple metapackage, which will require a restart. But experienced munki admins that want to avoid restarts (and logouts) will be able to either download the individual packages or at least extract the subpackages from the metapackage. As long as the launchd files package is not updated, munki updates should not a logout or restart.

from munki.

From [email protected] on April 01, 2011 09:26:51

I like it. I think I saw some discussion surrounding this a few weeks ago, but I wasn't sure if this was "it". I also like this method because it will be more natural for admins to deploy changes to preflight/postflight/broken_client scripts as a separate package.

Will this be handled through The Luggage makefiles?

from munki.

From [email protected] on April 01, 2011 17:20:21

Greg's approach is the only one that will work.

The reason the launchdaemons/launchagents component will always require a restart is at: http://lists.macosforge.org/pipermail/launchd-dev/2010-February/000741.html Simply, it is not possible to reload LaunchAgents in root/loginwindow context due to assumptions made when launchctl was written. No workarounds, no way to trick it with deep knowledge of Mac OS X internals, and definitely not supported.

(just documenting that certain methods are impossible - we keep revisiting the issue)

from munki.

From [email protected] on April 02, 2011 00:41:47

Will this be handled through The Luggage makefiles? https://code.google.com/p/munki/source/browse/trunk/code/tools/make_munki_mpkg.sh It currently produces an mpkg with three subpackages (/usr, /Library, /Applications), and splitting /usr into two packages (core + admin tools) is simple enough. Greg's working on a method of managing version numbers for the subcomponents.

from munki.

From [email protected] on April 25, 2011 13:16:54

This has been addressed with the metapackage; a new launchd subpackage will still require a restart, but all other subpackages, when updated, will not. The admin can deploy most munki tools updates without requiring a restart by deploying the subpackages minus the launchd subpackage.

Status: Done

from munki.