Munki controlled quitting of apps?

[John Lockwood]

Munki is designed to check for blocking apps and prompt for them to be manually quit by the user.

Sadly users are notorious for not paying attention to things like this. Munki does progress to then effectively blocking access to the rest of the Mac as way of 'encouraging' them further but again a lot of users will not know what to do. Furthermore some 'apps' actually are not straight forward apps in the dock but applets residing in the menubar which again many users cannot comprehend. (Even some 'normal' apps do not 'quit' when the last window is closed which is considered to be the standard practise on a Mac but not on Windows and some Mac developers follow the Windows standard instead.)

(As an aside disabling Microsoft Auto-Updater is a very good idea to stop it acting as a blocker.)

For other apps, particularly various menulet based apps e.g. iMazing, 1Password, possibly Tunnelblick, etc. it would be possible for an admin to write a script which could automate quitting these before Munki then does an update and then a similar script to relaunch them after Munki has completed the update. However as far as I can see there is currently no mechanism in Munki to facilitate this.

The current pre and post scripts only get triggered if there is no blocking app - duh! In this case they need to run specifically because there is a blocking app.

Note: I am not suggesting this approach be used for e.g. quitting Microsoft Word but I am opening this for discussion in relation to types of apps a user might find more confusing to deal with.

What do Greg and others think?

[Alan]

Have you explored other existing options, like having an empty blocking applications array, or using force_install_after_date?

--
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 on the web visit https://groups.google.com/d/msgid/munki-dev/653c2607-7828-4d48-a65a-5ff71ada9636n%40googlegroups.com.

[John Lockwood]

"Have you explored other existing options, like having an empty blocking applications array, or using force_install_after_date?"

Force install would not I believe result in quitting a menulet type app. However an empty blocking applications array might have possibilities.

Whilst an empty blocking array for the updater for the intended app would be useless as this does not result in quitting the app perhaps it could be combined with one of two other things. Either a pre-install script to quit the app and then run the normal updater but as you say with no blocking apps defined so the pre-install is triggered, or alternatively possibly to have two installers linked to each other. The first would be in effect a payload free one that just quits the desired app and is linked to the real unmodified updater.

[Wesley Whetstone]

I've been thinking about this recently as we have had several requests from individuals for MSC to have a "Quit and Update Apps" button. I believe this has come up in the past and the general apprehension was around not a single easy way to guarantee each app is quit. I would be curious if folks have a similar interest in a "Quit and Update Apps" button. 

I think we could make the quit action customizable for each app with additional pkginfo keys. For instance a `close_app_method` key could offer options similar to `uninstall_method` where the default option looks for the paths in blocking_application or the installs_array and runs a simple `/usr/bin/pkill -2 -f base_app_path`, or in more complex issues you can specify a `close_app_script`. Similar methods could be used to reopen the apps after being successfully updated.

I recently implemented some base login in a script that folks frequently run here to quickly update apps and get back to work. You can find mscupdate here. This method works well for those familiar with running terminal commands. A built in solution for MSC would be great for non-engineers. 

[Gregory Neagle]

On Mar 4, 2024, at 9:15 AM, John Lockwood <jeloc...@gmail.com> wrote:

 it would be possible for an admin to write a script which could automate quitting these before Munki then does an update and then a similar script to relaunch them after Munki has completed the update. However as far as I can see there is currently no mechanism in Munki to facilitate this.

Many Munki admins use preinstall_scripts and postinstall_scripts to do exactly this.

[Gregory Neagle]

On Mar 4, 2024, at 9:15 AM, John Lockwood <jeloc...@gmail.com> wrote:

What do Greg and others think?

https://github.com/munki/munki/issues/1157

[Gregory Neagle]

On Mar 4, 2024, at 9:15 AM, John Lockwood <jeloc...@gmail.com> wrote:

What do Greg and others think?

Here are the issues I see that make this non-trivial to implement in a way I would find acceptable:

What is the UI/UX? User gets a button that says “Quit, Update, and Relaunch” or similar (and frankly, wording this in an understandable way might also be a challenge). They click the button.. Now what?

MSC sends a “quit app” event to each open blocking app. How long should it wait for each app to quit? What should it do if a given app doesn’t quit? Sometimes an app will need some sort of interaction (like agree to saving a document) before it will quit. Should MSC bring each app to the front before attempting to quit it? If it doesn’t, the only indication that an app needs some interaction might be a bouncing icon in the Dock. Is this enough?

If some apps quit, but others don’t, should Munki attempt to update the items it can update? How does it communicate that to the user?

I’m sure there are more UI/UX issues to solve/make decisions about.

-Greg

[Gregory Neagle]

On Mar 4, 2024, at 9:15 AM, John Lockwood <jeloc...@gmail.com> wrote:

Furthermore some 'apps' actually are not straight forward apps in the dock but applets residing in the menubar which again many users cannot comprehend.

I don’t recommend making apps that users cannot easily figure out how to quit blocking_applications.

Better to either require a logout, or quit the process in a preinstall_script.

The first is “safer”; the second requires writing, testing and debugging at least one script (and possibly a postinstall_script to relaunch things).

https://github.com/munki/munki/wiki/Blocking-Applications#details

Even though it might be useful to block on faceless background applications (like iTunesHelper) or other processes, since normal users do not have the ability to easily quit such processes, don't use them as blocking_applications; instead specify the item needs a logout or restart as applicable. It would be confusing and frustrating for a user to be notified that installation cannot continue because "Microsoft Database Daemon" is running.

-Greg

[John Lockwood]

@Greg

I got the impression that Munki would not run the pre-install script because it saw the blocking app was running - hence the need to have a means to quit the blocking app. As I explained in these cases of particularly menulet based apps it is 'too complex' for ordinary users to know which menulet to quit and how to do this.

[Gregory Neagle]

You wouldn’t have a blocking_application in this scenario because your preinstall_script was going to handle quitting the app. 

Sent from my iPhone

On Mar 4, 2024, at 6:32 PM, John Lockwood <jeloc...@gmail.com> wrote:

@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 on the web visit https://groups.google.com/d/msgid/munki-dev/4852f996-8653-426d-81af-38164058a4fbn%40googlegroups.com.