OSX Mountain Lion sleep issues

[nonnoroger]

OSX Mountain Lion (ML) has an idle sleep policy that requires apps to set sleep assertions if they want to prevent sleep after the period set in Energy Saver - see for example http://arstechnica.com/apple/2012/07/os-x-10-8/18/. This means that utilities I relied on under Lion - Caffeine and ReallyPreventStandby plugin for LMS no longer work.

There is a new command line utility in ML that might give some pointers to a way forward:

caffeinate – prevent the system from sleeping on behalf of a utility
This allows you to either directly prevent your Mac from falling asleep for a specific period of time (e.g. an hour):

caffeinate -u -t 3600

or allows a command to run for a prolonged period without the automatic (and, since 10.8, rather aggressive) sleep function kicking in

caffeinate -s any-long-running-command -with arguments

The source of caffeinated seems to be here: http://opensource.apple.com/source/P...ment-271.25.8/

Has anyone else had sleep issues under ML running LMS (I am running 7.7.2)?

Does anyone who knows the system better than me have any suggestions for a way forward?

Seems like these new assertions could finally give a reliable solution to LMS sleep issues under OSX if they could be incorporated somehow. I do not think it will work just for ReallyPreventStandby to call caffeinate as the command just hangs until interrupted if called as caffeinate -i.

All help much appreciated.

[gharris999]

OSX Mountain Lion (ML) has an idle sleep policy that requires apps to set sleep assertions if they want to prevent sleep after the period set in Energy Saver - see for example http://arstechnica.com/apple/2012/07/os-x-10-8/18/. This means that utilities I relied on under Lion - Caffeine and ReallyPreventStandby plugin for LMS no longer work.

There is a new command line utility in ML that might give some pointers to a way forward:

caffeinate – prevent the system from sleeping on behalf of a utility
This allows you to either directly prevent your Mac from falling asleep for a specific period of time (e.g. an hour):

caffeinate -u -t 3600

or allows a command to run for a prolonged period without the automatic (and, since 10.8, rather aggressive) sleep function kicking in

caffeinate -s any-long-running-command -with arguments

The source of caffeinated seems to be here: http://opensource.apple.com/source/P...ment-271.25.8/

Has anyone else had sleep issues under ML running LMS (I am running 7.7.2)?

Does anyone who knows the system better than me have any suggestions for a way forward?

Seems like these new assertions could finally give a reliable solution to LMS sleep issues under OSX if they could be incorporated somehow. I do not think it will work just for ReallyPreventStandby to call caffeinate as the command just hangs until interrupted if called as caffeinate -i.

All help much appreciated.

I'll be happy to look at the source for caffeinate and see if what it's doing could be incorporated into ReallyPreventStandby. But I don't have Mnt Lion yet and living on the wrong side of the digital divide means that it might be some time before I get it. Need to find someplace in town where I can set up my mac mini and download it.

[nonnoroger]

I'll be happy to look at the source for caffeinate and see if what it's doing could be incorporated into ReallyPreventStandby. But I don't have Mnt Lion yet and living on the wrong side of the digital divide means that it might be some time before I get it. Need to find someplace in town where I can set up my mac mini and download it.

Good luck with that and very many thanks for picking this one up.

[danco]

I don't have Mountain Lion yet, but I wonder if my old solution would work.

There was a little program called Jiggler that prevented sleep by simulating a mouse movement every minute or so. I wrote a very simple shell script to start and quit Jiggler, and then I used Server Power Control to run these scripts at the relevant moments.

[nonnoroger]

I don't have Mountain Lion yet, but I wonder if my old solution would work.

There was a little program called Jiggler that prevented sleep by simulating a mouse movement every minute or so. I wrote a very simple shell script to start and quit Jiggler, and then I used Server Power Control to run these scripts at the relevant moments.

Thanks for the reminder about Jiggler Danco.

I have now downloaded 1.4 and tried it under Mountain Lion (bypassing the warning that it does not have a developer signature). ML really does have an aggressive sleep policy as Jiggler jiggles but does not prevent sleep.

I would have been happy to use it as an interim solution if it had worked, but I remember now why I started using Caffeine - those mouse jiggles are disconcerting for anyone else in the family who comes to use my Mac Mini while Jiggler is running.

The way ahead with ML does seem to be with the assertions.

[nonnoroger]

Well, it dawned on me that we should be able to invoke caffeinate as it is from ReallyPreventStandby instead of Gordon's sleep-inhibit (although I see from the source of this that it was also using assertions, but differently from caffeinate and presumably not in a way that works under Mountain Lion).

