I have installed Ubuntu 14.04 GNU/Linux on a MacBook Air (mid 2012). I'm trying to use rtcwake to implement a "delayed hibernation from suspend", as in https://askubuntu.com/a/33192 (the particular use case is not important here). But rtcwake, issued e.g. as,

sudo rtcwake --seconds 120  --mode mem

enters suspend (--mode mem) only for a few seconds (regardless of what the --seconds option says) and immediately returns. Both suspend and hibernate work correctly on this system, e.g. when triggered by pm-suspend or pm-hibernate (using the kernel's swsusp), or upon closing the lid. The machine keeps the time correctly and can show or update it in Ubuntu. The same command works as expected on another (non-Apple) machine with a similar GNU/Linux OS.

I know MAC OS X has this kind of feature to wake up from sleep at a preset time or after a preset duration. So, I believe, they are accessing an internal clock. My questions are (all related):

Is there some wake-up event occurring behind the scenes that's triggering this immediate wake-up? I doubt this could be the culprit, since, as I mentioned above, the machine suspends correctly otherwise. (But then again, suspending correctly otherwise could be possibly due to the offending module(s) being removed by a SUSPEND_MODULES hook before such "normal" suspend.) Also, the machine does not wake up from a normal suspend, triggered, e.g., by closing the lid, when a scheduled rtcwake says it should.

If there aren't any "hidden" wake-up events, how do I use this internal clock to trigger a scheduled wake-up from suspend in GNU/Linux, since rtcwake doesn't seem to be working? Is this clock RTC compatible to support standard driver model wakeup flags from a GNU/Linux tool? Are there any other methods/workarounds to achieve this result?

  • Did you try to wake up at given time (-t option)?
    – jimmij
    Jun 14, 2016 at 1:31
  • Yes, -t leads to the same result (wake-up after a second or two) as -s.
    – 0mid
    Jun 15, 2016 at 1:39

1 Answer 1


I have figured out the culprit. Doing cat /proc/acpi/wakeup, and disabling the *enabled devices one by one (using, e.g., sudo echo 'DEVABBRV' > /proc/acpi/wakeup, where DEVABBRV is the device abbreviation listed in the cat output above), it turns out that LID0 is waking up the machine "prematurely".

This is perhaps due to some non-standard, proprietary hardware sensor in the lid. Disabling the wake-up capability for LID0 (which could be made permanent by adding echo 'LID0' > /proc/acpi/wakeup to /etc/rc.local) makes rtcwake, and in particular sudo rtcwake --seconds 120 --mode mem, function as expected.

However, the problem still remains unsolved for my particular use case (with the script in https://askubuntu.com/a/33192), since rtcwake does not wake up the machine when run in that script.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .