Proposal: Add "Close apps and update" option to MSC

[Jordan Calhoun]

One of the largest friction points our users face is having to manually close apps before MSC can run updates.  This is particularly difficult for apps that remain running in the background (looking at your 1Password).  We often find some our users aren't sure how to fully quit some apps.

The proposal would be to add a preference to MSC that, when set, will offer to close any running apps for the user before updating.  The general flow would be as follows:

• Check for blocking apps that are running, same as MSC does today
• Alert the user of the running apps, offering a button to close the apps
• Attempt to close all apps
• Prompt the user about any apps that fail to close, and offer the choice to manually close the apps and "try again" or force quit the apps (similar to how apps like CleanMyMac might do)
• Run pending updates

I have a proof of concept working and would be happy to submit a PR for this feature if this is something you are open to adding

Thanks!

[Gregory Neagle]

Absolutely would consider a PR that implemented this: but the UI/UX must be reasonable and not lead to data loss (which generally means no force quitting).

Please see the discussion here: https://github.com/munki/munki/issues/1157

I note that you mention apps with additional background processes like 1Password. It’s not clear to me that there’s a generic mechanism to quit these — how would Munki know what additional background processes to quit?

-Greg

--
Find related discussion groups here:
https://github.com/munki/munki/wiki/Discussion-Group
---
You received this message because you are subscribed to the Google Groups "munki-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to munki-dev+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/munki-dev/9777f092-143c-4ee6-ba4e-fac43ee62365n%40googlegroups.com.

[Alan]

I like the idea in theory, because it isn't always 100% straightforward for an end user to figure out what the exact process is that they have to quit.

That said, would Munki be able to exit an app cleanly, as opposed to just brute-force killing the process?

In other words, let's say it's an app that has unsaved changes. Usually, if you quit (Cmd-Q) out of an app, the app will prompt you to save unsaved changes. If Munki just kills the prompting (even if you have to click a button in Managed Software Center to do so), would it just unceremoniously quit the program and possibly leave the user with unsaved changes (and no prompting to save)?

--

[Gregory Neagle]

As an example of the general problem around reliably and safely quitting apps:

1) Managed Software Center.app is open

2) 1Password has its menu bar item running

This Swift code:

import Foundation

import AppKit

let targetedApps = ["/Applications/1Password.app", "/Applications/Managed Software Center.app"]

let ws = NSWorkspace.shared

let runningApps = ws.runningApplications

for app in runningApps {

    if let url = app.bundleURL,

       targetedApps.contains(url.path)

    {

        if app.terminate() {

            print("Sent terminate signal to \(url.path)")

        }

    }

}

will cause Managed Software Center to quit (in most cases, anyway), but will leave the menu bar item running (and the NSApplication for /Applications/1Password.app running as well)

$ swift ~/Desktop/app_terminate_test.swift 

Sent terminate signal to /Applications/1Password.app

Sent terminate signal to /Applications/Managed Software Center.app

$ swift ~/Desktop/app_terminate_test.swift 

Sent terminate signal to /Applications/1Password.app

$ swift ~/Desktop/app_terminate_test.swift 

Sent terminate signal to /Applications/1Password.app

$ swift ~/Desktop/app_terminate_test.swift 

Sent terminate signal to /Applications/1Password.app

IOW, telling 1Password.app to terminate has no effect.

I think it will be difficult to have a generic/general-purpose method to safely quit everything — some apps will be tricky.

To view this discussion visit https://groups.google.com/d/msgid/munki-dev/13E6D008-2921-47C4-B383-11E5CAB306DB%40mac.com.

[Gregory Neagle]

if you call .forceTerminate on the app object, then the 1Password menu bar item quits and “/Applications/iPassword.app” is no longer in the list of running applications.

But calling forceTerminate on some (many?) apps could lead to data loss: forceTerminating Microsoft Word while there is an unsaved document, for example. So it can't be used “generically” in a safe manner.

