Mavericks Sleep/Wake Login Issue

Turns out that even though I had "Create mobile account at login" checked in my directory binding it didn't work on this MacBook Air. Once I made sure that checkbox was enabled the issue stopped. Not sure why it skipped creating a mobile account for that user… but at least it's working now.

Thought this would be fixed at 10.9.4 but unfortunately still happening...

@BMCCGroup - I was too. Haven't tested yet. Did you update and test? What if you unjoin and rejoin?

Yes, I already tested it. Still happening. I also put in a ticket to Centrify and they pointed out this is an Apple bug in Maverick. No resolution at the moment.

@BMCCGroup
I spoke with someone from Apple at the JAMF User meet up in NYC, and told of the problem as well.

Incase anyone is still looking for the work around until Apple starts taking this seriously. I've come up with this based on my findings on the loginwindow process.

#!/bin/sh
# Resets the LoginWindow Process so that the Active directory client gets a chance to login un-cached users.
# only use on Mavericks.

isUser=$((`ioreg -c IOHIDSystem | sed -e '/HIDIdleTime/!{ d' -e 't' -e '}' -e 's/.* = //g' -e 'q'` / 1000000000))
echo "HID idle for $isUser Seconds"
if test $isUser -ge 300 #If no Activitiy from the mouse and keyboard for 5 minutes....
then
    echo "No User Detected, Resetting Login Window"
    caffeinate -u -t 5 #Wake the display, that way there is no black screen of death
    sleep 5 #Wait for the Caffeinate Command to finish running.
    kill -9 `ps -Axjc | grep -E 'root.*loginwindow' | awk '{print $2}'` #Kill Roots LoginWindow
fi

The script runs at the interval, at a policy setting of ongoing, mine happens to be set at 60 minutes.
If a user has touched the HIDs within 5 minutes it cancels it's run.
To make sure we don't get a black screen of death, (sometimes happens if you kill loginwindow while the display is asleep), we "caffeinate the computer.
Then we kill only the loginwindow process associated with root.
Been tested in my open lab area over the last two weeks and works perfectly.
I've also limited the script to 10.9.x.

Hope this workaround helps for now.

Side benefit is it clears out any random characters that may be in the username and password fields as well.

This script works perfectly.

@BaddMann - Your script saved the day!

My pleasure Guys!
Watch out for AirplayUIServer.app as well.
It destroys Airdrop and crashes logouts if airdrop was used.

I'll write more later.

We are currently having this experiencing this issue as well.

I recommend you try:

sudo pmset womp 0 && reboot

This appears to address the loginwindow issue for us.

It is not a desirable configuration, but if it works for you as well, it will be a good indicator what Apple needs to do to address this bug.

--
B.

@bwarsing

Please try my script.
It works and does not require a reboot.

@BaddMann

I think you missed the point. This is an energy saver setting and is therefore persistent across reboots and does not require any scripting.

The reboot is not strictly required.

Yeah after I posted my message I researched it.
Feeling sheepish....
Nice to finally know the underlying cause.

I had the same issue. I tried all pmset options, nothing fixed it. Killing the login window process did fix it when it happened however that's not feasible.

I re imaged the computer and did not transfer any settings from old computer to the new. This helped, the computer no longer has the issues. 10.9.4 I believe something in the migration from old to new caused the problem.

@tnielsen

Are using monolithic ASR images?

Sounds like you whatever imaging process you are using is transferring things it should't be -- settings in /Library/Preferences/SystemConfiguration for instance. Copying such settings from one Mac to another can lead to strange issues.

Whatever the case, I can reproduce the behaviour described in this thread every time using a fresh install of Mavericks on any point release after 10.9.1.

@tnielson

My script only restarts loginwindow for the root user, that is the login prompt.
Not any other user....

It also checks for users, if anyone has touched the mouse or keyboard for the last five minutes it aborts.
Please give it a try you'll find it works rather well.

@BaddMann

