Munki2 Warning

[zack.m...@bsd7.org]

Added the OS X Yosemite 10.10.2 update to Munki yesterday. After it was run through MSU users reported popup "SecurityAgent not found. This action only authorized by Apple" multiple times. Only way to fix was force shutdown and restart. I followed instructions exactly and never added it to any manifests. I added a force install date key but that was all. Just a warning for this update. 

Any light shed on what I did wrong would be sweet, knowing me I messed up somewhere along the way.

[Clay Caviness]

We're seeing the same thing here as well. App store updates seem to be fine.

[Predrag Stojanovic]

Error not related to Munki (or anything you did).  Could be a bad HDD cable...

On Wednesday, January 28, 2015 at 11:21:51 AM UTC-5, zack.m...@bsd7.org wrote:

[Gregory Neagle]

Google Groups marked your post as spam, Clay. The irony...

-Greg

--
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.
For more options, visit https://groups.google.com/d/optout.

[Nate]

I've seen this error on a 10.9.5 and a 10.10.2 machine in the last 24 hours. Not sure what it is related to yet.

See: https://www.dropbox.com/s/eknel4nqku5wj94/Screenshot%202015-01-28%2007.52.29.png?dl=0

[Gregory Neagle]

Google finds lots of mentions of this message (going back a year or two) with several suspicious "fixes" but no clear cause or trigger (IMHO)

[Jason Hueske]

Funny, just five minutes ago I was on a user’s machine (10.10.2, 2.1.1.2352) to help them out with MS Word being stuck in a “modal state” after they attempted to save. Document could scroll and you could still switch windows but all menu items greyed out, ultimately had to force quit. I opened Activity Monitor and their softwareupdated process was not responding, but also not using CPU. When I tried soft-quitting softwareupdated via Activity Monitor, I got that exact SecurityAgent error. So, possibly something to do with softwareupdated?

I sure hope that modal error in Word wasn’t related. Never seen that error in my environment before either.

[zack.m...@bsd7.org]

Ya I've recently found out that it seems to be related to Time Machine or a /var/ folder. We had a couple users update no problem via app store, but so far the 10 users who have used MSU (still trying to enforce DON'T use the dang app store) had this error pop up. Just coincidence I suppose.

[Edward Eigerman]

We're seeing this very consistently on all updates through Munki and not at all on updates from any other source. We're guessing it's because this update contains a firmware update as well as the software updates. Not that that is a solution.

Ed

--

[Gregory Neagle]

So questions:

1) Does any one have a machine or group of machines on which they can reliably reproduce this issue?

2) Has anyone seen this issue in a VM?

3) On machines with this issue, what steps (if any) cause the issue to go away?

4) If there is a successful method of remedying the issue, what (if anything) have you tried to automate a fix or workaround?

5) Any ideas or guesses to the root cause or trigger?  I've only tested on a VM, and VMs would not get the firmware update, so Ed's guess is consistent with that.

-Greg

[Craig Lindsey]

Hi All,

This has come up for me on a few machines over the last year. Deleting the contents of /var/Folders/ resolves the issue. 

https://discussions.apple.com/thread/5600203

Lots of guessing and complaining in the discussions post but the solution is there and I remember finding the same fix elsewhere.

— Craig

[Mike Solin]

When we had the 10.10.2 beta on a few test machines, I noticed that new seed installations didn’t trigger a reboot.  I had set InstallAppleSoftwareUpdates to true, and SoftwareUpdateServerURL to the URL from the Yosemite seed configuration utility.  As Apple released new seeds, Munki would install them at the login window, but the machine wouldn’t reboot.  Upon trying to login (with either an AD account or a local account), you’d see the same error message about SecurityAgent.  Rebooting the machine fixed the problem every time.

Are you sure the 10.10.2 update is rebooting after installation?  I haven’t tested adding a pkginfo file for the OS X update, as we’re not forcing installs yet.

Mike

-- 

mi...@mikesolin.com / @flammable
http://mikesolin.com

[Gregory Neagle]

Restarts should be required; from the dist:

<pkg-ref id="delta" auth="Root" packageIdentifier="com.apple.pkg.update.os.10.10.2.14C109.delta" onConclusion="RequireRestart">OSXUpd10.10.2.pkg</pkg-ref>

<pkg-ref id="delta-patch" auth="Root" packageIdentifier="com.apple.pkg.update.os.10.10.2.14C109.delta" onConclusion="RequireRestart">OSXUpd10.10.2Patch.pkg</pkg-ref>

and 

<pkg-ref id="combo" auth="Root" packageIdentifier="com.apple.pkg.update.os.10.10.2.14C109.combo" onConclusion="RequireRestart">OSXUpdCombo10.10.2.pkg</pkg-ref>

But please verify in your logs.

-Greg

[Jason Hueske]

29 days uptime on my 10.10.2 machine in question. Bingo.

[Erik Gomez]

How are the machines getting their updates?

On my Munki machines I am seeing a restart required. We use Reposado. 

[nbalonso]

Could the cause be that because the new updates automatically log you in after the reboot, the process is not trusted when Munki kickstarts it?

Noel

[Nicolas Daigneault]

I had the same error with 10.10.2 push by reposado, by Munki2.

SecurityAgent not found. This action only authorized by Apple"

I clicked several time on ok, and waited 20 minutes to be sure.  I needed to force shutdown my computer, and 10.10.2 was installed.

For now I blocked the installation of the 10.10.2.

[Brandon Kerns]

Moments after reading this thread, I just had the behavior occur in my test environment . 

"Unapproved Caller. SecurityAgent may only be invoked by Apple software." upon first login attempt after 10.10.2 installed from Reposado repo, via Munki 2 client.

[Gregory Neagle]

On Jan 29, 2015, at 9:26 AM, Brandon Kerns <ker...@gmail.com> wrote:

Moments after reading this thread, I just had the behavior occur in my test environment . 

"Unapproved Caller. SecurityAgent may only be invoked by Apple software." upon first login attempt after 10.10.2 installed from Reposado repo, via Munki 2 client.

And had the machine rebooted after installing the update?

Still trying to get clear descriptions of behavior and patterns here.

-Greg

On Thursday, January 29, 2015 at 11:57:59 AM UTC-5, Nicolas Daigneault wrote:

I had the same error with 10.10.2 push by reposado, by Munki2.

SecurityAgent not found. This action only authorized by Apple"

I clicked several time on ok, and waited 20 minutes to be sure.  I needed to force shutdown my computer, and 10.10.2 was installed.

For now I blocked the installation of the 10.10.2.

[Brandon Kerns]

I was away from the machine while the updates were applying, so I wasn't able to observe the restart behavior. I came back to find it at the login screen and the error occurred at first login attempt. Details I do have:

- Physical Machine (iMac14,1)

- Fresh deployment from blanked HD

- Installed with 10.10.0 and then updated to current from there

- All of our machines are AD joined at imaging

I'm currently in the process of running through the re-image again, watching more closely now.

I'll let you know what I see.

[Gregory Neagle]

On Jan 29, 2015, at 9:57 AM, Brandon Kerns <ker...@gmail.com> wrote:

I was away from the machine while the updates were applying, so I wasn't able to observe the restart behavior. I came back to find it at the login screen and the error occurred at first login attempt. Details I do have:

- Physical Machine (iMac14,1)

- Fresh deployment from blanked HD

- Installed with 10.10.0 and then updated to current from there