-Greg

To view this discussion visit https://groups.google.com/d/msgid/munki-dev/B2F5570E-CD62-41C2-A739-C79F4B62C11A%40mac.com.

[Jordan Calhoun]

I currently have it gracefully quit the apps, if there is a dialog box preventing closing the app (say iTerm), it will then offer to force quit the app or let the user manually quit and try again.

Having a separate dialog box for force quitting could be adjusted to warn the user of potential data loss and I could set that as an additional option for admins to determine if they would like implemented.

As far as making sure all related processes are killed, i would rely on the same detections that Munki itself uses for blocking applications.  As long as those are closed then it shouldn't be a problem.  I am getting a build on a test machine now to validate 1Password behaves as expected but my initial test it worked

[Jordan Calhoun]

Quick update on this,

We have been testing it internally with my team and have seen two apps so far that don't play nicely with the terminate command as you suspected (1Password, and Docker).  The force quit logic works to trigger the apps to quit.  I have also implemented re-open logic to launch the apps again after the updates have completed.

Internally this is the flow that we have discussed for setup would be the most adaptable for admins:
1. Preference to enable auto quitting apps (disabled by default since this is the current behavior)

2. (Maybe) a preference to enable force quitting apps if quitting fails (this may not be needed depending on implementation of next items)

3. Similar to postinstall/preinstall scripts in the pkginfo, have a forceQuit script that allows for admin defined behavior to quit the app if sending a terminate doesn't work

4. (Maybe) a key in the pkginfo that specifies if the app can be forceQuit if the admin just wants the typical forceQuit behavior.

5. (Maybe) a key in the pkginfo that specifies if the app can be auto quit at all

This would allow flexibility for admins to opt-in and opt-out apps from any or all of the quitting functionality 

Let me know your thoughts!

[Jordan Calhoun]

After testing more and working on implementation, this is the flow that I have landed on that I believe would be the best for handling edge cases, and improving the experience for both admins and end users.  let me know your thoughts.  Once this is finalized I will finish implementing and submit the PR for review!

[Gregory Neagle]

In general, this looks reasonable.

Some questions and comments:

Is “*AutoClose*” the right term here? Perhaps something with the term “Quit” or “Terminate” might better express what’s happening. (I.E.: “AutoQuitBlockingApplications”?) I don’t feel strongly about this, however.

