Apple softwareupdate bug breaks aggressive notifications

160 views
Skip to first unread message

Gregory Neagle

unread,
Apr 13, 2021, 2:18:45 PM4/13/21
to munki-dev
I've been tracking an issue where machines here are not getting progressively nagged about overdue macOS updates. It turns out it's due to a bug in Apple's softwareupdate (at least in Big Sur):

bash-3.2$ softwareupdate -l --no-scan
Software Update Tool

Software Update found the following new or updated software:
* Label: macOS Big Sur 11.2.3-20D91
Title: macOS Big Sur 11.2.3, Version: 11.2.3, Size: 2383629K, Recommended: YES, Action: restart, 
bash-3.2$ softwareupdate -l --no-scan
Software Update Tool

No new software available.
bash-3.2$ softwareupdate -l --no-scan
Software Update Tool

No new software available.
bash-3.2$ softwareupdate -l --no-scan
Software Update Tool

No new software available.
bash-3.2$ softwareupdate -l --no-scan
Software Update Tool

No new software available.
bash-3.2$ softwareupdate -l --no-scan
Software Update Tool

Software Update found the following new or updated software:
* Label: macOS Big Sur 11.2.3-20D91
Title: macOS Big Sur 11.2.3, Version: 11.2.3, Size: 2383629K, Recommended: YES, Action: restart, 

These commands were issued in quick succession; it seems fairly random if softwareupdate will report the availability of this update or not.

If, when Munki runs, it decides to _not_ report the availability of the update, information about it is removed from the list of pending updates and so Munki loses track of the date it was first available. This "restarts" the counter, as it were, and so Munki never gets to the point where it notifies more aggressively.

Does anybody have any terribly bright/clever ideas for working around this issue? The only one I can think of requires the admin to track these and record their availability or due dates somewhere Munki can retrieve independently of Apple (like Apple update metadata).

-Greg

Gregory Neagle

unread,
Apr 13, 2021, 2:33:47 PM4/13/21
to munki-dev
Two more clues:

If you run `softwareupdate -l` (without --no-scan) it seems to always report the availability of the update. But without --no-scan it's much slower.

/Library/Preferences/com.apple.SoftwareUpdate.plist seems to continue to have data for the update even when softwareupdate does not:

bash-3.2$ softwareupdate -l --no-scan
Software Update Tool

No new software available.
bash-3.2$ defaults read /Library/Preferences/com.apple.SoftwareUpdate RecommendedUpdates
(
        {
        "Display Name" = "macOS Big Sur 11.2.3";
        "Display Version" = "11.2.3";
        Identifier = "MSU_UPDATE_20D91_patch_11.2.3";
        MobileSoftwareUpdate = 1;
        "Product Key" = "MSU_UPDATE_20D91_patch_11.2.3";
    }
)

The problem here is that it has been increasingly common for /Library/Preferences/com.apple.SoftwareUpdate.plist to continue to have stale data about updates that are already installed or no longer available. This is wby we switched to using info from softwareupdate -l --no-scan as (at least for a period) that appeared more accurate.

Ugh.

-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/C47B12C5-BF51-40D0-9DB1-18302EDD3A0D%40mac.com.

Nick McSpadden

unread,
Apr 13, 2021, 3:19:54 PM4/13/21
to munk...@googlegroups.com
The worst case scenario I see here is to be declarative instead, similar to Nudge / DeprecationNotifier. A minimum version is specified, and Munki will continually nag you about it even if the user can take no action (i.e. if the user ignores the update intentionally, or softwareupdate decides not to offer it, as you experienced). This essentially just incorporates Nudge's functionality into Munki.

This puts a higher burden on the admin, because it now becomes easy to prompt the user to take an action they physically cannot, so the operational cost is higher. But it means that there's no logic left to think about - either you're on the "right" version as specified by Munki preferences, or you aren't.

I'm not suggesting that this is a good idea, mind you - just that I think it's the easiest approach administratively, because it involves the least amount of guessing. 

To view this discussion on the web visit https://groups.google.com/d/msgid/munki-dev/0FBEE342-78A6-4299-8F3D-1CA427EEC168%40mac.com.


--
--
Nick McSpadden
nmcsp...@gmail.com

Gregory Neagle

unread,
Apr 13, 2021, 3:59:21 PM4/13/21
to munki-dev
On Apr 13, 2021, at 12:19 PM, Nick McSpadden <nmcsp...@gmail.com> wrote:

The worst case scenario I see here is to be declarative instead, similar to Nudge / DeprecationNotifier. A minimum version is specified, and Munki will continually nag you about it even if the user can take no action (i.e. if the user ignores the update intentionally, or softwareupdate decides not to offer it, as you experienced). This essentially just incorporates Nudge's functionality into Munki.

Which is what i was implying here:

Graham Pugh

unread,
Apr 13, 2021, 4:58:30 PM4/13/21
to munk...@googlegroups.com
How much slower is it without --no-scan? Is it totally unworkable? If so, could the scan process be decoupled from other pending tasks into its own process so that it doesn't delay other updates?

Cheers,
Graham
 

Von meinem iPhone gesendet

Am 13.04.2021 um 21:59 schrieb 'Gregory Neagle' via munki-dev <munk...@googlegroups.com>:



Gregory Neagle

unread,
Apr 13, 2021, 5:32:18 PM4/13/21
to munki-dev
How much slower depends on a variety of factors. You can test this yourself!

-Greg

Gregory Neagle

unread,
Apr 13, 2021, 5:50:48 PM4/13/21
to munki-dev
More clues pointing to a timing issue between `softwareupdate` and the MobileSoftwareUpdate.framework:

I can delete the RecommendUpdates item from com.apple.SoftwareUpdate, then do a -l --no-scan that claims no updates, then read RecommendUpdates item from com.apple.SoftwareUpdate and it comes up empty:

bash-3.2$ sudo defaults delete /Library/Preferences/com.apple.SoftwareUpdate RecommendedUpdates ; softwareupdate -l --no-scan ; sudo defaults read /Library/Preferences/com.apple.SoftwareUpdate RecommendedUpdates
Software Update Tool

No new software available.
(
)

If I wait a second and try to read the value again:

bash-3.2$ sudo defaults read /Library/Preferences/com.apple.SoftwareUpdate RecommendedUpdates
(
        {
        "Display Name" = "macOS Big Sur 11.2.3";
        "Display Version" = "11.2.3";
        Identifier = "MSU_UPDATE_20D91_patch_11.2.3";
        MobileSoftwareUpdate = 1;
        "Product Key" = "MSU_UPDATE_20D91_patch_11.2.3";
    }
)

Indeed if I just build the delay into the first attempt by adding a `sleep 1` in there:

bash-3.2$ sudo defaults delete /Library/Preferences/com.apple.SoftwareUpdate RecommendedUpdates ; softwareupdate -l --no-scan ; sleep 1 ; sudo defaults read /Library/Preferences/com.apple.SoftwareUpdate RecommendedUpdates
Software Update Tool

No new software available.
(
        {
        "Display Name" = "macOS Big Sur 11.2.3";
        "Display Version" = "11.2.3";
        Identifier = "MSU_UPDATE_20D91_patch_11.2.3";
        MobileSoftwareUpdate = 1;
        "Product Key" = "MSU_UPDATE_20D91_patch_11.2.3";
    }
)

macOS updates in Bug Sur are handled by a new (to macOS at least) mechanism -- the MobileSoftwareUpdate.framework. What appears to be happening here is that `softwareupdate` is triggering this other method to check, and not waiting long enough for its response.

-Greg


Reply all
Reply to author
Forward
0 new messages