Greg Neagle edited this page Jul 3, 2018 · 8 revisions


Munki 3

Managed Software Center

Command-line Tools

Munki configuration




Advanced Munki

Related tasks


Product-specific notes

Legacy Documentation

Clone this wiki locally

Info on managedsoftwareupdate tool


managedsoftwareupdate is the main client tool for Munki. It runs automatically approximately every hour, or in response to events from Managed Software, but can also be manually invoked.


Usage: /usr/local/munki/managedsoftwareupdate [options]

This is the main client tool. It functions in a similar manner to Apple's softwareupdate command-line tool.


short the long command    description
-h --help Show a help message and exit
-a --auto Used by launchd LaunchAgent for scheduled runs. No user feedback or intervention. Not tested or supported with other options.
-l --logoutinstall Used by launchd LaunchAgent when running at the loginwindow.
--installwithnologout Used by Managed Software when user triggers an install without logging out.
--manualcheck Used by launchd LaunchAgent when checking manually.
-m --munkistatusoutput Provides GUI progress feedback when installing.
--id=ID Alternate identifier for manifest retrieval
-q --quiet Quiet mode. Logs messages, but nothing to stdout. --verbose is ignored if --quiet is used.
-v --verbose More verbose output. May be specified multiple times.
--checkonly Check for updates, but don't install them. This is the default behavior.
--installonly Skip checking and install any pending updates.
--applesuspkgsonly When checking for updates, check only for Apple SUS packages, skip Munki packages.
--munkipkgsonly When checking for updates, check only for Munki packages, skip Apple SUS.
-V --version Print the version of the munki tools and exit.

Commonly used options

  • --installonly Causes managedsoftwareupdate to install items it has previously downloaded
  • --version Returns managedsoftwareupdate's version information

Operation overview

Client asks for a main manifest. It's retrieved and stored locally. Main manifest contains some metadata and a list of managed installs. On the client, it's named client_manifest.plist in Munki 2 and earlier, though on the server it may have any name. Under Munki 3, the local copy of the main manifest is saved under the same name it has on the server (or technically the resource name in the GET request).

managedsoftwareupdate requests a manifest via one of three values:

  1. if you pass --id=arbitrarystring at the command line, it uses 'arbitrarystring' as the request:


  1. If no --id option is passed, it looks for a ClientIdentifier value in /Library/Preferences/ManagedInstalls.plist and uses that.

  2. If no ClientIdentifier is available, it uses the fully-qualified hostname of the machine:


If that fails, it tries the short hostname:


If that fails, it tries the machine serial number. If the serial number is "AABBCCDDEEFF"; the request looks like:


If that fails, it tries to retrieve a manifest named, literally, "site_default":


Note that if the ManifestURL takes the form of a CGI invocation (http://webserver/cgi-bin/getmanifest?), the final URLs look like:


The CGI approach opens the possibility for pattern matching and more logic in the client-to-catalog mapping. You can do server-side logic to dynamically return the appropriate manifest for a given client.

Next, the client asks for more detail on each managed install.

As we get more detail on each managed install, we may discover some dependancies, so we request more info on these as well.

We then check the items to see if they are already installed.

For items that are not installed, or have an older version, we download installer items and put them in a staging folder.

(any items previously staged that have no corresponding catalog item are removed from the staging folder - this covers the case where an item is erroneously added to a manifest and then removed before it is actually installed) Using the dependency info and the catalog items, we build a list of items to be installed and their order. (InstallInfo.plist)

Unless the --auto option is passed, after checking for and downloading updates, managedsoftwareupdate will quit. You'll need to run it a second time with --installonly to get it to install the updates. This is a safety measure to make it less likely you'll accidently install something that requires a restart underneath a logged-in user.