Wondering if it will be confusing to admins (especially new admins” to have a Munki preference named “AutoCloseForUpdates” _and_ a pkginfo key also named “AutoCloseForUpdates”.

How long do you wait after sending .terminate() to blocking applications before checking to see if they’ve quit? Some may quit immediately; some may take a few seconds; others may open an alert or dialog (like a file save dialog), and if the user responds to it, the app may then quit (so the quit could be many seconds or even minutes later)

As for reopening apps: since there is a need for an “application_quit_script”, might there be a need for an “application_relanch_script”? (Not everything Munki can install is technically an _application_ but since this is related to “blocking_applications” I think we can give this a pass…) I’d be interested in how you will implement relaunching the quit apps (ideally you’d do it in a way that doesn’t cause the focus to keep changing for each re-launched app)

Any new dialogs/alerts needed for this will need to be localized for all of the languages currently supported by Managed Software Center.

I’m sure I’ll have additional questions and thoughts as this develops.

-Greg

To view this discussion visit https://groups.google.com/d/msgid/munki-dev/ca5b6287-0915-49d7-8981-e5ac37aa3176n%40googlegroups.com.
<MSC Updates Flowchat.png>

[Allister Banks]

Another thing that came up in a discussion about Santa (although not exactly the same flow as explicitly presenting the user with a choice) is knowing if an app is screensharing or using the microphone or camera, like videoconference apps - not that scripts can’t handle complications like a bundled audio driver potentially needing system daemons reloaded, just that an extra ‘you sure?’ could prevent the user unwittingly having a bad experience by not taking into account what’s going on at the time.

Allister

On Jan 7, 2026, at 7:59 AM, 'Gregory Neagle' via munki-dev <munk...@googlegroups.com> wrote:



To view this discussion visit https://groups.google.com/d/msgid/munki-dev/6829419D-00C5-481B-9C91-101F1DFCCD7A%40mac.com.

[Jordan Calhoun]

Is “*AutoClose*” the right term here? Perhaps something with the term “Quit” or “Terminate” might better express what’s happening. (I.E.: “AutoQuitBlockingApplications”?) I don’t feel strongly about this, however.

I don't have strong opinions on the key names; however, AutoQuit might be more correct, so i'll go with that for now

Wondering if it will be confusing to admins (especially new admins” to have a Munki preference named “AutoCloseForUpdates” _and_ a pkginfo key also named 

“AutoCloseForUpdates”.

 For the pkginfo I can understand where a similar name might be confusing.  What about "PreventAutoQuitForUpdates" for the pkginfo (and then flip the true/false logic)

How long do you wait after sending .terminate() to blocking applications before checking to see if they’ve quit? Some may quit immediately; some may take a few seconds; others may open an alert or dialog (like a file save dialog), and if the user responds to it, the app may then quit (so the quit could be many seconds or even minutes later)

I have been experimenting a range between 5-10 seconds, which seems to be a happy middle ground.  I have some ideas on the UI side to make this more graceful, so we can come back to this point once the PR is up for testing.

As for reopening apps: since there is a need for an “application_quit_script”, might there be a need for an “application_relanch_script”? (Not everything Munki can install is technically an _application_ but since this is related to “blocking_applications” I think we can give this a pass…) I’d be interested in how you will implement relaunching the quit apps (ideally you’d do it in a way that doesn’t cause the focus to keep changing for each re-launched app)

We came to the same conclusion related to the first part.   In researching our own setup, we found anything that wasn't an "app" wasn't using blocking applications and was handled with pre/post install scripts since it didn't make sense for a user to to quit those things etc.

Currently it is just doing a regular relaunch, which will switch focus between apps.  I don't have alternative at the moment and the UX is used is other apps that have to close app(s) to preform some action, and in our testing outweighs the challenge of a user remembering what apps to re-open after updates finish. 

Any new dialogs/alerts needed for this will need to be localized for all of the languages currently supported by Managed Software Center.

Will do!

I will get started on polishing up the implementation and get a PR up for others to test with.  

Thank you the detailed review!

[Gregory Neagle]

Another thought occurred to me:

Currently it is Managed Software Center, running as the current user, that is alerting users about blocking applications.

With your proposed changes, what process is responsible for attempting to quit and relaunch apps? Is it still Managed Software Center? If so, admins will need to understand that any "application_quit_script” will _not_ run with elevated privileges (as do all the other pkginfo scripts, which are run by `managedsoftwareupdate`, running as root). Instead, the "application_quit_script” will run as the user interacting with Managed Software Center.

As for reopening apps without a bunch of focus switching, you can use `open -g` or 

https://developer.apple.com/documentation/appkit/nsworkspace/openapplication(at:configuration:completionhandler:)

with a OpenConfiguration setting “activates” to false: https://developer.apple.com/documentation/appkit/nsworkspace/openconfiguration/activates

Either of these methods will launch the app “behind” Managed Software Center and avoid the focus jumping to each newly relaunched app.

-Greg

To view this discussion visit https://groups.google.com/d/msgid/munki-dev/33f96f67-db9e-4837-a08f-a03f5ef684c6n%40googlegroups.com.

[Jordan Calhoun]

I didn't know about those options!  I will implement.  Correct, the script would run as the user.  We can come back to that (possible) limitation later if we need to once everything else is ironed out.  Here is (roughly) the UI I am working on for the feature, with each case shown as an example: