Yosemite Sleep/Wake Login Issue?

We have been seeing the same issue in our environment since Tuesday. I'm guessing it's related to the latest security update Apple released last week. Thus far, we have implemented a couple of the suggestions (rc.server, clearing library cache & BootCache.playlist file) for the 50% issue with limited success. The rc.server definitely did not impact the wake from sleep logon issue and we are still working on testing the cache clearing and playlist file deletion fix.

I believe @franton was working on an issue like this the other week, although I think it was 10.9. Looked to be more of an authorisation issue. He might be able to comment on it.

Are you using mobile accounts? We use them most of the time to help with the reliability.

Just wanted to chime in that we're also seeing this issue on our AD bound 10.10.2 clients with mobile accounts.

@dsargent I'm unaware of the cache clearing and playlist file deletion fix, or was that meant to be plist file? Is it in the 50% boot thread? Do you have a link to share? Thanks for the information on this!

@davidacland We are using mobile accounts which I agree should help with the reliability. I'm at a loss as to why they are freezing up for 10.10 in sleep mode since the mobile account makes it act somewhat like a local account.

@johanguz Thanks for letting me know. Hopefully this gains some traction and there's a solution out there someone knows about!

@breatheforme Hopefully there is a fix soon. As a workaround we've enabled unlocking by a local admin on Yosemite clients https://support.apple.com/en-us/HT202402 which at least allows us to bypass force restarting a client's computer.

Just want to chime in that this is also affecting our users. They're bound to AD with mobile accounts. I believe it happens for us when they take their Mac home for the day and disconnect from the AD server. When they try to open their Mac to login at home, they're no longer connected to AD and it hangs. I think it will eventually show an error connecting to the server and allow them in.

Yes, that should be plist, not playlist...bitten by an auto correction. This was posted in the 50% boot thread as something that was recommended by Apple.

We still haven't found a resolution to this, though we haven't been focused on this, as we have been fighting the inability to logon to an AD bound machine while off the network with our largely mobile workforce. We thought it was limited to 10.10, but have been seeing it crop on 10.9 machines as well.

Thus far, it has been more of an annoyance more than a fire...unlike the aforementioned spreading offline logon issue.

Just my 2 cents.

We are also experiencing this issue. Seems to be centered around WiFi & 10.10.3 & AD Accounts.
Not sure if FileVault 2 is part of the issue but we need to use at as per corp policy.

End user go away and screen saver kicks in or they close the lid, afterwards at wake time trying to type in their AD password the UI does nothing. Seems like its stuck. Not even the Cancel button is working. Eventually, if you wait more than 2 mins it will either shake "No" or just simply, do nothing.

One user was sitting at my desk with her laptop stuck in this state. Just for fun we waited about 5 mins (didn't time it but certainly much longer than normal) and auto-magically it authenticated and logged in. We were both like "How you like dem apples Alfalfa?"

We have a few desktops running 10.10.3 & AD Accounts & FileVault, since these machine are Ethernet, this issue is not present.

Also noticed that machines on WiFi, from restart/startup once the disk is unlocked it takes 1 min 39 seconds to get to the desktop of an AD account. If we do this on the same machine with a Thunderbolt Ethernet plugged, whether WiFi is on or not, the boot time is 32 seconds.

We tried ticking "Use Preferred Domain Controller" in the mac's AD plugin. No change.
We tried something we read about adding .local to the macs DNS. No change.

So as a resolve, we are unbinding the mac from AD, cause my end users need to work and not troubleshoot Apple Timepiece & Telephone Corporation's break-though Emoji support.
Unbind your macs, and this issue goes away like a wave of Albus Dumbledore's Wand.
But of course you lose all the goodness of AD stuff.

We are monitoring every machine that becomes unbound through the JSS so we have reporting on it. Before we unbind the machine we make the user change their password cause that will reset their AD password to another 90 days and hopefully the Watch Manufacturer will issue another Emoji update in that time.

On a side note, anyone bought watch?
:)

@pvader have you tried this? From my notes:

sudo defaults write /Library/Preferences/com.apple.loginwindow DSBindTimeout -int <seconds>

The seconds you need to enter will be different depending on the infrastructure at the particular client. In xxx's case, I set it to 20 seconds and it worked well. Here is how you determine what value will work:

