Posted on 04-28-2015 03:37 PM
The issue: Several users report (and I've seen with my own eyes) that 10.10.x / all of their open apps crash after returning from sleep mode. The mouse will move around the screen and the users can right click on dock icons, but they cannot force-quit apps or access other os menu items / features. Beach ball spins for a while, and only a forced restart resolves the issue.
The environment: University setting with computers managed by Casper, bound to our AD, and encrypted (Sophos Safeguard using FileVault). OS varies between 10.10.2 and 10.10.3 (but might be affecting 10.10.1 as well).
The hardware: Recently purchased (arrived in late February), Late 2013 iMacs (14,1) and MBPs (11,1) with 8 GB RAM and Intel i5. All computers arrived with Yosemite.
The failed workarounds:
- Upgrading to 10.10.3 / supplemental 10.10.3 update
- Using PMST to turn off hibernate and/or deep sleep (one user reported the problem worsening after this)
- Restoring the OS
- PRAM or SMC reset
- Disabling Sophos anti-virus
I am running a Late 2014 Mac Mini, 16GB, i7 with Sophos anti-virus and encryption on 10.10.3, and have not had this problem, so I want to rule out the encryption...
Solved! Go to Solution.
Posted on 05-30-2015 08:27 AM
I worked with an Senior Education Support rep from Apple – after going over the development notes for 10.10.4, which indicated this issue should be addressed, he suggested we try the 10.10.4 beta on one of the computers, and see if the issue still exists. We upgrade one of the problematic MacBook Pros with the beta for 10.10.4, and the problem is resolved. I wouldn't normally release a beta into our environment, but it's only 4 devices (for now), and they are otherwise useless – I hope the public version is released soon.
For more details about the issue, see: "Apple Replaces Problematic 'Discoveryd' Process With mDNSresponder in 10.10.4 Beta 4"
Posted on 04-28-2015 03:49 PM
This sounds exactly like our issue: https://jamfnation.jamfsoftware.com/discussion.html?id=12421
The only fix we have is to unbind it from AD. It's an AD-related issue that started in 10.9.5 and we have not been able to nail down, except it always happens soon after a connection to our network is made (connect to VPN, come out of sleep, roam on wifi, etc).
I'd like you to try a test for me: write a simple script that turns the primary NIC off and on every 60 seconds. It should trigger the issue within an hour or two if it is the same issue. Pretty sure it is due to a change in opendirectoryd that has an issue with some domain infrastructures (could be bad DNS records, bad caching, or unreachable DCs or something).
I am able to reproduce this on a totally fresh OS install, only bound to AD, so I know there are no apps or other factors involved.
Posted on 04-29-2015 06:06 AM
@alexjdale for the script are you using something similar to:
usr/sbin/networksetup -setairportpower en1 off /usr/sbin/networksetup -setairportpower en1 on
or
sudo ifconfig en0 down sudo ifconfig en0 up
edit: Do you know if this issue effect local accounts if the computer is bound to AD?
Posted on 04-29-2015 07:18 AM
I was going to say this sounds like an issue we were experiencing which is a bug in McAfee EPM
https://kc.mcafee.com/corporate/index?page=content&id=KB84462
But you're able to replicate it sans any extra software. Unfortunately I am not able to replicate this in our environment so you may be on to something with your infrastructure specific theory.
Posted on 04-29-2015 02:35 PM
Here is my script, which let me try different durations between toggles as well as number (duration between did not really seem to make a difference, I usually used 40 seconds). As I recall, the problem still occurred when logged in as a local account.
My best theory is that it happens sometimes when opendirectoryd gets in contact with the domain and performs whatever initialization/caching/secret sauce it does.
#!/bin/bash
NIC=$1
numSec=$2
numToggles=$3
counter=$numToggles
while [ $counter -gt 0 ]; do
log "Toggling $NIC, $counter of $numToggles"
counter=$[$counter-1]
ifconfig $NIC down
ifconfig $NIC up
currSec=0
while [ $currSec -lt $numSec ]; do
currSec=$[$currSec+1]
sleep 1
done
done
Posted on 04-29-2015 02:53 PM
Great, I'll give this a go and see if it duplicates the issue. Thanks!
I've got the script running now and will report back.
Posted on 05-04-2015 07:05 AM
Sigh... I've had this script running all weekend, and I cannot get it to recreate the issue.
Posted on 05-30-2015 08:27 AM
I worked with an Senior Education Support rep from Apple – after going over the development notes for 10.10.4, which indicated this issue should be addressed, he suggested we try the 10.10.4 beta on one of the computers, and see if the issue still exists. We upgrade one of the problematic MacBook Pros with the beta for 10.10.4, and the problem is resolved. I wouldn't normally release a beta into our environment, but it's only 4 devices (for now), and they are otherwise useless – I hope the public version is released soon.
For more details about the issue, see: "Apple Replaces Problematic 'Discoveryd' Process With mDNSresponder in 10.10.4 Beta 4"
Posted on 06-01-2015 11:07 AM
Good to see you had that resolved. We finally got Apple to admit to the opendirectoryd bug that is affecting us, but no ETA on a fix. We have to remove the Active Directory authentication search policy to fix our lockups.
Posted on 01-11-2016 07:33 AM
I have a config profile set to bind with AD and provide login window authentication running on iMac labs with 10.10.4. Sleep has been a minor issue, however, in the last month or so it's become extremely challenging. I haven't been able to identify what may have affected this yet - any thoughts?