10.10.2 combo is different than 10.10.1 delta. And I expect the firmware update only installs once -- that is, if you update a machine to 10.10.2 (and therefore also install the Thunderstrike firmware update), then reformat the machine, install 10.10 or 10.10.1 and then update to 10.10.2 again, the firmware update may not (most likely will not) be installed again. So there are possibly many variables in play here.

-Greg

[Edward Eigerman]

I'm concerned that the current work-around, hard restarting after the update, may leave the machine on 10.10.2, but without the firmware update, which will never get applied since the machine is already on 10.10.2. I don't know how to check to see if the firmware update has applied or not.

Ed

[Gregory Neagle]

I think `system_profiler SPHardwareDataType`'s Boot ROM Version can give you a clue. You'd need to capture a before and after.

-Greg

[Brandon Kerns]

Also just confirmed same behavior on two more reference machines (MacBookAir6,1 and MacBookPro11,2). These machines had been sitting at login screen with 10.10.1 and updated to 10.10.2 though normal Munki runs after it was enabled in Reposado. I did notice that after the hard power off, both of these machines did and extra reboot before coming back up to the login screen. 

So, just to be clear: After the error occured, machine was hard powered off, powered on, progress bar displayed, rebooted again, second chime and progress bar, then proceeded to login screen.

[Gregory Neagle]

On Jan 29, 2015, at 10:34 AM, Brandon Kerns <ker...@gmail.com> wrote:

Also just confirmed same behavior on two more reference machines (MacBookAir6,1 and MacBookPro11,2). These machines had been sitting at login screen with 10.10.1 and updated to 10.10.2 though normal Munki runs after it was enabled in Reposado.

Did the machine then (automatically) reboot after Munki/softwareupdate installed 10.10.2?

I did notice that after the hard power off,

This is passive. Do you mean "after I powered them off by holding down the power button for several seconds"? Or something else?

both of these machines did and extra reboot before coming back up to the login screen. 

So, just to be clear: After the error occured, machine was hard powered off,

By hand?

powered on,

Manually?

progress bar displayed, rebooted again,

By itself (IE, no manual intervention)?

[Brandon Kerns]

So, the sequence was:

- Machines had been sitting and updated through normal automated runs

- Error occurred and displayed upon first login

- I powered them off by holding power button for several seconds

- Once off, pressed the power button once more to power on

- Chime and then apple logo with progress bar

- Progress bar completed

- Without intervention, the machine restarted

- Second chime then apple logo with progress bar

- Progress bar completed

- Machine proceeded to login screen

- I can now log in successfully, with no error displayed

[Gregory Neagle]

On Jan 29, 2015, at 10:49 AM, Brandon Kerns <ker...@gmail.com> wrote:

So, the sequence was:

- Machines had been sitting and updated through normal automated runs

- Error occurred and displayed upon first login

Did the machine (automatically) reboot after Munki/softwareupdate installed 10.10.2? This seems really important to determine.

[Brandon Kerns]

Greg, left out the answer to one of your questions:

Similar to the first one, I can't know if they rebooted automatically after the update applied - I wasn't present. Since these machines were sitting at the login screen, they applied the updates in the background when the updates were enabled in my testing branch. I didn't realize this as an issue and test logging in until today (likely days later).

[Gregory Neagle]

On Jan 29, 2015, at 11:06 AM, Brandon Kerns <ker...@gmail.com> wrote:

> Greg, left out the answer to one of your questions:
>
> Similar to the first one, I can't know if they rebooted automatically after the update applied - I wasn't present.

Please look at system.log and /Library/Managed Installs/Logs/Install.log to determine this.

/Library/Managed Installs/Logs/Install.log will tell you when the 10.10.2 update was installed; reboots are recorded in the system.log.

