Mac Mini Server (2011) won't go to sleep anymore

Same problem here. If I follow the proposed solution

sudo launchctl unload -w /System/Library/LaunchDaemons/org.isc.named.plist

the the Mac Mini goes to sleep but then after awake the Internet Connection gets lost. I have solved this by running

sudo launchctl load -w /System/Library/LaunchDaemons/org.isc.named.plist

after the Mac Mini awakes. But this can only be a workaround.

Do you have Internet Connection Sharing enabled?

I see there is now a warning, that the computer will not go into sleep mode, as long as ICS is enabled.

The other thought which crossed my mind is that perhaps everyone is running the server version of Mac OS X? In which case, it might make sense that these daemons would keep the system awake.

In my case, I originally installed Lion as the server version, then later changed it to the regular version using instructions I found on the Apple developer forums. However, after I upgraded to Mountain Lion, I noticed that the Startup Disk preference pane was showing it as "OS X Server, 10.8". Deleting /Applications/Server.app fixed that, but if my theory is correct, then perhaps my daemons are configured for the server version?

I've been having the same issues with my Mac Mini after installing Mountain Lion, that it won't go to sleep, and when I does, I can't get it to wake up, and I have to force re-start it. I did take it into Apple and they saw that the Sleep Image was missing, which is something that, if missing, should reappear with a reboot. Not the case here. They had never seen this before in the store and suggested that I do a reinstall, which I have yet to do. I wanted to see if others have been having this issue and any other potential fixes. I'll try the re-install and report back.

I installed Mountian lion it was sleeping fine .

Now I installed Server ML and system cannot sleep, Screen goes black but computer keep running no sleep.

My Lion server used to sleep fine . May be some bug in the server ML ?

Hey I just wanted to say thank you, you saved me from having to reinstall ML hoping that sleep would work 🙂 I did notice however that ML takes "significantly" longer to actually sleep (15 or so seconds maybe) as compared to maybe 3-5 seconds in Lion server, oh well I can live with that. Thanks again.

I have a Mac Mini (early 2009) and iMac (mid 2007), both upgraded from Lion 10.7.4 to Mountain Lion (NOT Server). Prior to the upgrade, both would sleep when instructed (power button, Apple menu, Energy Saver Schedule), but now neither sleep (although the display on each machine WILL go to sleep).On the Mac Mini, I have run 'pmset' and ascertained that one of the assertions was:

pid 67(named): [0x000000080000012d] 64:41:54 DenySystemSleep named: "org.isc.named.denysystemsleep"

However, I had already unloaded the BIND plist, so am concerned that Apple has inserted something else into the system. Also, looking at the system log, I cannot find anything at the instant that I select sleep (button or apple menu) that would suggest a problem. This appears to be something that Apple needs to tackle!

I don't know if it's a bug or intentional. Considering that a true "server" is a machine which is supposed to perform tasks like network routing, network file access, email routing, etc. 24/7 unattended, it would make sense that networking daemons like named would cause it to stay awake. You don't really want your server going to sleep on you and cutting off network services for everyone on the network.

That said, there should be a better way to configure this behavior other than stopping the daemons completely.

I notice on my Mac Pro that the white power light shows the machine as asleep (pulsing) right away after I put it to sleep. However, the fans continue to hum for about 15 seconds or so before stopping. So yeah, definitely a bit slower to get to a full sleep than Lion was.

I've been playing around with my situation a bit (loading and unloading the daemon with different plist settings) and have noticed that sometimes launchctl doesn't actually stop the daemon. In which case, I've resorted to using the kill command to stop it. In the case you're showing:

pid 67(named): [0x000000080000012d] 64:41:54 DenySystemSleep named: "org.isc.named.denysystemsleep"

you'd do the following:

sudo kill -s HUP 67

Using launchctl is preferable because it's cleaner (and persists across reboots), but sometimes you have to use brute force. 🙂

Also, using SIGHUP is the nicest way to do it. If that doesn't work, you can substitute TERM or KILL for HUP. Those are pretty much guaranteed to stop it, but they may cause an "unclean" stop if named was in the process of writing to a file (or similar) when you killed it. So use TERM and KILL only as a last resort.

Under Server.app the LDAP daemon uses internal SPI to explicitly disallow sleep. If you do not need to use your computer as an LDAP server, then configure your system to not launch slapd.

If you do need to use slapd, then you'll have to manually turn it off, and make sure that process slapd is killed or not running, every time before you put your system to sleep.

Your system will only sleep if slapd is not running.

Thanks for the info. I figured that sleep prevention might be baked into the network daemons when running OS X as a server.

For me I upgraded from Lion Server to Mountain Lion client (so I guess you can say I am not running ML as a server) yet I was still getting the non-sleeping behavior, rasc2003 solution worked for me, I am fairly new to OS X so I don't really the extent of "missing behavior" as a result of executing:

sudo launchctl unload -w /System/Library/LaunchDaemons/org.isc.named.plist

But at least that way I can put it to sleep. I also measured the time from selecting "Sleep" in the menu to fans stopping.. came in at exactly 30 seconds, way longer than I remember on Lion.

Another thing I noticed, I had itunes "Sync this iPhone over wifi" on, whenever I connected my iPhone to power, the mini would wake up from sleep with the display turned off (to sync I guess), I don't remember this happening with Lion (but maybe it was and I never noticed it), fixed that one by unchecking sync over wifi.

I ran sudo launchctl unload -w /System/Library/LaunchDaemons/org.isc.named.plist and came up with an error that signified that it was already unloaded (launchctl: Error unloading: org.isc.named).

I then loaded (launchctl load -w /System/Library/LaunchDaemons/org.isc.named.plist) and unloaded (launchctl unload -w /System/Library/LaunchDaemons/org.isc.named.plist) again, this time without error, at least in Terminal.

I then ran pmset -g assertions and found pid 49495(named): [0x0000000800000eaf] 00:43:46 DenySystemSleep named: "org.isc.named.denysystemsleep" in the list, even though there is no sign of the PID file in /private/var/run/named!

Loading (launchctl load -w /System/Library/LaunchDaemons/org.isc.named.plist) again and running pmset -g assertions shows not just pid 49495(named): [0x0000000800000eaf] 00:43:46 DenySystemSleep named: "org.isc.named.denysystemsleep" in the list, but also pid 49986(named): [0x0000000800000eaf] 00:43:46 DenySystemSleep named: "org.isc.named.denysystemsleep"; at this point, the PID file (49986) reappears in the correct location, together with a session.key file. It would therefore appear that the launchctl actions are not acting on the original item. As soon as I attempt to 'kill' PID 49495, a different process is started and the BIND server restarts.

That may all sound very confusing and, believe me, it IS! I really am at a loss to understand what is going on and think the only way out is to carry out a clean install of ML and see what happens!

On other forums, I've seen reports from people that fixed it by doing a second clean install of ML, I know I was ready to do that yesterday before I stumbled on the thread here.

Notice from above that people are talking about "two" different daemons, some are stopping ics and some are stopping slapd, you may want to try both before you revert to the painful reinstall solution.