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

Question

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.)

Nous

Have you checked the system logs in /var/log/syslog (Linux) or /var/log/system.log (Mac)? – Scanties

This was actually helpful. various logs mentioning: ASL database, com.apple.asl, – Nous

Apr 21 00:27:20 9858770s-MacBook-Pro syslogd[40]: ASL Sender Statistics Apr 21 00:30:00 9858770s-MacBook-Pro syslogd[40]: Configuration Notice: ASL Module "com.apple.cdscheduler" claims selected messages. Those messages may not appear in standard system log files or in the ASL database. Apr 21 00:30:00 9858770s-MacBook-Pro syslogd[40]: Configuration Notice: ASL Module "com.apple.install" claims selected messages. Those messages may not appear in standard system log files or in the ASL database. ... – Nous

Mentions: ASL Sender Statistics, ASL modules: "com.apple.cdscheduler", "com.apple.install", "com.apple.family.asl", "com.apple.callhistory.asl.conf", "com.apple.contacts.ContactsUICore", "com.apple.authd", "com.apple.asl", ... – Nous

Answer 1

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 :)

Asphyxia

This led me to the answer (although it was different on my machine, and on different logs, namely /var/log/wifi.log ). However, the bounty just got expired – Nous

No worries, I'm glad it helped you :) – Asphyxia

Answer 2

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?

Avlona

Instead of nohup/disown, just pass the path of org to exec which replaces "this process" with orig. – Agueda

Thank you for the answer, however, I don't currently have a Linux on a physical device to check or verify the answer. – Nous

@SohailSi - Ok. I followed "Linux-related answers are also appreciated." – Avlona

Answer 3

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:

2. pmset -g log Useful stats about "Total Sleep/Wakes since boot".
3. 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)

Nous

Better command: log show --style syslog --last 1h | fgrep "Wake"log show --style syslog --last 1h | fgrep "Wake" – Nous

AskDifferent link: "MacBook Pro 2018 switch from sleep to DarkWake in loop. How to diagnose?" apple.stackexchange.com/questions/334202/… – Nous

macobserver.com/tmo/article/… – Nous

sudo pmset -b tcpkeepalive 0sudo pmset -b tcpkeepalive 0 – Nous

sudo pmset -g will show valuable information but the items shown in the list are poorly documented. e.g. tcpkeepalive – Nous

from: reddit.com/r/MacOS/comments/9ovgq6/macbook_idle_draining – Nous

also useful details: reddit.com/r/MacOS/comments/9ogf17/… – Nous