If needed, dig into the archived system logs (named system.log.0.gz, system.log.2.gz, etc.

sudo zgrep shutdown /var/log/system.log.*.gz might be of help here.

This is vitally important information as far as determining the root cause of this issue. If machines are not rebooting after installing the 10.10.2 update, this is the root cause.

-Greg

[mwilk...@rgmadvisors.com]

Good afternoon,

I can confirm that we are seeing this same behavior in our environment. It can be reproduced when installing the 10.10.2 Update from Managed Software Center instead of App Store.  It forces a hard shut down, then after reboot, it completes the installation and then proceeds to behave normally.

The only difficulty I have is putting a machine back into that state, since our workflow now installs the latest available version of the OS.  I have some users that I may be able to use as testers, if needed, though.

I'm happy to provide as much info as I can.

Mike Wilkerson

Desktop Systems Administrator

RGM Advisors, LLC

Austin, Texas

On Wednesday, January 28, 2015 at 10:21:51 AM UTC-6, zack.m...@bsd7.org wrote:

Added the OS X Yosemite 10.10.2 update to Munki yesterday. After it was run through MSU users reported popup "SecurityAgent not found. This action only authorized by Apple" multiple times. Only way to fix was force shutdown and restart. I followed instructions exactly and never added it to any manifests. I added a force install date key but that was all. Just a warning for this update. 

Any light shed on what I did wrong would be sweet, knowing me I messed up somewhere along the way.

---------------------------------------------------------------

This email, along with any attachments, is confidential. If you 

believe you received this message in error, please contact the 

sender immediately and delete all copies of the message.  

Thank you.

[Gregory Neagle]

On Jan 29, 2015, at 11:19 AM, mwilk...@rgmadvisors.com wrote:

Good afternoon,

I can confirm that we are seeing this same behavior in our environment. It can be reproduced when installing the 10.10.2 Update from Managed Software Center instead of App Store.  It forces a hard shut down,

What does this mean? what forces a hard shutdown?

then after reboot, it completes the installation and then proceeds to behave normally.

The only difficulty I have is putting a machine back into that state, since our workflow now installs the latest available version of the OS.  I have some users that I may be able to use as testers, if needed, though.

Again: I am urgently seeking information on whether or not these machines are rebooting after installing the 10.10.2 update.

(And I'd like to point out that this is one reason you should be testing new updates before deploying them widely -- seems like a lot of people were just pushing out the 10.10.2 update to everyone on day 1)

I'm happy to provide as much info as I can.

Mike Wilkerson

Desktop Systems Administrator

RGM Advisors, LLC

Austin, Texas

On Wednesday, January 28, 2015 at 10:21:51 AM UTC-6, zack.m...@bsd7.org wrote:

Added the OS X Yosemite 10.10.2 update to Munki yesterday. After it was run through MSU users reported popup "SecurityAgent not found. This action only authorized by Apple" multiple times. Only way to fix was force shutdown and restart. I followed instructions exactly and never added it to any manifests. I added a force install date key but that was all. Just a warning for this update. 

Any light shed on what I did wrong would be sweet, knowing me I messed up somewhere along the way.

---------------------------------------------------------------

This email, along with any attachments, is confidential. If you 

believe you received this message in error, please contact the 

sender immediately and delete all copies of the message.  

Thank you.

[mwilk...@rgmadvisors.com]

Let me clarify "It forces a hard shut down, then after reboot, it completes the installation and then proceeds to behave normally."

When managed Software Update completes the installations, the machine reboots as it normally would, then boots to a black screen with the "Unapproved caller..." alert box/error.  You're then stuck in a loop which requires a hard shut down of the machine.  As soon as you reboot, though, it resumes normal operation.

[Gregory Neagle]

On Jan 29, 2015, at 11:22 AM, mwilk...@rgmadvisors.com wrote:

Let me clarify "It forces a hard shut down, then after reboot, it completes the installation and then proceeds to behave normally."

When managed Software Update completes the installations, the machine reboots as it normally would,

Are you sure? Do you have a log to confirm?

[Edward Eigerman]

The firmware on a MacPro that had the 10.10.2 update applied, but was stuck on the unauthorized sender error and had to be hard restarted is MP61.0116.B11, The firmware on a MacPro on a seed version of 10.10.2, which doesn't have the firmware update, as far as I know, is MP61.0116.B10. So I think the firmware is being applied.

Ed

--

[mwilk...@rgmadvisors.com]

I have now seen this on about 10 users' machines.  It was around the 6th or so user that I began putting together the pieces that it was specific to Managed Software Center.  I'll have to get a hold of a machine that is still on 10.10.1 and reproduce it in my lab.  All of the machines I've seen it on are back in user hands.

Can you run down exactly which logs you want me to collect?  I can also grab some video, if you like.

Like always, I'm also putting out other fires, so I'll try to do this ASAP.

-mike

[Brandon Kerns]

I'm working on getting this info for you, Greg, but am getting slowed down people walking in with issues ... dang jobs, always getting in the way ;)

[Gregory Neagle]

I just want a clear, unambiguous sequence of events, starting with the install of the 10.10.2 update and leading to the appearance of the unwanted error dialog.

ManagedSoftwareUpdate.log, /var/log/install.log, and /var/log/system.login the correct time frame should provide the needed information.

-Greg

[Brandon Kerns]

Greg, 

I sent you the files you requested via "Reply privately to author". Let me know if they don't come through.

[Gregory Neagle]

Yes, and this is very much looking like a failure to restart after the 10.10.2 update is installed. Here is a bit of an affected machine's system.log, showing no evidence of system restart after the update was installed at 16:54:

Jan 27 16:53:50 <redacted> MunkiStatus[15540]: checkProcess timer fired

Jan 27 16:54:16 --- last message repeated 5 times ---

Jan 27 16:54:15 <redacted> kernel[0]: Refusing new kext com.apple.kpi.libkern, v14.1: already have loaded v14.0.

Jan 27 16:54:15 <redacted> kernel[0]: Refusing new kext com.apple.kpi.unsupported, v14.1: already have loaded v14.0.

Jan 27 16:54:15 <redacted> kernel[0]: Refusing new kext com.apple.kpi.mach, v14.1: already have loaded v14.0.

Jan 27 16:54:15 <redacted> kernel[0]: Refusing new kext com.apple.kpi.bsd, v14.1: already have loaded v14.0.

Jan 27 16:54:16 <redacted> mds[89286]: (Volume.Normal:2464) volume:0x7fe6bc1b7000 ********** Bootstrapped Creating a default store:0 SpotLoc:(null) SpotVerLoc:(null) occlude:0 /Volumes/bless.84V4

Jan 27 16:54:17 <redacted> mds[89286]: (ImportServer.Normal:4469) Software update complete

Jan 27 16:54:19 <redacted> kernel[0]: BUG in process suhelperd[813]: over-released legacy external boost assertions (1 total, 1 external, 0 legacy-external)

Jan 27 16:54:20 --- last message repeated 9 times ---

Jan 27 16:54:20 <redacted >MunkiStatus[15540]: checkProcess timer fired

Jan 27 16:54:21 <redacted> com.apple.xpc.launchd[1] (com.googlecode.munki.managedsoftwareupdate-check[15324]): Service exited with abnormal code: 1

Jan 27 16:54:25 <redacted> MunkiStatus[15540]: checkProcess timer fired

Jan 27 16:54:30 --- last message repeated 1 time ---

Jan 27 16:54:30 <redacted> MunkiStatus[15540]: managedsoftwareupdate not running...

Jan 27 16:54:35 <redacted> MunkiStatus[15540]: checkProcess timer fired

Jan 27 16:54:35 <redacted> MunkiStatus[15540]: managedsoftwareupdate not running...

Jan 27 16:54:40 <redacted> MunkiStatus[15540]: checkProcess timer fired

Jan 27 16:54:40 <redacted> MunkiStatus[15540]: managedsoftwareupdate not running...

Jan 27 16:54:45 <redacted> MunkiStatus[15540]: checkProcess timer fired

Jan 27 16:54:45 <redacted> MunkiStatus[15540]: managedsoftwareupdate not running...

Jan 27 16:54:50 <redacted> MunkiStatus[15540]: checkProcess timer fired

Jan 27 16:54:50 <redacted> MunkiStatus[15540]: managedsoftwareupdate not running...

Jan 27 16:54:55 <redacted> MunkiStatus[15540]: checkProcess timer fired

Jan 27 16:54:55 <redacted> MunkiStatus[15540]: managedsoftwareupdate not running...

Jan 27 16:54:55 <redacted> MunkiStatus[15540]: Timed out waiting for managedsoftwareupdate.

Jan 27 16:54:55 <redacted> MunkiStatus[15540]: statusSessionFailed: -1

Jan 27 17:02:16 <redacted> ScreenSaverEngine[16836]: Window Server is not available.

Jan 27 17:02:16 --- last message repeated 1 time ---

Jan 27 17:02:16 <redacted> ScreenSaverEngine[16836]: *** CGEventTapCreate returned NULL

This is the worrisome bit:

Jan 27 16:54:21 <redacted> com.apple.xpc.launchd[1] (com.googlecode.munki.managedsoftwareupdate-check[15324]): Service exited with abnormal code: 1

The managedsoftwareupdate launchd jon exited abnormally. This is almost certainly the cause of failure to reboot.

The relevant part of ManagedSoftwareUpdate.log:

Jan 27 2015 16:51:46 -0500 Installing OS X Update

Jan 27 2015 16:54:20 -0500     Done with OS X Update

Jan 27 2015 16:54:20 -0500     Done.

Jan 27 2015 16:54:20 -0500     You have installed one or more updates that requires that you restart your

Jan 27 2015 16:54:20 -0500     computer.  Please restart immediately.

Jan 27 2015 18:00:29 -0500 ### Starting managedsoftwareupdate run: auto ###

It doesn't show a crash of the managedsoftwareupdate process, so something else is happening.

Relevant part of install.log:

Jan 27 16:54:19 <redacted> softwareupdated[812]: SoftwareUpdate: finished install of 031-17157

Jan 27 16:54:19 <redacted> softwareupdated[812]: Removing 031-17157

Jan 27 16:54:19 <redacted> softwareupdated[812]: Removed local product for 031-17157 (1)

Jan 27 16:54:19 <redacted> softwareupdated[812]: SoftwareUpdate: Removed foreground transaction [0x6]

Jan 27 16:54:19 <redacted> softwareupdated[812]: Removing client SUUpdateServiceClient pid=15544, uid=0, installAuth=YES rights=(system.install.apple-software, system.install.apple-software.standard-user, system.install.software, com.apple.SoftwareUpdate.modify-settings), transactions=0 (/usr/sbin/softwareupdate)

Jan 27 17:56:04 <redacted> softwareupdated[812]: BackgroundActivity: Starting Background Check Activity

[Brandon Kerns]

Another small bit of info - the issue *did* occur once again on the first iMac I was speaking of after re-imaging from blank a second time.

[mwilk...@rgmadvisors.com]

Ok, I just walked through the process and was able to reproduce it.  You're right, Greg.  The machine does not restart.  Here's what I saw:

- With no apps running, I launched managed Software Update and it displays the 10.10.2 update and Remote Desktop Client.

- I clicked Update button, got pop-up indicating that the update required a restart and to Log out & update, which I did.

- logged out to black screen, with the Managed Software Center progress bar.  (NOTE: Our policy banner (Acceptable use policy window) popped up behind this window, as well.)

- After the packages were installed, the progress bar window simply went away and the machine sat at our Policy Banner.

- After I clicked "Agree", it went right back to the login window.

- Upon my attempt to log in, the screen went black and I got the Unapproved caller error.

- power off the unit by holding the power button for 5 seconds, then rebooting, completes the installation.

I'll send the log files over in a moment.

-mike

[Gregory Neagle]

On Jan 29, 2015, at 1:45 PM, mwilk...@rgmadvisors.com wrote:

Ok, I just walked through the process and was able to reproduce it.  You're right, Greg.  The machine does not restart.  Here's what I saw:

- With no apps running, I launched managed Software Update and it displays the 10.10.2 update and Remote Desktop Client.

- I clicked Update button, got pop-up indicating that the update required a restart and to Log out & update, which I did.

- logged out to black screen, with the Managed Software Center progress bar.  (NOTE: Our policy banner (Acceptable use policy window) popped up behind this window, as well.)

- After the packages were installed, the progress bar window simply went away and the machine sat at our Policy Banner.

- After I clicked "Agree", it went right back to the login window.

- Upon my attempt to log in, the screen went black and I got the Unapproved caller error.

- power off the unit by holding the power button for 5 seconds, then rebooting, completes the installation.

I'll send the log files over in a moment.

Or you can just look at them yourself and see if they show a similar sequence of events.

-Greg

[Gregory Neagle]

Here are logs for a machine that did not exhibit this issue, and did reboot after installing the 10.10.2 update:

ManagedSoftwareUpdate log (excerpt):

Jan 28 2015 11:50:41 -0800 Installing available Apple Software Updates...

Jan 28 2015 11:50:42 -0800     Finding available software

Jan 28 2015 11:50:44 -0800 Installing OS X Update, Remote Desktop Client Update

Jan 28 2015 11:54:26 -0800     Done with OS X Update

Jan 28 2015 11:54:26 -0800     Done with Remote Desktop Client Update

Jan 28 2015 11:54:26 -0800     Done.

Jan 28 2015 11:54:26 -0800     You have installed one or more updates that requires that you restart your

Jan 28 2015 11:54:26 -0800     computer.  Please restart immediately.

Jan 28 2015 11:54:26 -0800 Finishing...

Jan 28 2015 11:54:26 -0800 Saving application inventory...

Jan 28 2015 11:54:34 -0800     Performing postflight tasks...

Jan 28 2015 11:54:36 -0800     postflight stdout: Postflight report submmitted for Mac.

Inventory submmitted for Mac.

Jan 28 2015 11:54:36 -0800     postflight stderr: 2015-01-28 11:54:34.828 system_profiler[11876:200058] platformPluginDictionary: Can't get X86PlatformPlugin, return value 0

2015-01-28 11:54:34.830 system_profiler[11876:200058] platformPluginDictionary: Can't get X86PlatformPlugin, return value 0

Jan 28 2015 11:54:36 -0800 ### Ending managedsoftwareupdate run ###

Jan 28 2015 11:54:36 -0800 Software installed or removed requires a restart.

Jan 28 2015 12:17:25 -0800 ### Starting managedsoftwareupdate run: auto ###

Jan 28 2015 12:17:25 -0800 Starting...

Relevant bit of system log:

Jan 28 11:54:39 Mac.local MunkiStatus[10218]: checkProcess timer fired

Jan 28 11:54:41 Mac.local shutdown[11894]: reboot by admin: 

Jan 28 11:54:53 localhost bootlog[0]: BOOT_TIME 1422474893 0

And install.log:

Jan 28 11:54:25 Mac.local softwareupdated[10051]: SoftwareUpdate: finished install of 031-17157

Jan 28 11:54:25 Mac.local softwareupdated[10051]: SoftwareUpdate: finished install of 031-3227

Jan 28 11:54:25 Mac.local softwareupdated[10051]: Removing 031-17157, 031-3227

Jan 28 11:54:25 Mac.local softwareupdated[10051]: Removed local product for 031-17157 (1)

Jan 28 11:54:25 Mac.local softwareupdated[10051]: Removed local product for 031-3227 (1)

Jan 28 11:54:25 Mac.local softwareupdated[10051]: SoftwareUpdate: Removed foreground transaction [0x2]

Jan 28 11:54:25 Mac.local softwareupdated[10051]: Removing client SUUpdateServiceClient pid=10293, uid=0, installAuth=YES rights=(system.ins

tall.apple-software, system.install.apple-software.standard-user, system.install.software, com.apple.SoftwareUpdate.modify-settings), transa

ctions=0 (/usr/sbin/softwareupdate)

Jan 28 11:55:21 localhost softwareupdate_firstrun_tasks[70]: swscan.apple.com is available: TRUE

[Gregory Neagle]

Current working theory (but really not enough data):

After installing the 10.10.2 update, Munki performs a few more tasks before triggering a reboot. One of those tasks is causing the launchd job to die. Compare:

GOOD:

Jan 28 2015 11:54:26 -0800     You have installed one or more updates that requires that you restart your

Jan 28 2015 11:54:26 -0800     computer.  Please restart immediately.

Jan 28 2015 11:54:26 -0800 Finishing...

Jan 28 2015 11:54:26 -0800 Saving application inventory...

Jan 28 2015 11:54:34 -0800     Performing postflight tasks...

Jan 28 2015 11:54:36 -0800     postflight stdout: Postflight report submmitted for Mac.

Inventory submmitted for Mac.

Jan 28 2015 11:54:36 -0800     postflight stderr: 2015-01-28 11:54:34.828 system_profiler[11876:200058] platformPluginDictionary: Can't get X86PlatformPlugin, return value 0

2015-01-28 11:54:34.830 system_profiler[11876:200058] platformPluginDictionary: Can't get X86PlatformPlugin, return value 0

Jan 28 2015 11:54:36 -0800 ### Ending managedsoftwareupdate run ###

Jan 28 2015 11:54:36 -0800 Software installed or removed requires a restart.

BAD:

Jan 27 2015 16:51:46 -0500 Installing OS X Update

Jan 27 2015 16:54:20 -0500     Done with OS X Update

Jan 27 2015 16:54:20 -0500     Done.

Jan 27 2015 16:54:20 -0500     You have installed one or more updates that requires that you restart your

Jan 27 2015 16:54:20 -0500     computer.  Please restart immediately.

<appears to die here>

Jan 27 2015 18:00:29 -0500 ### Starting managedsoftwareupdate run: auto ###

So it's dying after logging "You have installed one or more updates that requires that you restart your computer.  Please restart immediately." (which is coming from /usr/sbin/softwareupdate) , but before logging "Finishing".

Here are some of the tasks it does between those messages:

munkicommon.savereport() (in doInstallTasks())

sendUpdateNotification() (to MSC.app or MunkiStatus)

https://github.com/munki/munki/blob/master/code/client/managedsoftwareupdate#L918-L927

add more items to the report:

    munkicommon.report['EndTime'] = munkicommon.format_time()

    munkicommon.report['ManagedInstallVersion'] = munkicommon.get_version()

    munkicommon.report['AvailableDiskSpace'] = \

                                        munkicommon.getAvailableDiskSpace()

    munkicommon.report['ConsoleUser'] = munkicommon.getconsoleuser() or \

                                        '<None>'

munkicommon.savereport()

One of these actions could be hitting something that got replaced/updated/changed that's causing the managedsoftwareupdate launchd job to crash.

Or it's possible that it's something happening a bit later, and when the process crashes some of the last things it tried to log don't actually get flushed to disk. The next few things:

https://github.com/munki/munki/blob/master/code/client/managedsoftwareupdate#L927-L936

    munkicommon.display_status_major('Finishing...')

    sendEndNotification()

    # save application inventory data

    munkicommon.saveappdata()

    # run the postflight script if it exists

    postflightscript = os.path.join(scriptdir, 'postflight')

    result = runScript(postflightscript, 'postflight', runtype)

    # we ignore the result of the postflight

    munkicommon.log("### Ending managedsoftwareupdate run ###")

Additional thoughts and theories welcome.

-Greg

[Erik Gomez]

May it also be possible that people with custom post flight scripts are the ones receiving this issue?

Sent from my iPad

[Gregory Neagle]

Absolutely possible, since that's one of the tasks Munki performs before attempting a restart.

[Jason Hueske]

Not a factor in the only client I’ve seen this on.

[Gregory Neagle]

Meaning exactly what? That there was no Munki postflight script in place on the affected client?

-Greg

[Jason Hueske]

Right, and none on unaffected ones either.

[mwilk...@rgmadvisors.com]

We also do not use any custom post flight scripts. 

[Gregory Neagle]

Changing the subject line so people will actually notice this thread.

-Greg

[Rundall, Jacob D]

This may be a red herring, but here are portions of Install.log for four machines I updated from 10.10.1 to 10.10.2 today via Munki. #1 & #2 did NOT experience the issue described in this (renamed) thread. #3 & #4 DID experience the issue we're discussing.

#3 and #4 failed to reboot automatically as part of the installation process via Munki. I got the error on the first login on #3 & #4. I force rebooted #3 via the power button and was then able to log in. I SSH'd to #4 and did 'sudo shutdown -r now' and was able to login without error after it restarted.

Two things that #3 & #4 had in common were that they were both also updating from Munki 1.0.0.1877.0 to 2.1.0.2349. Machines #1 & #2 were already running Munki 2.1.0.2349. Again, this may be a red herring. (Of course, a way bigger red herring would be that #1 & #2 were both installing TextWrangler....) An associated fact is that an update of Munki itself requires a restart on its own. So that's another angle: none of the Munki items installed on #1 and #2 required an update (the 10.10.2 update would have, however). But the update of Munki itself both on #3 and #4 required an update on its own.

I can send relevant excerpts from ManagedInstallLog.log or system.log that might be useful, but I can save space for now by saying that what I'm seeing matches up with the log excerpts Greg posted yesterday afternoon. I'm also seeing the same error in system.log
...com.googlecode.munki.managedsoftwareupdate-check[15324]): Service exited with abnormal code: 1

Jake Rundall


------------------------------------------------------

#1: FAA-MacInstall - no problem
Jan 29 2015 11:17:09 -0600 Install of Adobe Flash Player-16.0.0.296: SUCCESSFUL
Jan 29 2015 11:17:39 -0600 Install of Java (JDK) 8 Update 31-1.8.31.13: SUCCESSFUL
Jan 29 2015 11:22:14 -0600 Apple Software Update install of OS X Update-10.10.2: SUCCESSFUL
Jan 29 2015 11:22:14 -0600 Apple Software Update install of Remote Desktop Client Update-3.8.2: SUCCESSFUL


#2: FAA-test-Jake1B - no problem
Jan 29 2015 11:04:04 -0600 Apple Software Update install of OS X Update-10.10.2: SUCCESSFUL
Jan 29 2015 11:04:04 -0600 Apple Software Update install of Remote Desktop Client Update-3.8.2: SUCCESSFUL

------------------------------------------------------

#3: FAA-test-MLab2B - experienced the issue described in this thread
Jan 29 2015 11:06:22 -0600 Removal of MakerWare Bundle of Awesome 2.4.1.35: SUCCESSFUL
Jan 29 2015 11:06:30 -0600 Install of Munki - Managed software installation for OS X-2.1.0.2349: SUCCESSFUL
Jan 29 2015 11:06:35 -0600 Install of Graphic Design fonts-2015.01.16: SUCCESSFUL
Jan 29 2015 11:06:54 -0600 Install of Adobe Flash Player-16.0.0.296: SUCCESSFUL
Jan 29 2015 11:07:30 -0600 Install of Chrome-39.0.2171.99: SUCCESSFUL
Jan 29 2015 11:08:03 -0600 Install of Firefox-35.0: SUCCESSFUL
Jan 29 2015 11:08:12 -0600 Install of HandBrake-0.10.0: SUCCESSFUL
Jan 29 2015 11:08:18 -0600 Install of TextWrangler-4.5.12: SUCCESSFUL
Jan 29 2015 11:08:51 -0600 Install of Java (JDK) 8 Update 31-1.8.31.13: SUCCESSFUL
Jan 29 2015 11:14:20 -0600 Install of Adobe Acrobat XI Pro-11.0.10: SUCCESSFUL
Jan 29 2015 11:14:38 -0600 Install of Brother Inkjet Printer Drivers (4.0.6b)-4.0.6: SUCCESSFUL
Jan 29 2015 11:14:50 -0600 Install of Brother Scanner Drivers-3.10.6: SUCCESSFUL
Jan 29 2015 11:24:24 -0600 Apple Software Update install of OS X Update-10.10.2: SUCCESSFUL
Jan 29 2015 11:24:24 -0600 Apple Software Update install of Remote Desktop Client Update-3.8.2: SUCCESSFUL


#4: AppStoreDep1010 - experienced the issue described in this thread
Jan 29 2015 13:02:04 -0600 Install of Munki - Managed software installation for OS X-2.1.0.2349: SUCCESSFUL
Jan 29 2015 13:02:24 -0600 Install of Java (JDK) 8 Update 31-1.8.31.13: SUCCESSFUL
Jan 29 2015 13:02:28 -0600 Install of TextWrangler-4.5.12: SUCCESSFUL
Jan 29 2015 13:08:22 -0600 Apple Software Update install of Digital Camera RAW Compatibility Update-6.02: SUCCESSFUL
Jan 29 2015 13:08:22 -0600 Apple Software Update install of OS X Update-10.10.2: SUCCESSFUL
Jan 29 2015 13:08:22 -0600 Apple Software Update install of Remote Desktop Client Update-3.8.2: SUCCESSFUL

On Jan 30, 2015, at 10:34 AM, Gregory Neagle <gregn...@mac.com> wrote:

> Changing the subject line so people will actually notice this thread.
>
> -Greg
>

[Hugh Burt]

We are also experiencing a problem with our 10.9.5 clients running munki 1 with the 2015-001 update. Users click update, they are logged out, the machine restarts and then hangs for ever with the spinning grey wagon wheel. We have had this before and it looks to me if perhaps Munki doesn't seem to handle OS X (Post 10.9.4) updates that require restarts very well. I have noticed a common denominator with some of the munki 2 posts in that we also have a policy banner which has to be clicked before users see the logon box. I have decided to remove said banner to see if that helps. We had to use this banner because our auditors insisted on it.

-----------------------------------------------------------------------

[Gregory Neagle]

If this turns out to be an issue with Munki code, realize that I do not plan to patch or update Munki 1 code.

I would probably accept a patch from others against Munki 1.

Do recall that all Munki does is call /usr/sbin/softwareupdate to install Apple updates...

-Greg

On Jan 30, 2015, at 11:34 AM, 'Hugh Burt' via munki-dev <munk...@googlegroups.com> wrote:

> We are also experiencing a problem with our 10.9.5 clients running munki 1 with the 2015-001 update. Users click update, they are logged out, the machine restarts

Are you certain about this part ("restarts")?

> and then hangs for ever with the spinning grey wagon wheel. We have had this before and it looks to me if perhaps Munki doesn't seem to handle OS X (Post 10.9.4) updates that require restarts very well. I have noticed a common denominator with some of the munki 2 posts in that we also have a policy banner which has to be clicked before users see the logon box. I have decided to remove said banner to see if that helps. We had to use this banner because our auditors insisted on it.
>
> -----------------------------------------------------------------------
>

[Franson, Chris]

I had a machine fail to reboot after installing 10.9.5 Security update
2015-001 while also updating Munki core tools to 2.2.0.2399. I’ll have to
wait until Monday to collect log files.
It doesn’t seem that this issue is specific to 10.10.2.
-Chris

[Rundall, Jacob D]

What version of Munki were you running prior to the update? Is anybody getting these errors with Munki 2, or only while running Munki 1 (and possibly updating to Munki 2)?

Thanks,

Jake

[Franson, Chris]

On 1/30/15, 19:25, "Rundall, Jacob D" <runda...@gmail.com> wrote:

>What version of Munki were you running prior to the update? Is anybody
>getting these errors with Munki 2, or only while running Munki 1 (and
>possibly updating to Munki 2)?

I’d accidentally pushed an earlier Munki 2.2 RC into production (ugh) so
it would have been updating from an earlier version of 2.2. I’m not sure
which one.
-Chris

[Edward Eigerman]

We are using 2.0 and getting the error.

--
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+unsubscribe@googlegroups.com.

[Pepijn Bruienne]

I'm digging into this over the weekend, but just wanted to add a data point that we are seeing the same failure to reboot, with the same logging output (launchd job dies after softwareupdate completes): 

Jan 30 22:06:12 m-vmwyosemite1 com.apple.xpc.launchd[1] (com.googlecode.munki.managedsoftwareupdate-loginwindow[1958]): Service exited with abnormal code: 1 

I've been able to reliably reproduce this with a 10.10.1 VM running Munki 2.0.1.2253. In addition to the OS X 10.10.2 update this VM is also installing the ARD 3.8.2, iTunes 12.1 and Yosemite CLI tools updates. 

Dissecting the process around Apple updates in the Munki code will take a little bit of time on my part as I try to follow Greg's hunch about some other post-softwareupdate process run by Munki failing because of the OS update that just got installed prior to it. I would implore anyone on the list to share any additional data or findings they have as this is an important issue likely to impact more of us given the high failure rate we've seen already. 

Thanks, 
Pepijn. 

-- 
Pepijn Bruienne
Sent with Airmail

On January 30, 2015 at 11:34:13 AM, Gregory Neagle (gregn...@mac.com) wrote:

Changing the subject line so people will actually notice this thread.

-Greg

[Pepijn Bruienne]

So a first thing I tried was the following: poking through appleupdates.py I noticed the ptyexec wrapping being done, and the logic to deal with it not being there:

https://github.com/munki/munki/blob/master/code/client/munkilib/appleupdates.py#L1170

Code for ptyexec is here: https://github.com/munki/munki/blob/9537780bae55c15a3c8a34dc177978f5134201b9/code/client/ptyexec

Just to get an idea if ptyexec might be involved I figured I'd trigger the alternative run mode that uses /usr/bin/script instead by renaming ptyexec so it would execute like this:

https://github.com/munki/munki/blob/master/code/client/munkilib/appleupdates.py#L1179

To my surprise, the OS X 10.10.2 update now applied and the expected postflight actions ran, and Munki restarted the VM as required. No error prompts about "unapproved caller" were seen and login was successful, the OS X version was at 10.10.2.

For cross-reference I rolled the VM back again and this time left ptyexec in place so that it would once again be used to wrap softwareupdate - the process once again failed as it has been for others who reported the issue. I'm not sure if this means ptyexec is to blame, but this might give some focus to further figure out root causes. I'll report anything else I find.

Thanks,

Pepijn.

-- 
Pepijn Bruienne
Sent with Airmail

[Gregory Neagle]

Since not everyone is seeing this issue (for example, I haven't been able to reproduce this), it's also possible this is just chance: that if you had tried a few more times with /usr/bin/script it would have triggered the same error eventually.

Some background:

/usr/sbin/softwareupdate -v causes useful progress info to be sent to stdout: but only if softwareupdate thinks it's connected to a terminal.

When Munki was running softwareupdate as part of a launchd job which is not connected to a controlling terminal, softwareupdate doesn't output any progress info at all.

So I started using /usr/bin/script as a pseudo-tty wrapper for softwareupdate in order to cause softwareupdate to output progress info.

But the guys at Google noticed that /usr/bin/script caused huge CPU usage while softwareupdate ran, leading to fans ramping up and noticable performance hits.

So John Randolph wrote a Python replacement -- ptyexec. This allowed softwareupdate to provide progress info without causing a huge spike in CPU.

-Greg

[Pepijn Bruienne]

Yep, correct - I did run it a few times to verify but after sending my reply to this thread it hung up anyway. Right now it seems more likely that the process hangs up if a Munki 2 update is installed in the same update session, prior to the OS X 10.10.2 update running. This may explain why not everyone is able to reproduce this, if they are testing with no other updates, a Munki update in particular, being installed at the same time. The test VM I am working with does install a few other updates in the same session (Flash, Java) but those don't appear to be causing the failure to restart. It doesn't make immediate sense that installing updated Munki launchd jobs would cause the managedsoftwareupdate job to crash later on, but then again considering the full rewrite launchd received in 10.10 this doesn't entirely shock me.

Recap: test the 10.10.2 updater with and without a Munki update in the same session, compare restart behavior.

Thanks,

Pepijn.

-- 
Pepijn Bruienne
Sent with Airmail

[Gregory Neagle]

On Jan 31, 2015, at 10:46 PM, Pepijn Bruienne <brui...@gmail.com> wrote:

Yep, correct - I did run it a few times to verify but after sending my reply to this thread it hung up anyway.

So by this you mean that you observed the issue even with ptyexec not being used?

Right now it seems more likely that the process hangs up if a Munki 2 update is installed in the same update session, prior to the OS X 10.10.2 update running.

This may explain why not everyone is able to reproduce this, if they are testing with no other updates, a Munki update in particular, being installed at the same time. The test VM I am working with does install a few other updates in the same session (Flash, Java) but those don't appear to be causing the failure to restart. It doesn't make immediate sense that installing updated Munki launchd jobs would cause the managedsoftwareupdate job to crash later on, but then again considering the full rewrite launchd received in 10.10 this doesn't entirely shock me.

And "best practice" is to not install the Munki launchd jobs unless they've changed, so are you also implying that it must not only include a Munki update, but specifically an install of the Munki launchd jobs at the same time as the 10.10.2 update to trigger this issue? (I'm skeptical)

Recap: test the 10.10.2 updater with and without a Munki update in the same session, compare restart behavior.

We may need to be more specific around the "Munki update" as well, since what exactly changes depends on what you are running and what you install... IOW there are a lot more changes if you are updating from some version of Munki 1 to Munki 2.1.1 than if you are updating from Munki 2.1 to 2.1.1 and aren't (re-)installing the Munki launchd jobs.

[Pepijn Bruienne]

On February 1, 2015 at 9:53:48 AM, Gregory Neagle (gregn...@mac.com) wrote:

On Jan 31, 2015, at 10:46 PM, Pepijn Bruienne <brui...@gmail.com> wrote:

Yep, correct - I did run it a few times to verify but after sending my reply to this thread it hung up anyway.

So by this you mean that you observed the issue even with ptyexec not being used?

Yes, after doing more A/B comparison runs with and without ptyexec I saw success both with and without it, though it took 5-6 attempts before it did. I think I have a better idea as to why, see next section.

Right now it seems more likely that the process hangs up if a Munki 2 update is installed in the same update session, prior to the OS X 10.10.2 update running.

This may explain why not everyone is able to reproduce this, if they are testing with no other updates, a Munki update in particular, being installed at the same time. The test VM I am working with does install a few other updates in the same session (Flash, Java) but those don't appear to be causing the failure to restart. It doesn't make immediate sense that installing updated Munki launchd jobs would cause the managedsoftwareupdate job to crash later on, but then again considering the full rewrite launchd received in 10.10 this doesn't entirely shock me.

And "best practice" is to not install the Munki launchd jobs unless they've changed, so are you also implying that it must not only include a Munki update, but specifically an install of the Munki launchd jobs at the same time as the 10.10.2 update to trigger this issue? (I'm skeptical)

