Yosemite apps 'not responding' after sleep

jmig
New Contributor II

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...

1 ACCEPTED SOLUTION

jmig
New Contributor II

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"

View solution in original post

9 REPLIES 9

alexjdale
Valued Contributor III

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.

jmig
New Contributor II

@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?

Kaltsas
Contributor III

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.

alexjdale
Valued Contributor III

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

jmig
New Contributor II

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.

jmig
New Contributor II

Sigh... I've had this script running all weekend, and I cannot get it to recreate the issue.

jmig
New Contributor II

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"

alexjdale
Valued Contributor III

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.

bheitzig
New Contributor II

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?