Mavericks Sleep/Wake Login Issue

[pblake]

I am having an issue, and I am hoping someone here has seen it or has a fix.

We use Centrify here to bind our Macs to AD.
The issue we are seeing is once a user logs in, creates a profile. If the logout and put the computer to sleep, they cannot log back in until after the reboot. I assume this is a networking issue, but I cannot find a resolution.

Please help JAMF Nation!

[bwarsing]

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

[BaddMann]

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

[bwarsing]

@BaddMann

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

[BaddMann]

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

[bwarsing]

@BaddMann][/url

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

sudo ifconfig en0 down && ifconfig en0 up

[nessts]

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

[bwarsing]

@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. ;)

[pblake]

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.

[BaddMann]

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?

[rcarey912]

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

[BaddMann]

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

[bwarsing]

@BaddMann

Not suggesting HUP'ing network is any better -- just wondering if our experiences align and trying to scope the issue.

Here is what I know to be effective in curbing this loginwindow amnesia...

HUP loginwindow: always works
HUP network: always works
HUP SecurityAgent: sometimes works
WOMP = false: appears to work! I have tried it on 15 machines, but they are all identical hardware...

Model Name: iMac
Model Identifier: iMac12,1
Processor Name: Intel Core i5
Processor Speed: 2.5 GHz
Boot ROM Version: IM121.0047.B1F
SMC Version (system): 1.71f22

If you have the time and inclination, to try setting WOMP to false on a vanilla machine, I would very much appreciate knowing if it has any effect.

Thanks!

[mash3d3d]

@BaddMann

Hi. I am interested in using your script as we are having the same issues here on our macs bound to an AD. I'm not too savvy with OSX just yet and I'm wondering how I can implement the script?

Many thanks.

[fabian_ulmrich]

We had almost the same problems and spend lots of hours in solving this. Obviously it was related to the power management settings as described by @rcarey912. We solved it by not allowing any sleep mode but display sleep. For now that's a very good workaround we can live with. And it's not really raising your energy costs if you schedule an auto power off as well as auto power on.

@mash3d3d Think that's not really a script. Try using the script from @rcarey912 via policy "once per computer" on "login" or "recurring check-in". This should work I think!

Cheers :)

Cheers!

[mash3d3d]

Great. The script from @rcarey912 worked!

Thanks.

[Nix4Life]

hey guys;

just checking if this has been fixed with the 10.9.5 update.

LS

[Johnny_Kim]

Had one teacher run the 10.9.5 update and still sees the issue.

[tstanton]

From Centrify's Support, in Aug 2014: " This problem can also be duplicated using the native Apple AD Plugin"; so it's not a Centrify issue. ".....
At the time of writing there is no resolution. (only workarounds)

Centrify has filed Apple Bug ID #16131717 for this issue.
This bug was accepted by Apple and marked as a duplicate of Bug 1645729.
"

[Abdelhafid]

I've been running into this issue aswell with mavericks 10.9.5. Disabling womp appears to work but I'd need to test it further. Has anyone else been running into this issue and found another way to fix it? The script looks interesting but I'm not sure if it's feasible for lab macbooks. I've been seeing this when using the native Apple AD plugin btw. Any advice is much appreciated.

[bezzoh]

Anyone else seeing this with El Capitan? I've recently upgraded a bunch of iMacs to 10.11 and they seem to be having the exact same problem. You can log in fine from boot-up, but any Macs left around a while just freeze at login screen (and the username/password box just kinda dims a little but never disappears). Just had a reported that a whole room full exhibited the same behaviour.

I'd so far disabled all disksleep settings, etc (though hadn't disabled womp yet). Getting me down a bit this one.