CODEWITHSUNDEEP
linuxmacos-mojavepower-managementreal-time-clockstandby
Sohail Si
Sohail Si

Reputation: 2976

How to investigate which process causes wakeups during laptop sleep-mode in MacOS (or Linux)?

My MacBook spontaneously wakes up from sleep mode with high fan activity.

I want to do a investigate this in RTC or power settings? Or by strace-ing of processes, etc (using some process/kernel magic!).

Hint: It is probably managed by "rtcwake".

I am not even sure if this is a scheduled task, or from a WiFi wakeup, or something else.

I don't want guesses about what usually causes this in Mojave, etc. Instead: I need to do a systematic investigation on this on my MacOS (Mojave). Linux-related answers are also appreciated.

This is about system standby, sleep-mode, suspended mode. (Note that this is not about standup and wakeup of individual processes. The whole laptop turns on spontaneously.)

Upvotes: 6

Views: 7637

Answers (3)

Sohail Si
Sohail Si

Reputation: 2976

Here I am documenting my systematic approach. It is loosely based on, and initiated by, the answer by @vijay-rajpurohit, which is in turn based on comment by @Robert @1431720 . Note that the final result is particular to my MacOS machine, based on the logs shown below. It will be different in your MacOS.

In first attempt, I first checked the logs using: log show --style syslog | grep ... but it is taking too long. I accidentally checked /var/log/wifi.log after exploring the /var/log/ (I am also curious about /var/log/powermanagement/*.asl).

This turned out to be most useful:

  1. cat /var/log/wifi.log|grep -i "Wake reason"

Then found this line: (note the EC. bit)

Thu Apr 23 22:41:32.359 Info: <airportd[219]> _systemWokenByWiFi: System wake reason: <EC.ARPT>, was woken by WiFi

Then googled for EC.ARPT, I found the following commands:

  1. pmset -g log Useful stats about "Total Sleep/Wakes since boot".
  2. pmset -g assertions This turned out to show the full answer to this question:
2020-04-24 02:23:38 +0100 
Assertion status system-wide:
   BackgroundTask                 1
   ApplePushServiceTask           0
   UserIsActive                   1
   PreventUserIdleDisplaySleep    0
   PreventSystemSleep             0
   ExternalMedia                  0
   PreventUserIdleSystemSleep     0
   NetworkClientActive            0
Listed by owning process:
   pid 111(hidd): [0x0000200a000986a9] 00:00:00 UserIsActive named: "com.apple.iohideventsystem.queue.tickle.4295010950.3" 
   pid 85(apsd): [0x0003b830000b90bd] 00:00:10 ApplePushServiceTask named: "com.apple.apsd-waitingformessages-push.apple.com" 
Kernel Assertions: 0x100=MAGICWAKE
   id=504  level=255 0x100=MAGICWAKE mod=24/04/2020, 01:57 description=en0 owner=en0
Idle sleep preventers: IODisplayWrangler

In short, in a systematic approach, I explored the following keywords based on the logs, and googled each :

  • EC.ARPT (example link)
  • iohideventsystem (example link)
  • MAGICWAKE (example link)
  • ApplePushServiceTask (see below)

Most informative item emerged from the output of pmset -g assertions. For example ApplePushServiceTask in the following line:

pid 85(apsd): [0x0003b830000b90bd] 00:00:10 ApplePushServiceTask named: "com.apple.apsd-waitingformessages-push.apple.com"

The solution that seems to work in my particular case (not a general solution) was to disable : /System/Library/LaunchDaemons/com.apple.apsd.plist using launchctl. But this cannot be done until you do a csrutil disable in the safe mode. I don't write instructions here because it need caution and you need to enable it later.

(to be updated)

Upvotes: 0

Vijay Rajpurohit
Vijay Rajpurohit

Reputation: 1352

Reading the log file is the best way to debug the problem.

So, try this command in your Terminal to fetch the system logs, this will tell you "wake up" history.

log show --style syslog | fgrep "Wake reason: EC.LidOpen"

To see the wake reason:

For macOS Sierra, Mojave, Catalina, and newer

log show |grep -i "Wake reason"

Or for MacOS El Capitan, Yosemite, Mavericks, and older

syslog |grep -i "Wake reason"

This will look like:

MacBookPro kernel[0] : Wake reason = OHC1
MacBookPro kernel[0] : Wake reason = PWRB
MacBookPro kernel[0] : Wake reason = EHC2
MacBookPro kernel[0] : Wake reason = OHC1

So what do these wake reason codes mean?

  • OHC: stands for Open Host Controller, is usually USB or Firewire. If you see OHC1 or OHC2 it is almost certainly an external USB keyboard or mouse that has woken up the machine.
  • EHC: standing for Enhanced Host Controller, is another USB interface, but can also be wireless devices and bluetooth since they are also on the USB bus of a Mac.
  • USB: a USB device woke the machine up
  • LID0: this is literally the lid of your MacBook or MacBook Pro when you open the lid the machine wakes up from sleep.
  • PWRB: PWRB stands for Power Button, which is the physical power button on your Mac
  • RTC: Real Time Clock Alarm, is generally from wake-on-demand services like when you schedule sleep and wake on a Mac via the Energy Saver control panel. It can also be from launchd setting, user applications, backups, and other scheduled events.

There may be some other codes (like PCI, GEGE, etc) but the above are the ones that most people will encounter in the system logs. Once you find out these codes, you can really narrow down what is causing your Mac to wake up from sleep seemingly at random.

Hope this will help :)

Upvotes: 5

sancho.s ReinstateMonicaCellio
sancho.s ReinstateMonicaCellio

Reputation: 15571

This answer is based on Linux, so it might not apply strictly to Mac. To determine whether rtcwake is responsible for your MacOS wakeups, you could replace the executable (in my Ubutnu it is /usr/sbin/rtcwake) with a wrapper script that leaves a sign of rtcwake having run, e.g.

$ cd /usr/sbin/rtcwake
$ sudo mv rtcwake rtcwake_orig

and then write script /usr/sbin/rtcwake containing

#!/bin/bash
touch $HOME/rtcwake_ran
/usr/sbin/rtcwake_orig

Variants of the script would depend on your shell. In particular, in the last line you would possibly run rtcwake in some alternative way, so as to not own the process (nohup / disown). See https://unix.stackexchange.com/questions/152310/how-to-correctly-start-an-application-from-a-shell

To inspect possible causes of wakeup, you can check various relevant logs, at /var/log. E.g., syslog*, acpi*. See also https://unix.stackexchange.com/questions/83036/where-is-the-log-for-acpi-events

Do you have wakeonlan?

Upvotes: 1

Related Questions