MacBook pro Dock flashes

[CBrown1975]

We are a new user of JAMF and are currently in a 1to1 refresh rollout. So far so good, but we are having a issue with the laptops in which the dock and screen "flash" and go away for 10 seconds or so. Has anyone else experienced this or have a possible solution that we could look at?

Thanks for any help

[rderewianko]

Sounds like somethings Killing dock or its crashing.
I'd poke around in console for: com.apple.Dock.agent

[mm2270]

Do you have something, like an application, launching at login, or anything in the Login Items that you see? Typically, the Dock flashing and going away means the Dock application is crashing and relaunching. Its designed to stay running, so if it unexpectedly quits, it will try to relaunch itself, but may get stuck in a loop. Sometimes this is caused by an application trying to activate that is causes Dock to crash.
It may also be because of a Configuration Profile or MCX setting, or several other possibilities though.

[CBrown1975]

Thank you for the quick response.

I did a console right away and this is what I got......maybe Chrome related?

Again any help is greatly appreciated.

5/21/15 9:45:36.336 AM nsurlstoraged[617]: realpath() returned NULL for /var/root/Library/Caches/jamf
5/21/15 9:45:36.337 AM nsurlstoraged[617]: The read-connection to the DB=/var/root/Library/Caches/jamf/Cache.db is NOT valid. Unable to determine schema version.
5/21/15 9:45:36.337 AM nsurlstoraged[617]: realpath() returned NULL for /var/root/Library/Caches/jamf
5/21/15 9:45:36.337 AM nsurlstoraged[617]: realpath() returned NULL for /var/root/Library/Caches/jamf
5/21/15 9:45:36.337 AM nsurlstoraged[617]: ERROR: unable to determine file-system usage for FS-backed cache at /var/root/Library/Caches/jamf/fsCachedData. Errno=13
5/21/15 9:46:04.510 AM com.apple.xpc.launchd[1]: (com.apple.PubSub.Agent[4452]) Endpoint has been activated through legacy launch(3) APIs. Please switch to XPC or bootstrap_check_in(): com.apple.pubsub.ipc
5/21/15 9:46:04.510 AM com.apple.xpc.launchd[1]: (com.apple.PubSub.Agent[4452]) Endpoint has been activated through legacy launch(3) APIs. Please switch to XPC or bootstrap_check_in(): com.apple.pubsub.notification

[CBrown1975]

In our infancy we only have Chrome and Gradebook placed on the dock. Is there a log or a way that we could look and see what exactly is crashing?

[rderewianko]

how are they being put on the dock?

[CBrown1975]

We have 2 separate policies set with 2 different dock items.

Hope this gives you the answer.....

[mm2270]

Meaning you are using the built in Add to Dock function inside Casper to add the items to the Dock?
If so, are you seeing that when the Dock "flashes" those icons are in the Dock? Or are they not there at all? I'm not sure if the Dock is staying up long enough for you to even see it. If they aren't in the Dock, then its possible the policy running to add the Dock items in is causing the crash, though honestly, I've never seen that myself.

As a test, you can try disabling the 2 policies that are trying to add those Dock items in and see what happens.

[CBrown1975]

To answer mm270 we do not have any applications launching at login. I will look down the rabbit hole of the MCX settings and see what I find.

[CBrown1975]

That is correct, the Add to Dock function is being used. You are correct, I couldn't tell you what is in the dock when it "flashes". The symptoms are that the dock goes away and the screen goes to black for 10 seconds or so.

We are running that test now, but I'm willing to bet that it will work. Obviously this is not a long term solution because part of purchasing JAMF was the functionality of being able to "push" these items out.

[mm2270]

@CBrown1975 I would only go 'down the rabbit hole' if you're using MCX in the first place. I was only suggesting possible causes. If you have no MCX or Config Profiles being pushed to the Macs, then that obviously isn't going to be the cause.
There should also be a crash log entries in Console that you can look at to see if it reveals anything. I would just look in either the latest system.log or in All Messages to see what it may be showing.

[CBrown1975]

More logs to look at.....

