gui vs cli behaviour

[Philip Powell]

Occasionally a co worker will report that their Managed Software Centre is stuck in a loop. Running sudo managedsoftwareupdate && sudo managedsoftwareupdate --installonly completes successfully with no errors or warnings.

More recently an install with a custom "installs" array in its pkginfo will fail with the error "the App is in use by another user". I've tried adding a preinstall script to kill those processes but the script never runs. It looks like the Managed Software Centre is running its own check before handing off to the managedsoftwareupdate process.
In this case running managedsoftwareupdate && managedsoftwareupdate --installonly manually also completes successfully with no errors or warnings.

Any idea what might be causing this? Would it be possible to somehow align the GUI behaviour with the cli, or do we have something configured wrong?
We're on v7.0.5, macOs 15 & 26

Cheers

Phil

[Alan]

This is expected behavior. From https://github.com/munki/munki/wiki/managedsoftwareupdate

--installonly Skip checking and install any pending updates. No safety checks.

There are no safety checks when you use the --installonly flag.

If you're certain that killing the app won't cause any problems for any of your users, you might want to consider using an empty installs array. From https://github.com/munki/munki/wiki/Blocking-Applications#blocking_applications-vs-installs :

If there is no blocking_applications array, and there is an installs array containing one or more applications, Munki will use those applications as a substitute blocking_applications array. This can be convenient, as Munki can "automagically" discover blocking applications for drag-n-drop dmg installs. If you need to override this behavior, simply create an actual blocking_applications array listing the actual applications you want to block an install. If you want NO applications to block an install, provide an empty blocking_applications array.

--
You received this message because you are subscribed to the Google Groups "munki-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to munki-discus...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/munki-discuss/9fe916e7-9625-4474-adde-83e917bf86d2n%40googlegroups.com.

[Gregory Neagle]

On Jan 12, 2026, at 6:31 AM, Philip Powell <pkpo...@gmail.com> wrote:

Occasionally a co worker will report that their Managed Software Centre is stuck in a loop. Running sudo managedsoftwareupdate && sudo managedsoftwareupdate --installonly completes successfully with no errors or warnings.

More recently an install with a custom "installs" array in its pkginfo will fail with the error "the App is in use by another user". I've tried adding a preinstall script to kill those processes but the script never runs. It looks like the Managed Software Centre is running its own check before handing off to the managedsoftwareupdate process.

Yes, it is. It is checking for blocking_applications.

In this case running managedsoftwareupdate && managedsoftwareupdate --installonly manually also completes successfully with no errors or warnings.

`managedsoftwareupdate —installonly` skips all safety checks. It does not check for blocking_applications and will happily update an application that is in use with unsaved data. It will also happily install an item that requires a restart, and not actually trigger a restart. You should not really be using this option without understanding the implications.

$ managedsoftwareupdate -h

USAGE: mangedsoftwareupdate [options]

COMMONLY USED OPTIONS:

  -v, --verbose           More verbose output. May be specified multiple times.

  --checkonly             Check for updates, but don't install them. This is the default behavior when no other options are specified.

  --installonly           Skip checking and install all pending updates. No safety checks.

<snip>

Any idea what might be causing this?

Explained above.

Would it be possible to somehow align the GUI behaviour with the cli, or do we have something configured wrong?

I think this is more a misunderstanding of what is happening, and why.

If you don’t want to have blocking_applications for an item, provide an emply blocking_applications array. You can then do any pre-install process killing in a preinstall_script if needed.