My particular session updates Munki from 2.0.1.2253 to 2.1.0.2349. The launchd job in 2.1.0.2349 is the same at version 2.0.0.1969 so it doesn't get installed. The only installed components are com.googlecode.munki.core 2.1.0.2349 and com.googlecode.munki.app 4.0.2348.

Given the above I've done about a dozen tests with and without installing aforementioned Munki components along with the 10.10.2 update (while allowing other updates to install) and every time a Munki update was installed the launchd job died and a restart was not performed. Without the Munki updates the installation completed successfully, the launchd job didn't die and a restart was performed.

TL;DR:

OS X 10.10.2 update + Munki components + other updates = failure

OS X 10.10.2 update + other updates = success

That begs the question if and why updating the Munki components causes its launchd job to terminate. That's definitely not something we've seen before but again I cast a doubtful eye on Yosemite's launchd. It would be very helpful if others reporting the same issue could chime in on whether or not they are also installing Munki updates and hopefully we can get some more clarity.

Recap: test the 10.10.2 updater with and without a Munki update in the same session, compare restart behavior.

We may need to be more specific around the "Munki update" as well, since what exactly changes depends on what you are running and what you install... IOW there are a lot more changes if you are updating from some version of Munki 1 to Munki 2.1.1 than if you are updating from Munki 2.1 to 2.1.1 and aren't (re-)installing the Munki launchd jobs.

