Want to highlight a helpful answer? Upvote!

Did someone help you, or did an answer or User Tip resolve your issue? Upvote by selecting the upvote arrow. Your feedback helps others! Learn more about when to upvote >

Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

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

I updated from Lion to Mountain Lion yesterday. Since then I am totally unable to bring my Mini to sleep. Does anyone has a similar problem ?

Mac mini, OS X Mountain Lion, i5 + i7, @TV 3, iPhone 4S, iPad2

Posted on Jul 26, 2012 1:37 AM

Reply
61 replies

Aug 2, 2012 7:12 PM in response to Jan C

Jan, you could try manually editing org.isc.named.plist like so:


sudo /Applications/TextEdit.app/Contents/MacOS/TextEdit


then open /System/Library/LaunchDaemons/org.isc.named.plist and change the lines which look like this:


<key>Disabled</key>

<false/>


to this:


<key>Disabled</key>

<true/>


Then save that file and use launchctl to unload it as before (or reboot). That should prevent it from being reloaded.

Aug 4, 2012 11:31 AM in response to Grid Peer

Thanks for the advice, Grid Peer, but I've come to the conclusion that the problem is not in having the BIND server running, but in what Apple has implemented in ML. In fact, in the past, I have kept (and still keep) a BIND server running on 4 of my machines in many iterations of OS X (iBook (G4), 10.5 [Slave]; Mac Mini (Core Duo), 10.6 [Master]; iMac (mid 2007), 10.8 [Slave]; Mac Mini (early 2009), 10.8 [Slave]) as I have an internal network with the ability for each machine to use its own DNS server if the master falls over. Prior to 10.8 I was able to put the latter 2 machines to sleep ... and now I can't; THAT is the problem and it is caused by the fact that Apple has re-jigged the way it invokes the launchd sequence of operations. In the LaunchDaemons plist, there doesn't appear to be any indication of the requirement to prevent sleep, so that new requirement has obviously been invoked at a different point in the boot sequence. I wish to decide what does and what does not prevent sleep on a client (not server) ML machine and that is my dilemma!

Aug 5, 2012 1:49 PM in response to jbjoret

had the same issues after upgrading my mac mini used for afp shares and time machine to Mountain Lion Server.

the key for filesharing prevent sleep is in:


/Applications/Server.app/Contents/ServerRoot/System/Library/LaunchDaemons/com.ap ple.server.filesharing.plist


set the key "PreventSystemSleep" to "No" and after reboot ML Server will sleep fine dispite active filesharing.

Aug 5, 2012 4:04 PM in response to otmarj

Perhaps I should have started a new thread to deal with the fact that my problem is on a client machine, not one running ML Server. Nevertheless, the issue is related to both, so it is perhaps best left in the one thread?


Anyway, looking at my system log, when I rebooted this evening, I got (a snippet of the sequence):


Aug 5 22:32:34 localhost kernel[0]: BSD root: disk0s2, major 1, minor 2

Aug 5 22:32:34 localhost kernel[0]: Kernel is LP64

Aug 5 22:32:34 localhost kernel[0]: USBMSC Identifier (non-unique): 2006087682053402AA28 0x781 0x5530 0x126

Aug 5 22:32:34 localhost kernel[0]: Waiting for DSMOS...

Aug 5 22:32:03 localhost com.apple.launchd[1]: *** launchd[1] has started up. ***

Aug 5 22:32:03 localhost com.apple.launchd[1]: *** Shutdown logging is enabled. ***

Aug 5 22:32:17 localhost com.apple.launchd[1] (com.parallels.desktop.launchdaemon): Unknown key for boolean: HopefullyExitsFirst

Aug 5 22:32:17 localhost com.apple.launchd[1] (com.stclairsoft.DefaultFolderXAgent): Unknown key for string: Version

Aug 5 22:32:17 localhost com.apple.launchd[1] (com.stclairsoft.DefaultFolderXAgent): Unknown key: Version

Aug 5 22:32:17 localhost com.apple.launchd[1] (com.apple.automountd): Unknown key for boolean: NSSupportsSuddenTermination

Aug 5 22:32:33 localhost hidd[45]: Posting 'com.apple.iokit.hid.displayStatus' notifyState=1

Aug 5 22:32:33 localhost distnoted[70]: # distnote server daemon absolute time: 33.702752677 civil time: Sun Aug 5 22:32:33 2012 pid: 70 uid: 0 root: yes

Aug 5 22:32:34 localhost hidd[45]: void __IOHIDLoadBundles(): Loaded 0 HID plugins

Aug 5 22:32:33 localhost fseventsd[46]: event logs in /.fseventsd out of sync with volume. destroying old logs. (259125 32 259176)

Aug 5 22:32:33 localhost named[66]: starting BIND 9.8.1-P1 -f -c /etc/named.conf

Aug 5 22:32:34 localhost named[66]: built with '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--disable-dependency-tracking' '--prefix=/usr' '--sysconfdir=/private/etc' '--localstatedir=/private/var' '--enable-atomic=no' '--with-openssl=yes' '--with-gssapi=yes' '--enable-symtable=none' 'CC=/Applications/Xcode.app/Contents/Developer/Toolchains/OSX10.8.xctoolchain/u sr/bin/cc' 'CFLAGS=-arch i386 -arch x86_64 -g -Os -pipe -gdwarf-2 ' 'LDFLAGS=-arch i386 -arch x86_64 -framework IOKit -framework CoreFoundation' 'CXX=/Applications/Xcode.app/Contents/Developer/Toolchains/OSX10.8.xctoolchain/ usr/bin/c++' 'CXXFLAGS=-arch i386 -arch x86_64 -g -Os -pipe '


