问在MacOS (或Linux)中，如何研究哪个进程会导致膝上型计算机睡眠模式中的唤醒？

EN

读取日志文件是调试问题的最佳方法。

因此，在终端中尝试这个命令来获取系统日志，这将告诉您“唤醒”历史记录。

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

要了解觉醒的原因：

macOS Sierra，Mojave，Catalina和更新版本

log show |grep -i "Wake reason"

或者是MacOS El Capitan，Yosemite，小牛和更年长的

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

，那么这些唤醒原因代码是什么意思？

• OHC:代表开放主机控制器，通常是USB或Firewire。如果您看到OHC1或OHC2，几乎可以肯定是外部USB键盘或鼠标唤醒了机器。
• EHC:代表增强主机控制器的是另一个USB接口，但也可以是无线设备和蓝牙，因为它们也在Mac的USB总线上。
• USB :一个USB设备唤醒了机器
• LID0:，这实际上是你的MacBook或MacBook Pro的盖子，当你打开盖子，机器从睡梦中醒来。
• PWRB : PWRB表示电源按钮，这是Mac上的物理电源按钮
• RTC:实时时钟报警器，通常来自于按需唤醒服务，比如当你通过节能控制面板安排睡眠和在Mac上醒来时。它还可以来自启动设置、用户应用程序、备份和其他预定事件。

可能还有其他一些代码(如PCI、GEGE等)，但以上是大多数人在系统日志中会遇到的代码。一旦你发现了这些代码，你就可以真正缩小导致Mac从睡眠中醒来的原因，这似乎是随机的。

希望这会有所帮助:)

这个答案是基于Linux的，所以它可能并不严格适用于Mac。为了确定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

脚本的变体将取决于您的shell。特别是，在最后一行中，您可能会以另一种方式运行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吗

在这里，我记录了我的系统方法。它大致是基于@vijay-rajpurohit的答案，并且是由@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，我发现了以下命令：

1. pmset -g log有用的统计“总体睡眠/唤醒自启动”。
2. 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

简而言之，在一种系统的方法中，我根据日志搜索了以下关键字，并对每个关键字进行了搜索：

• 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，否则无法执行此操作。我在这里不写指令，因为它需要小心，您需要稍后启用它。

(待更新)