Munki can get into a notification loop if root is using the Persian calendar

The Problem

At some point, this blog post may be obsolete, because I’m hoping this will be fixed soon, but in the meantime, I’ve filed an issue on GitHub: Using Persian calendar results in notification loop at every next Munki run

If you have users who claim to see notifications multiple times a day, even if you have DaysBetweenNotifications set to 1 or more, you may want to have them check what calendar/locale root is using.

When you select a locale, there is a default calendar that goes along with it. To see this in action, try going to System Preferences Language & Region > General. If you set the region to Asia > Afghanistan, you’ll see the calendar automatically change to Persian, and then if you set the region to Americas > United States, you’ll see the calendar automatically change to Gregorian.

At that point, if you run defaults read ~/Library/Preferences/.GlobalPreferences.plist AppleLocale, you should see en_US as a result. But if you keep the locale as United States and manually switch the calendar type to Persian, then defaults read ~/Library/Preferences/.GlobalPreferences.plist AppleLocale should return en_US@calendar=persian.

That’s just for your user account, though. Munki doesn’t care about the locale or calendar set for the user account, but if the calendar (or calendar set by the default locale) is Persian for the root account, Munki (as of this writing, but hopefully not much sooner afterwards) will get into a notification loop, and your users will either see this every hour or so:

Or, worse yet, after three days, see Managed Software Center pop up every hour or so:

A Workaround

As a workaround, you may want to verify that your users have a locale specified in /Users/username/Library/Preferences/.GlobalPreferences.plist, and then change the locale in /Library/Preferences/.GlobalPreferences.plist to one that uses Gregorian by default.

Alternatively, you can keep it at the old locale but just specify the calendar; for example: sudo defaults write /Library/Preferences/.GlobalPreferences AppleLocale "en_AF@calendar=gregorian"

Automated Workaround

Since I don’t know how long it will take to fix this issue (it may not be an easy fix), I created a nopkg that “fixes” this issue by changing the root-used locale/calendar while leaving the user-specific ones in place.


User preference should already exist

Based on my limited testing (Catalina 10.15.7 only), it appears if you create a fresh user account, that user account automatically gets its own ~/Library/Preferences/.GlobalPreferences.plist file with the AppleLocale prepopulated based on what’s in /Library/Preferences/.GlobalPreferences.plist, but it lives independently. So, in theory, if you have a single-user machine in which the user account has already been created, you might be safe in just writing directly to /Library/Preferences/.GlobalPreferences.plist without messing up the user’s ~/Library/Preferences/.GlobalPreferences.plist.

Adjusting root’s user preference doesn’t seem to make a difference

sudo defaults write /private/var/root/Library/Preferences/.GlobalPreferences AppleLocale "en_US@calendar=gregorian" doesn’t seem to override what’s in defaults read /Library/Preferences/.GlobalPreferences AppleLocale.





Leave a Reply

Your email address will not be published. Required fields are marked *