However, checking for loaded launchd plist files (launchctl list), 'org.isc.named.plist' is not to be found. In fact, attempting to unload that plist causes an error, while loading it creates a second instance of the DenySystemSleep notice! Clearly PID 66 (every boot, always the same!) is not loaded from the /System/Library/LaunchDaemons folder! Which means that OS X 10.8 has a separate list of launch files that it works from, irrespective of the state of the default files in that folder; where is that list?


Anyone any ideas?

Aug 6, 2012 2:49 PM in response to Jan C

Okay, I've found my own error! I had a second launchd property list from a previous installation that I had permitted - inadvertently - to remain loaded. It was loading BIND at boot! I unloaded that property list and loaded the one I had previously found gave a second instance ... and rebooted. It, too, came up with the DenySystemSleep assertion, but that disappeared when I unloaded org.isc.named.plist and rebooted.


So, now, everything seems to be working as it should .... except that I still actually want the BIND server to run, but I don't want it to prevent system sleep. I've not been able to find <PreventSystemSleep> as a key in the man page for either launchctl or launchd and am not sure if it would do any harm just inserting it to try; any advice?

Aug 6, 2012 11:19 PM in response to otmarj

Unfortunately, 'PreventsSleep' doesn't work, either! Neither does 'PreventSleep' or 'DenySleep'! It must be something like that, though, mustn't it? Has anyone found the full list of valid key words for ML yet? Alternatively, what criterion does Apple use to determine which daemon will prevent sleep, if that is not determined by the property list default keys?


BTW, I've been using 'False' with the keys I've tried; is that correct?

Aug 8, 2012 7:06 AM in response to Jan C

I have been carrying out a little more research and have found that starting the BIND server as root without utilising launchctl from the Terminal results in the DenySystemSleep assertion associated with org.isc.named.denysystemsleep just as before. Clearly, named has been compiled with the restriction already built-in, but it's difficult to know where. The log entry on starting shows:


built with '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--disable-dependency-tracking' '--prefix=/usr' '--sysconfdir=/private/etc' '--localstatedir=/private/var' '--enable-atomic=no' '--with-openssl=yes' '--with-gssapi=yes' '--enable-symtable=none' 'CC=/Applications/Xcode.app/Contents/Developer/Toolchains/OSX10.8.xctoolchain/u sr/bin/cc' 'CFLAGS=-arch i386 -arch x86_64 -g -Os -pipe -gdwarf-2 ' 'LDFLAGS=-arch i386 -arch x86_64 -framework IOKit -framework CoreFoundation' 'CXX=/Applications/Xcode.app/Contents/Developer/Toolchains/OSX10.8.xctoolchain/ usr/bin/c++' 'CXXFLAGS=-arch i386 -arch x86_64 -g -Os -pipe '


...but there is nothing there that I can link to the phenomenon. I have seen on another thread that it might be possible to install a more recent version of BIND (9.8.3-P2) from http://www.isc.org/software/bind/ using the 'configure' options previously used for BIND in 10.7.4 (to be found at http://opensource.apple.com).


If anyone has any other thoughts..........

Aug 9, 2012 5:13 AM in response to Jan C

It's in bind9-44/bind9/bin/named/main.c (from opensource.apple.com), lines 851-853:


#ifdef __APPLE__

IOPMAssertionCreateWithName(kIOPMAssertionTypeDenySystemSleep, kIOPMAssertionLevelOn, CFSTR("org.isc.named.denysystemsleep"), &named_IOPMSleepAssertion);

#endif


and cleanup code is in lines 900-903.


It should be possible to delete those lines and compile a proper behaving named.

Aug 9, 2012 7:09 AM in response to rasc2003

Sorry, I've been away for a few days. Anyways, this is what I meant when I mentioned earlier that named has sleep prevention "baked in". Meaning, that it's hardcoded rather than set via a configuration file.


So if you absolutely need named running, then the only option (for now) if you want your system to sleep is to recompile it as rasc2003 describes and replace the stock version which comes with ML.


If you're ambitious, you could try to find the code which parses the plist files, and pass the 'PreventsSleep' setting on to named. Then make the call to IOPMAssertionCreateWithName() conditional based on that setting. Be sure to send a patch to Apple if you do. 😁

Aug 12, 2012 9:11 AM in response to Jan C

Strange! I was notified of a reply (sent today at 13:07 GMT) from jas1; the email contained the message


"Hi Jan C - I have the exact same problem as you - upgraded from Lion Server to vanilla Mountain Lion - but i am far less technical than you seem to be. Have you figured a work around I can understand? I can also not unload org.isc.named.plist"


but I can't find it anywhere in this thread! Anyway, to answer the question, my temporary workaround is not to have the BIND server running on my 2 main client machines (Mac Mini (Miniskuell) and iMac (Intrepid)) until I (or Apple) can sort the problem out.


To my mind, there are a couple of issues that need to be resolved:


1. We, the punters, need to be told what ML uses as the criterion that sets up the assertion that denies system sleep. We also need to know why it is inserted for BIND (for example) but not for Apache2, the web server.


2. We, the punters, need to know how we can use this new facility that will give an application the authority to prevent system sleep .... or any other thing, one might surmise!


When those questions are answered, we can think more clearly about setting up a proper workaround!

Aug 13, 2012 1:33 AM in response to rasc2003

For some reason, the reply from rasc2003 didn't appear in the thread ... and I even lost my own responses ... so inserted my reply yesterday afternoon without the information given (making my response totally superfluous!!).


I think I'll try a re-compile, but after comparing the source available from isc.org with that available from opensource.apple.com.


My thanks for the information, which answers all my questions!! 🙂

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

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple ID.