My favorites | Sign in
Project Home Downloads Wiki Issues Source

Frequently Asked Questions
Updated Jun 25, 2014 by

Q: How do you pronounce Munki?

A: Same as "monkey."

Q: Does Munki stand for something?

A: Nope. Just a fun name that evokes "helper monkeys."

Q: What package formats does Munki support?

A: Munki supports the following formats:

  • Apple-flat packages (.pkg)
  • Apple-flat meta-packages (.mpkg)
  • Apple-non-flat packages (.pkg)*
  • Apple-non-flat meta-packages (.mpkg)*
  • Drag-and-drop disk images
  • Adobe CS3/CS4/CS5/CS6 Deployment "packages" created with Adobe's Enterprise Deployment tools - CS3 info CS4/CS5/CS6 info
  • Many Adobe CS3/CS4/CS5/CS6 product updaters
  • Adobe Acrobat Pro 9.x updater disk images as downloaded from Adobe

* Must be wrapped in a disk image file (.dmg).

Q: How does Munki determine if the correct version of an application is installed?

A: If the path to the application appears in the "installs" array, Munki will first check that path. If the application is found at the given path, its CFBundleShortVersionStrings string is checked. If it matches what's listed in the the manifest, Munki knows the correct version is installed. If the application isn't found at the given path, system_profiler is used to gather a list of all installed applications. If the application is listed with the correct version number, Munki knows the correct version is installed. If it's not listed, or it has an earlier version number, Munki knows the application must be installed. To speed up searching for applications, Munki caches the list of applications returned by system_profiler.
If there is no "installs" list, Munki relies on package receipts listed in the "receipts" array to determine installation status.
See HowMunkiDecidesWhatNeedsToBeInstalled for even more information on this topic.

Q: How often do Munki clients check for updates?

A: On average, once an hour. The exact time between checks is randomized somewhat to prevent every client from hitting the Munki server all at once. A launchd job defined at /Library/LaunchDaemons/com.googlecode.munki.managedsoftwareupdate-check.plist runs once an hour. It, in turn, calls /usr/local/munki/updatecheckhelper, which sleeps a random time between 0 and 60 minutes before checking with the server. This means that the time between any two Munki runs can vary from a few minutes to almost two hours.

Q: How is a user notified of available updates?

A: An application named "Managed Software Update", which looks very much like Apple's Software Update application, will open and display available updates. Like with Apple's Software Update, the user can then choose to install the updates now, or wait until later. Unlike with Apple's Software Update, the user cannot pick and choose among the updates. Those are managed by the Munki administrator. If any update requires a logout or restart, Managed Software Update triggers a logout before proceeding. Otherwise, the user can choose to update without logging out.

Q: What happens if the user chooses to update without logging out, but some of the updates are for applications that are currently open?

A: Munki can check for certain applications and notify the user to quit them before proceeding. See BlockingApplications for more info on this feature.

Q: What if there is no user logged in?

A: Munki will install available updates if there is no user logged in and the machine has been idle for 10 seconds or longer. A status window is displayed, and the loginwindow is hidden so that no-one can login while updates are occurring.

Q: Can Munki install Apple Software Updates?

A: Yes. See AppleSoftwareUpdatesWithMunki for more information.

Q: I keep getting 'Can't install Foo-1.0 because the integrity check failed.'

A: Most likely the disk image containing Foo-1.0 is a read/write disk image. Possible solutions:

  • Convert the disk image to read-only and reimport the item.
  • Recreate the disk image as read-only and reimport the item.
  • Configure Munki to not verify package checksums (not recommended). See the PackageVerificationMode key in

Q: I keep seeing warnings like WARNING: Could not process item Office2011_update-14.4.2 for update. No pkginfo found in catalogs: production, yet there is definitely an item named "Office2011_update-14.4.2" in the production catalog. What is happening?

A: A name followed by a hyphen and a version number (or a number!) has special meaning: it means NAME-VERSION. So Munki is actually looking for an item named "Office2011_update" with a version of "14.4.2". It is NOT looking for an item with the name "Office2011_update-14.4.2". To avoid this type of confusion, don't put versions into names. It's rarely good practice to do so. If you must, don't precede the version with a hyphen. (Any number preceded by a hyphen is likely to be interpreted as a version number.)

Q: Each time Munki runs, it wants to install the same software again. Why is this?

A: The most likely explanation is that the install has failed. On the next run, Munki sees the item is not installed, and tries again. If the item actually is installed, see the next question...

Q: Munki successfully installed some software, but now each time Munki runs, it wants to install the software again. Why is this?

A: Munki uses one of two arrays in the pkginfo to determine if an item is installed. If the "installs" array exists, each item in the array is checked; if it does not exist or the currently installed version is older than the one described in the pkginfo, Munki will attempt to install the item. If there is no "installs" array, Munki will use the "receipts" array, again installing if any receipt is missing or is an older version that that described in the pkginfo.
If Munki repeatedly presents an item for install after a successful installation, then one or more items in the "installs" array is not being installed, or one or more items in the "receipts" array is not being recorded in the receipts database. You'll need to determine what is not being installed and remove it from the installs or receipts array. (Or in the case of a receipt, mark it as "optional".) Alternately, if there is no installs array, you can often resolve this issue by adding an installs array. See HowMunkiDecidesWhatNeedsToBeInstalled for even more information on this topic.

Q: Can I deploy Mac App Store apps using Munki?

A: In most cases, yes. See App Store Apps

Q: Why does does the munkitools.mpkg/launchd.pkg require a restart? This prevents an unattended upgrade of the Munki tools!

A: It is non-trivial to load launchd jobs, especially user-level LaunchAgents, in the correct Mach context from a package postinstall script in all possible execution contexts in which a package can be installed. But more importantly, the launchd jobs control Munki itself, and so Munki could not unload and reload these jobs without killing itself during the unload. So for maximum reliability, we require a restart so we ensure the jobs are loaded in the correct context and that Munki can actually complete the task!

As for unattended updates of the Munki tools, in most cases it is possible to upgrade them without requiring a logout or restart. See UpdatingMunkiTools for additional information.

Comment by, Aug 7, 2014

Double 'does' typo?

Sign in to add a comment
Powered by Google Project Hosting