Have you tried simply using a script to create a network transition or sending a HUP to SecurityAgent?

@bwarsing

Please Explain more.
The HUP part I understand it's the network Transition, that threw me.
Though I think everyone could benefit from an explanation.

@BaddMann][/url

Explicit example: bringing a network device down and then back up again.

sudo ifconfig en0 down && ifconfig en0 up

thats not likely to work without a sudo after the &&

@nessts

Yes, but if we are going to get picky then I suppose if it were in a script capable of restarting loginwindow, you really wouldn't need sudo at all. ;)

I was told if you are using AD binding, and using anything besides the built-in Apple one, this is an issue. From my conversations with Centrify, it seems to be a bug in 10.9.x with 3rd party directory plugins. They have an open ticket with Apple, but so far no resolution.

I wrote my Loginwindow restart to specifically avoid restarting the network.

If I happen to have policies running, or some other network reliant task running, it would effect it.

The login window on the other hand is a separate process that constantly gets created and destroyed as a regular side effect of logging in and logging out.
All I'm doing is causing another trigger to go through a process the mac goes through anyway......

So why is disconnecting and possibly harming other tasks better than causing a natural process to happen?

Here's the script that I use and we do AD logins. This scripts works flawlessly. You can change the sleep settings to whatever you need. I believe I found this here on Jamf Nation:

#!/bin/sh

# AD login Window.sh
# #
#
###

# set power management preferences
# set scheduled events for startup and shutdown

# settings for desktops
setDesktopPrefs(){
pmset -a sleep 0 2>/dev/null # system does not go to sleep automatically
pmset -a powerbutton 0 2>/dev/null # do not allow power button to sleep the computer
pmset -a displaysleep 30 2>/dev/null # sets display sleep time
pmset -a disksleep 0 2>/dev/null # does not spindown hard drives
pmset -a womp 1 2>/dev/null # wake up computer if it receives wake-on-lan magic packet

# set scheduled startup and shutdown
pmset repeat cancel # clear all repeating startup and shutdown events
sleep 1
pmset repeat wakeorpoweron MTWRFSU 7:45:00, shutdown MTWRFSU 22:15:00
sleep 1
}
# settings for laptops
setLaptopPrefs(){
pmset -a sleep 0 2>/dev/null # system does not go to sleep automatically
pmset -a powerbutton 0 2>/dev/null # do not allow power button to sleep the computer
pmset -a displaysleep 30 2>/dev/null # sets display sleep time
pmset -a disksleep 0 2>/dev/null # does not spindown hard drives
pmset -a womp 1 2>/dev/null # wake up computer if it receives wake-on-lan magic packet
pmset -a lidwake 1 2>/dev/null # wake up computer when lid is opened
pmset -a acwake 0 2>/dev/null # do not wake up computer when power adapter is connected
pmset -a halfdim 1 2>/dev/null # sets display to halfdim before display sleep
pmset -a sms 1 2>/dev/null # use Sudden Motion Sensor to park disk heads on sudden changes in G force

# set prefs when using battery only
pmset -b sleep 20 2>/dev/null # system goes to sleep after idle time
pmset -b displaysleep 15 2>/dev/null # sets display sleep time
pmset -b disksleep 10 2>/dev/null # spindown hard drives

# set scheduled startup and shutdown
pmset repeat cancel # clear all repeating startup and shutdown events
}

checkIfLaptop=$(sysctl -n hw.model | grep -i -c book 2>/dev/null)
if [ $checkIfLaptop -gt 0 ]; then
echo "Setting power management for laptop..."
setLaptopPrefs
else
echo "Setting power management for desktop..."
setDesktopPrefs
fi
pmset -g
echo
pmset -g sched
sleep 1
exit 0
###

@rcarey912

This isn't a problem with the sleep schedule on an AD joined Mac.
This is a problem with third Party Clients AD clients, like Powerbroker(Also know as Likewise) or Centrify.
This script you offer can't help us.
Thank You, though, at least this may get some attention.