Как выяснить, какой процесс вызывает пробуждения во время режима сна ноутбука в MacOS (или Linux)?

Question

Мой MacBook самопроизвольно выходит из спящего режима с высокой активностью вентилятора.

Я хочу исследовать это в RT C или в настройках питания? Или путем связывания процессов и т. Д. c (используя магию процессов / ядра c!).

Подсказка: вероятно, это управляется "rtcwake".

Я даже не уверен, что это запланированная задача, или из-за пробуждения по WiFi, или из-за чего-то еще.

Я не хочу догадываться о том, что обычно вызывает это в Mojave, et c. Вместо этого: мне нужно провести систематическое c расследование этого на моем MacOS (Мохаве). Также приветствуются ответы, связанные с Linux.

Речь идет о режиме ожидания системы, спящем режиме, режиме ожидания. (Обратите внимание, что речь идет не о включении и отключении отдельных процессов. Весь ноутбук включается самопроизвольно.)

Answer 1

Чтение файла журнала - лучший способ отладки проблемы.

Итак, попробуйте эту команду в вашем терминале, чтобы получить системные журналы, это скажет вам историю "пробуждения".

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

Чтобы увидеть причину пробуждения:

Для macOS Сьерра, Мохаве, Каталина и новее

log show |grep -i "Wake reason"

Или для MacOS El Capitan, Yosemite, Mavericks и старше

syslog |grep -i "Wake reason"

Это будет выглядеть так:

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

Так, что означают эти коды причины пробуждения?

• OH C: обозначает Open Host Controller, обычно это USB или Firewire. Если вы видите OHC1 или OHC2, это почти наверняка внешняя USB-клавиатура или мышь, которая разбудила машину.
• EH C: означает Enhanced Host Controller, это другой интерфейс USB , но также могут быть беспроводными устройствами и Bluetooth, поскольку они также находятся на шине USB Ma c.
• USB: USB-устройство разбудило машину
• LID0: это буквально крышка вашего MacBook или MacBook Pro, когда вы открываете крышку, когда машина выходит из спящего режима.
• PWRB: PWRB означает Power Кнопка, которая является кнопкой физического питания вашего Ma c
• RT C: Будильник с часами реального времени, как правило, из служб пробуждения по запросу, например, при планировании сна и проснуться на Ma c через панель управления Energy Saver. Это также могут быть настройки запуска, пользовательские приложения, резервные копии и другие запланированные события.

Могут быть и другие коды (например, PCI, GEGE и др. c), но приведенные выше что большинство людей встретит в системных журналах. Как только вы узнаете эти коды, вы действительно сможете сузить причины, по которым ваша мама c просыпается, казалось бы, случайно.

Надеюсь, это поможет:

Answer 2

Этот ответ основан на Linux, поэтому может не относиться строго к Ма c. Чтобы определить, отвечает ли rtcwake за ваши пробуждения в MacOS, вы можете заменить исполняемый файл (в моем Ubutnu /usr/sbin/rtcwake) сценарием-оболочкой, который оставляет знак запуска rtcwake, например,

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

, а затем напишите скрипт /usr/sbin/rtcwake, содержащий

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

Варианты скрипта будут зависеть от вашей оболочки. В частности, в последней строке вы могли бы запустить rtcwake некоторым альтернативным способом, чтобы не владеть процессом (nohup / disown). См. https://unix.stackexchange.com/questions/152310/how-to-correctly-start-an-application-from-a-shell

---

Чтобы проверить возможные причины пробуждения, вы можете проверить различные соответствующие журналы, на /var/log. Например, syslog*, acpi*. Смотрите также https://unix.stackexchange.com/questions/83036/where-is-the-log-for-acpi-events

---

У вас есть wakeonlan?

Answer 3

Здесь я документирую свой систематический c подход. Оно свободно основано и инициировано ответом @ vijay-rajpurohit, который, в свою очередь, основан на комментарии @Robert @ 1431720. Обратите внимание, что окончательный результат зависит от моего компьютера MacOS, основываясь на журналах, показанных ниже. В MacOS он будет другим.

При первой попытке я сначала проверил журналы, используя: log show --style syslog | grep ..., но это занимает слишком много времени. Я случайно проверил /var/log/wifi.log после изучения /var/log/ (мне также интересно узнать /var/log/powermanagement/*.asl).

Это оказалось наиболее полезным:

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

Затем нашел эту строку: (обратите внимание на EC. бит)

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

Затем, погуглив на EC.ARPT, я нашел следующие команды:

pmset -g log Полезные статистические данные о "Всего сна / пробуждений с момента загрузки". pmset -g assertions Получилось, чтобы показать полный ответ на этот вопрос:

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

Короче говоря, в систематическом c подходе я исследовал следующие ключевые слова на основе журналов и гуглил каждое:

• EC.ARPT (пример ссылка )
• iohideventsystem (пример ссылка )
• MAGICWAKE (пример ссылка )
• ApplePushServiceTask (см. Ниже)

Наиболее информативный элемент появился из вывода pmset -g assertions. Например, ApplePushServiceTask в следующей строке:

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

Решение, которое, кажется, работает в моем конкретном случае (не общее решение), было отключить: /System/Library/LaunchDaemons/com.apple.apsd.plist с использованием launchctl. Но этого нельзя сделать, пока вы не сделаете csrutil disable в безопасном режиме. Я не пишу здесь инструкции, потому что это требует осторожности, и вам нужно включить его позже.

(будет обновлено)