ReallyPreventStandby has these settings:

Allow standby after how many idle minutes?
Prohibit standby if players are on?
Inhibit standby command
Re-enable standby command
Inhibit is a toggle command

Under OSX, by default, the inhibit command is set to sleep-inhibit with a period of 60 seconds. There is no re-enable command and the inhibit command is not a toggle (meaning it gets called periodically - I guess every 60 seconds or thereabouts).

My first try was to set these as: /us/bin/caffeinate -i (which creates an assertion to prevent the system from idle sleeping), pkill caffeinate, and command is a toggle. But found that caffeinate was not getting invoked (I do not know why).

So instead I am now using: /usr/bin/caffeinate -i -t 60 (create the assertion for 60 seconds), no re-enable command, and inhibit is not a toggle.

This now seems to be working! Well, after about 30 minutes of listening I did get the system going into standby while playing once. Just wondering if this was due to one invocation of caffeinate terminating before a new one is started.

Gordon - I notice that usually a second caffeinate is invoked before the previous one times out. Is this intentional/designed? Is the 60 seconds a built-in period for the re-invocaction? Any ideas why I could not get it working as a toggle?

By the way, I have my system sleep time set to 10 minutes. I am currently running with ReallyPreventStandby set to preventing standby if players are on - when I had the system going into standby while playing this setting was off.

I will try it for a couple of days and then post again.

[nonnoroger]

I will try it for a couple of days and then post again.

No need to wait a couple of days. My Mac Mini is still going to sleep sometimes while LMS is playing to a SB (Touch). For a while ReallyPreventStandby, invoking caffeinate, does prevent standby beyond my system idle timer. But sometimes it just goes to sleep.

I strongly suspect that this is a glitch that comes with the repeated calls of caffeinate. Caffeinate -i called directly from the command line has never yet allowed sleep.

[danco]

OSX Mountain Lion (ML) has an idle sleep policy that requires apps to set sleep assertions if they want to prevent sleep after the period set in Energy Saver - see for example http://arstechnica.com/apple/2012/07/os-x-10-8/18/. This means that utilities I relied on under Lion - Caffeine and ReallyPreventStandby plugin for LMS no longer work.

I'm sure you know what's happening on your own machine.

But I see that the Roaringapps compatibility table lists Caffeine as compatible with Mountain Lion. If it's not, maybe you should report it there.

I've just installed ML on an external drive, not my main one, so I'll check some time what result I get.

[nonnoroger]

I'm sure you know what's happening on your own machine.

But I see that the Roaringapps compatibility table lists Caffeine as compatible with Mountain Lion. If it's not, maybe you should report it there.

I've just installed ML on an external drive, not my main one, so I'll check some time what result I get.

Hmmm. I had hoped I knew what was happening on my own machine. But prompted by your post I have just tried it again to find it did prevent sleep beyond my set idle timer.

It seems that I am not the only one to report it failing to prevent sleep though - see the replies to this post: http://hints.macworld.com/article.ph...20801003744629.

I have emailed the developers but have not had a reply. I will hold off for things to clarify before contacting Roaringapps.

Note though that caffeine is not useful for LMS use as it also stops the screen from blanking (when it works!)

[gharris999]

Gordon - I notice that usually a second caffeinate is invoked before the previous one times out. Is this intentional/designed? Is the 60 seconds a built-in period for the re-invocaction? Any ideas why I could not get it working as a toggle?

By the way, I have my system sleep time set to 10 minutes. I am currently running with ReallyPreventStandby set to preventing standby if players are on - when I had the system going into standby while playing this setting was off.

I will try it for a couple of days and then post again.

Truthfully, I never did take ReallyPreventStandby's code to a "finished" state. The toggle feature was supposed to be a execute:first == inhibit sleep, execute:again == uninhibit. But I don't recall if I really fleshed that feature out or not. I'd have to review the code and, frankly, I don't even have a copy of ReallyPreventStandby currently installed on any of my LMS boxes.

Lately, I've been giving SrvrPowerCtrl a little more attention. The next version to hit my beta repo will include a feature to check for active login sessions on both Linux and OSX and optionally inhibit power saving when it sees one. Could that work for you? Could you train yourself and family members to always remember to logout when finished using the Mac? Under this scenario, you'd disable all or most of the OS X power management features and let SrvrPowerCtrl take care of business.