See above, but I concur, 1 -> 2 has its own set of caveats. Basically more data is needed from those reporting the issue about what is installed outside of the OS X 10.10.2 update.

Thanks,

Pepijn.

[Samuel Keeley]

I will dig more into the logs tomorrow, but we are seeing the issue and don't update Munki with Munki - instead updating with Puppet. 

There must be another set of conditions which makes this happen. 

--
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.
For more options, visit https://groups.google.com/d/optout.

--
Samuel Keeley

[Gregory Neagle]

For those of you who can replicate this issue with some frequency:

If you add a Debug=true key to the Munki launchd daemons (see `man launchd.plist`) I wonder if we might get some additional useful info. We might also consider wiring up StandardOutPath and StandardErrorPath to see that gets us any extra data.

-Greg

[Brandon Kerns]

I can also certify that my example machines were not updating Munki in the run along with the 10.10.2 install. Two of the examples had been sitting at the login window getting updates via auto runs for quite some time (weeks at least) - and no new Munki version was enabled/pushed to them. The third example was a fresh re-image, with the Munki tools being installed by DeployStudio prior to the initial bootstrap run.

On Sunday, February 1, 2015 at 10:58:37 PM UTC-5, Samuel Keeley wrote:

I will dig more into the logs tomorrow, but we are seeing the issue and don't update Munki with Munki - instead updating with Puppet. 