5/21/15 10:10:07.000 AM kernel[0]: AppleCamIn::handleWakeEvent_gated
5/21/15 10:10:07.000 AM kernel[0]: AppleCamIn::handleWakeEvent_gated
5/21/15 10:10:10.670 AM netbiosd[208]: name servers down?
5/21/15 10:10:13.023 AM logind[91]: -[SessionManager getClient:withRole:inAuditSession:]:241: ERROR: No session dictionary for audit session 100000
5/21/15 10:10:13.023 AM logind[91]: _SMGetSessionAgent:73: ERROR: __SMGetClientForAuditSessionAgent failed 2
5/21/15 10:10:59.760 AM netbiosd[208]: name servers down?
5/21/15 10:11:11.310 AM NotificationCenter[739]: Dock connection interrupted!
5/21/15 10:11:11.310 AM NotificationCenter[739]: disconnect 0x60000011f4a0
5/21/15 10:11:11.311 AM NotificationCenter[739]: Dock connection invalid!
5/21/15 10:11:11.312 AM NotificationCenter[739]: disconnect 0x0
5/21/15 10:11:11.318 AM com.apple.xpc.launchd[1]: (com.apple.Dock.agent[4934]) Service exited with abnormal code: 1
5/21/15 10:11:11.640 AM com.apple.xpc.launchd[1]: (com.apple.cfprefsd.xpc.daemon) Service only ran for 0 seconds. Pushing respawn out by 10 seconds.
5/21/15 10:11:11.662 AM com.apple.xpc.launchd[1]: (com.apple.cfprefsd.xpc.agent) Service only ran for 0 seconds. Pushing respawn out by 10 seconds.
5/21/15 10:11:12.654 AM NotificationCenter[739]: reconnecting, dock back alive
5/21/15 10:11:12.654 AM NotificationCenter[739]: Attempt to use XPC with a MachService that has HideUntilCheckIn set. This will result in unpredictable behavior: com.apple.dock.notificationcenter
5/21/15 10:11:12.655 AM NotificationCenter[739]: Dock connection invalid!
5/21/15 10:11:12.655 AM NotificationCenter[739]: disconnect 0x60800011cdd0
5/21/15 10:11:14.644 AM Finder[640]: CoreDockSetTrashFull returned error -4956
5/21/15 10:11:21.776 AM com.apple.xpc.launchd[1]: (com.apple.Dock.agent[5261]) Service exited with abnormal code: 1
5/21/15 10:11:21.919 AM spindump[3026]: Saved spin report for loginwindow version 10.4 (10.4) to /Library/Logs/DiagnosticReports/loginwindow_2015-05-21-101121_Lukes-MacBook-Pro.spin
5/21/15 10:11:22.304 AM com.apple.xpc.launchd[1]: (com.apple.imfoundation.IMRemoteURLConnectionAgent) The _DirtyJetsamMemoryLimit key is not available on this platform.
5/21/15 10:11:23.078 AM NotificationCenter[739]: reconnecting, dock back alive

[mm2270]

OK, so now we're seeing some more useful information. I see that Dock.agent is exiting with code 1 (error), so something is causing crashes. However, it actually sounds more like the loginwindow is crashing and not the Dock. I see in the above logs that there is a spindump for loginwindow, and you're stating that the screen goes black, which means its probably loginwindow that is crashing.

What OS are you imaging these Macs with? Or are they set up with?

Edit: Actually, never mind on loginwindow. I think its just that the Dock crashes are getting reported under loginwindow since its part of that overall launchd process.

[CBrown1975]

They are coming straight out of the box with 10.3.3.

[CBrown1975]

We are not imaging

[bpavlov]

@CBrown1975 There's your problem. You're working with 10.3.3. ;) Sorry couldn't help it.

[mm2270]

Lol, yeah, I'm guessing you meant 10.10.3, right? Anyway, not sure what the actual culprit is, but since you are not imaging them, something that's getting pushed to them as part of your configurations from Casper is likely causing the crash. ( I know 10.10's been buggy, but I don't think so buggy as to cause the Dock to crash at login :) ) You might need to do some old fashioned troubleshooting by enabling items one by one until you figure out which one is doing it.

[bentoms]

@CBrown1975 Are these dock items being added via a policy?

If so, how is it scoped & what's the execution frequency?

[CBrown1975]

10.10.3 is correct....my bad

They are being scoped to all computers with the frequency of ongoing.

We have turned off those policies and they issue has not popped up since. Obviously there is something with the policy and how the items are being deployed. Working now on making those a configuration profile and not a policy.

[bpavlov]

I haven't paid attention to the full thread but just to point out that if you have an ongoing policy that's managing your dock then it may literally be overwriting and killing the dock each time at check-in. This may or may not be what's happening, but something to keep in mind.

[bentoms]

@CBrown1975 what @bpavlov said hit the nail on the head for what I was getting at.

The dock "flashing" was happening every time the policy was being run.

[mm2270]

I had thought the same thing as @bpavlov re: the Ongoing policy. Only thing is, if its restarting the Dock every 10 seconds or so that wouldn't really be it. But it does seem like something in the policy causing it. Glad you at least figured out it was the policy doing it.

[CBrown1975]

Ok let me ask you this......I can't have a dock item to stay in the dock when a user removes it? And that a ongoing policy will cause a machine to blackout anytime we have an ongoing policy running? What's the point of having that as a option if that is the outcome. Seems while it is a possible reason that this is happening, it doesn't shine a good light on the product.

Again I am new at this and am learning on the fly. If there is another solution that can solve our issue I would appreciate to hear it.

[mm2270]

Ongoing policies are not for enforcing items like a Dock configuration. There are other ways to accomplish this with a Configuration Profile, and MCX prior to that. Ongoing policies are more for items that you always want to either make available in Self Service or for stuff that may need to make a configuration change in the background. As the Dock is a user specific item, trying to have a policy always running, adding in items is going to make for a poor experience. The Dock needs to restart when items are added to it by a policy or script, since that's the only way for the item to show up. Its different than manually dragging an icon into the Dock.

That being said, it should not have actually caused the severe issue you were seeing, since you said it was restarting every 10 seconds, so I suspect there was something else going on here. I doubt your Casper config is set up for Macs to run policy checks every 10 seconds, so I'm not completely convinced it was just that alone.

For setting up a Dock config that user's can't change, take a look at this:
http://errorfreeit.com.au/blog/2015/4/28/dock-master