Make sure the Mac has FileVault enabled, and is bound to AD. Turn on OD debug mode in terminal: odutil set log debug
Set the value of DSBindTimeout to 30 seconds
Shut down the Mac, then turn it back on
Look at /var/log/opendirectoryd Turn off OD debug mode in terminal: odutil set log default

The word you need to search for in that log is “cached”. You’ll either see that it was successful in talking to AD or you’ll see “failed to use original node for cached user ‘ad_username’, continuing with offline authentication”. If you see the failure message, increase the time out value. If it was successful, you can reduce the time out value lower if you’d like, but make sure you leave it long enough that it actually does authenticate against AD. If it always uses the cached credentials and the user's password has changed, the keychain will get out of sync."

@RobertHammen I'm seeing the same thing and tried that patch as well. It had no effect for my users. I use that one for users who complain about logins and usually set it anywhere from 10-15 without any issue. @pvader is right though it really seems to have gotten worse for me since 10.10.3. Glad others are having the issue so I know that it's not isolated.

when this happens, are these laptops on the Uni network?

Hey all,

Think I narrowed it down to 802.11ac as the culprit here in our setup.

Apple's newest laptops utilizes a WiFi adapter that supports 802.11ac where as older laptops have the WiFi chipset of 802.11n.

There is no sleep/screen saver lag on machines that use 802.11n

Can anyone else can confirm this?

Thanks as always,
-p

Hi Everyone,

Has anyone found a workaround/fix for this issue? I have a decent amount of users with this problem, mostly MBPr 13" and using we are using mobile accounts if that helps.

DSBindTimeout doesn't work. Flushing the DNS caches seems to help for about a week then the issue comes back.

Any ideas/suggestions would be greatly appreciated :)

From the things I've read, this issue may also be attributed to the very problematic and buggy discoveryd process Apple introduced in Yosemite (replaced mDNSResponder) As being reported out there, the latest 10.10.4 beta from Apple has done away with discoveryd and put mDNSResponder back. If they stick with this, we may finally see an end to all the crazy wi-fi and general networking issues Yosemite brought with it.

Honestly, I can't wait for Apple to release 10.10.4. It can't come soon enough for us. It looks like it may be the first release of 10.10 that promises to fix all the bugs.

I just read about this yesterday
http://www.macrumors.com/2015/05/26/apple-discoveryd-replaced-with-mdnsresponder/

Have a look at...

Awesome, thanks everyone! @donmontalvo I'll give that a shot. Otherwise we'll hold out for 10.10.4 and hope they keep mdnsresponder.

Hi all,
I'm definitely hearing a lot about this. We have a Mac user email list and there's been much discussion about these issues lately. I've never seen it first hand, so was taking it with a grain of salt - BUT I just imaged a new Mac and it's been sitting over night sleeping. Upon waking it up this morning it definitely had the described issue.

Here's to 10.10.4's release (or a fix) SOON!

Thanks,
Matt

Is anyone still having this issue with 10.10.4? I had a colleague come to me with the issue running 10.10.4 but this is the only confirmed case I have so far. Not sure if it was a fluke or still an issue so i'm just putting feelers out!

We have not see any reoccurrence of this since pushing 10.10.4.

Regards,
Darren

I have not seen this issue since 10.10.3

@breatheforme we just started seeing many of our Macbook Pros w/ HDDs running 10.10.4 after being awoken from sleep take 2-5 minutes or more to actually wake and accept input from users to get past the lock screen. Reached out to JAMF about the issue.

Given that 10.10.4 does not use the Yosemite-introduced discoveryd process anymore, does anyone have any ideas on a root cause and/or a solution??

@aporlebeke

I've found this can be caused by a bug in Fiery print drivers. If you have Fiery print drivers look in your Console logs, especially around the time of wake or screen unlock. The bug hogs so much CPU it prevents some keystrokes in the login window from being recognized.

Do you have Fiery print drivers?

@gskibum, no, no Fiery print drivers for us. I ended up just making a new base OS using a MBP with a HDD. This seems to have solved the problem with a very long delay after a computer is woken up. Seems to be a bug when using a base OS made on an SSD.

Just means that we have to reimage everything with a regular spinning hard drive ... sigh