There must be another set of conditions which makes this happen. 

On Sunday, February 1, 2015, Pepijn Bruienne <brui...@gmail.com> wrote:

On February 1, 2015 at 9:53:48 AM, Gregory Neagle () wrote:

On Jan 31, 2015, at 10:46 PM, Pepijn Bruienne <> wrote:

Yep, correct - I did run it a few times to verify but after sending my reply to this thread it hung up anyway.

So by this you mean that you observed the issue even with ptyexec not being used?

Yes, after doing more A/B comparison runs with and without ptyexec I saw success both with and without it, though it took 5-6 attempts before it did. I think I have a better idea as to why, see next section.

Right now it seems more likely that the process hangs up if a Munki 2 update is installed in the same update session, prior to the OS X 10.10.2 update running.

This may explain why not everyone is able to reproduce this, if they are testing with no other updates, a Munki update in particular, being installed at the same time. The test VM I am working with does install a few other updates in the same session (Flash, Java) but those don't appear to be causing the failure to restart. It doesn't make immediate sense that installing updated Munki launchd jobs would cause the managedsoftwareupdate job to crash later on, but then again considering the full rewrite launchd received in 10.10 this doesn't entirely shock me.

And "best practice" is to not install the Munki launchd jobs unless they've changed, so are you also implying that it must not only include a Munki update, but specifically an install of the Munki launchd jobs at the same time as the 10.10.2 update to trigger this issue? (I'm skeptical)

