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

21 views
Skip to first unread message

Jordan Calhoun

unread,
Dec 4, 2025, 12:17:30 PM (yesterday) Dec 4
to munki-dev
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

unread,
Dec 4, 2025, 12:24:53 PM (yesterday) Dec 4
to munki-dev
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

unread,
Dec 4, 2025, 12:26:13 PM (yesterday) Dec 4
to munk...@googlegroups.com
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

unread,
Dec 4, 2025, 2:22:47 PM (yesterday) Dec 4
to munk...@googlegroups.com
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.

Gregory Neagle

unread,
Dec 4, 2025, 2:29:51 PM (yesterday) Dec 4
to munki-dev
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

Jordan Calhoun

unread,
Dec 4, 2025, 3:10:16 PM (yesterday) Dec 4
to munki-dev
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

Screenshot 2025-12-04 at 2.47.23 PM.png
Screenshot 2025-12-04 at 2.06.47 PM.png
Reply all
Reply to author
Forward
0 new messages