My particular session updates Munki from 2.0.1.2253 to 2.1.0.2349. The launchd job in 2.1.0.2349 is the same at version 2.0.0.1969 so it doesn't get installed. The only installed components are com.googlecode.munki.core 2.1.0.2349 and com.googlecode.munki.app 4.0.2348.

Given the above I've done about a dozen tests with and without installing aforementioned Munki components along with the 10.10.2 update (while allowing other updates to install) and every time a Munki update was installed the launchd job died and a restart was not performed. Without the Munki updates the installation completed successfully, the launchd job didn't die and a restart was performed.

TL;DR:

OS X 10.10.2 update + Munki components + other updates = failure

OS X 10.10.2 update + other updates = success

That begs the question if and why updating the Munki components causes its launchd job to terminate. That's definitely not something we've seen before but again I cast a doubtful eye on Yosemite's launchd. It would be very helpful if others reporting the same issue could chime in on whether or not they are also installing Munki updates and hopefully we can get some more clarity.

Recap: test the 10.10.2 updater with and without a Munki update in the same session, compare restart behavior.

We may need to be more specific around the "Munki update" as well, since what exactly changes depends on what you are running and what you install... IOW there are a lot more changes if you are updating from some version of Munki 1 to Munki 2.1.1 than if you are updating from Munki 2.1 to 2.1.1 and aren't (re-)installing the Munki launchd jobs.

See above, but I concur, 1 -> 2 has its own set of caveats. Basically more data is needed from those reporting the issue about what is installed outside of the OS X 10.10.2 update.

Thanks,

Pepijn.

--
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+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
Samuel Keeley

[Pepijn Bruienne]

What version(s) of Munki did you have on those machines who failed to reboot after the 10.10.2 update was installed?

Thanks,

Pepijn.

-- 
Pepijn Bruienne
Sent with Airmail

To unsubscribe from this group and stop receiving emails from it, send an email to munki-dev+...@googlegroups.com.

[Gregory Neagle]

I really think this is all a red herring and we should be focussing on the actions that managedsoftwareupdate performs after softwareupdate finishes running but before the restart is initiated. I'd recommend upping Munki's logging level in Munki's preferences and adding the Debug keys to Munki's LaunchDaemons.

-Greg

[Brian Warsing]

We are seeing this issue as well, but it didn't start appearing until the 10.10.2 update was released. 

I can also vouch that the issue is not scoped to Munki 2. 

We are using Munki v1 and the identical behavior (failure to restart) is presenting. 

Sent from my iPhone

[Brandon Kerns]

All of mine were with version 2.0.1.2253 of the tools - I haven't pushed 2.1.1 yet. However, I was going to give the process a go with that version today. I will also add the debug keys to the daemons and up the logging level when I do the next attempt.

[Pepijn Bruienne]

I have added:

MSUDebugLogEnabled 1

MSULogEnabled 1

LoggingLevel 4

to /L/Preferences/ManagedInstall.plist and set the Debug key in the launchd plists as well. Anything I'm missing?

Thanks,

Pepijn.

-- 
Pepijn Bruienne
Sent with Airmail

[Gregory Neagle]

I wouldn't have bothered with the MSU keys as MSU and MSC are not involved with this issue, but setting LoggingLevel to 4 might provide a bit more info into what managedsofteareupdate is doing before it dies.

-Greg

[Pepijn Bruienne]

We're trying to narrow this down to a certain version range and right now 2.0.x and earlier look suspect though there are several factors at play it appears and not just one or more changes made to the Munki code in 2.1.x and on. For those of you who have seen this issue but have not yet responded, could you please add your deployed version to this thread for further comparison?

For reference, I see the failure to restart with version 2.0.1.2253.

Thanks,

Pepijn.

-- 
Pepijn Bruienne
Sent with Airmail

[Gregory Neagle]

Which version of the Munki tools were your machines running at the time of install?

-Greg

[Gregory Neagle]

These are consistent with Pepijn's observation of issues when attempting updates with Munki 2.0.x and earlier; and no issue when using Munki 2.1 and later...

-Greg

[Gregory Neagle]

Version of the Munki tools?

-Greg

On Jan 28, 2015, at 12:49 PM, 'Edward Eigerman' via munki-dev <munk...@googlegroups.com> wrote:

We're seeing this very consistently on all updates through Munki and not at all on updates from any other source. We're guessing it's because this update contains a firmware update as well as the software updates. Not that that is a solution.

Ed

On Wed Jan 28 2015 at 3:46:23 PM <zack.m...@bsd7.org> wrote:

Ya I've recently found out that it seems to be related to Time Machine or a /var/ folder. We had a couple users update no problem via app store, but so far the 10 users who have used MSU (still trying to enforce DON'T use the dang app store) had this error pop up. Just coincidence I suppose.

On Wednesday, January 28, 2015 at 12:34:03 PM UTC-7, Predrag Stojanovic wrote:

Error not related to Munki (or anything you did).  Could be a bad HDD cable...

On Wednesday, January 28, 2015 at 11:21:51 AM UTC-5, zack.m...@bsd7.org wrote:

Added the OS X Yosemite 10.10.2 update to Munki yesterday. After it was run through MSU users reported popup "SecurityAgent not found. This action only authorized by Apple" multiple times. Only way to fix was force shutdown and restart. I followed instructions exactly and never added it to any manifests. I added a force install date key but that was all. Just a warning for this update. 

Any light shed on what I did wrong would be sweet, knowing me I messed up somewhere along the way.

--
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.
For more options, visit https://groups.google.com/d/optout.

[mwilk...@rgmadvisors.com]

After updating my clients' version of Munki to 2.1.1.2352, the issue is no longer present.

The version we had previously distributed was 2.0.1.2253, which is what was originally presenting this issue to us.

Thank you very much,

-Mike

---------------------------------------------------------------

This email, along with any attachments, is confidential. If you 

believe you received this message in error, please contact the 

sender immediately and delete all copies of the message.  

Thank you.

[Rundall, Jacob D]

Yes, indeed. And I’ve reproduced the results in a more controlled way on two machines. This time the only update I’m installing is the 10.10.2 update. When I use Munki 1.0.0.1877 there is a failure to reboot and I have the issue; when I use 2.1.0.2349 there is a reboot and there is no issue.

I enabled Debug in the LaunchDaemons and set LoggingLevel to 4 for Munki before running these tests. I’ve got system.log and various Munki logs available for all of them. I’d be happy to send the raw logs to Greg off-list. I’m going to try to pick through them and see if I can identify anything illuminating that I can clean and post on the list.

Jake

[Gregory Neagle]

It is looking like this issue is more likely to occur if the Munki tools are pre-2.1 and less likely to occur with Munki 2.1 and later, but I'm not yet prepared to say 2.1+ "fixes" the issue.

Pepijn Bruienne has been doing the bulk of the investigation and has found what seems to be a smoking gun, but not all data points line up as neatly as we'd like.

Still, I'd recommend admins install at least Munki 2.1 on Yosemite machines before attempting the 10.10.2 update to maximize your chances for success.

-Greg

[Jonathan Cohen]

The first client that we tested the 10.10.2 deployment with was running Munki 2.0.1.2253 , it had the same error as discussed here.  We have not done any further testing.  The update was only the OS update and did not include a Munki update or any other software installations.

[Pepijn Bruienne]

Thanks to Jonathan and Jake for their replies, this increases confidence that the focus for this issue is on 2.0.x and earlier. In more extended testing on my end with version 2.1.0.2349 it also did not have any trouble restarting as required by the 10.10.2 update.

If you are experiencing this issue but have not yet shared the exact version of Munki in use at the time of the update, please do so ASAP.

Thanks,

Pepijn.

-- 
Pepijn Bruienne
Sent with Airmail

[Erik]

https://groups.google.com/forum/#!topic/autopkg-discuss/KxAQBBx-QjE

Thoughts on this? I haven't seen the issue but I was using 2.1.X build and I also did not use this method to deploy Flash 16.0.0.296.

[Gregory Neagle]

No other reports or discussion.

I really don't think it has anything to do with an autopkg recipe update other than it and the issue both use the word "security".

The "unapproved caller" issue can be found on Google going back years, so there are obviously multiple triggers, most pre-dating both the 10.10.2 update and recent AutoPkg recipe updates.

-Greg

[Brandon Kerns]

Sorry for the delay, I was able to try again on the same reference machines substituting the 2.2 tools yesterday and the problem did not return on any of them.

[Pepijn Bruienne]

Thanks for testing and reporting Brandon, much appreciated.

Thanks,

Pepijn.

-- 
Pepijn Bruienne
Sent with Airmail