macOS Monterey Apple hat es nicht so wirklich drauf mit dem Ruhezustand!

[carsten_h]

Moin!

In der letzten Nacht habe ich meinen Mac mini M1 einmal in den Ruhezustand geschickt (um 00:05). Doch wenn ich mir die Verbrauchsauswertung in Home Assistant so ansehe, dann hat das kleine Kerlchen wohl eher unter der Bettdecke gelesen.
Um die Kurve zu erläutern:
Am Anfang die Werte zwischen 50-60W sind die wenn Handbrake lief, also den Prozessor und die GPU wirklich gut auslastet. Der Wert von 15W ist dann wenn der Mini wirklich schläft. Es sind 15W weil noch extern ein OWC Thunderbolt 3 Dock und ein USB Hub (stromversorgt) dranhängen an denen ein paar externe Platten (2) und SSD (3) hängen. Das OWC Dock kennt zwar einen Ruhezustand, aber so wenig verbraucht es wohl nicht und der USB Hub kenn halt keinen Ruhezustand.

Doch was verflucht macht der mini Nachts die ganze Zeit wenn der Verbrauch so bei 30W läuft?
Ja, es gibt eine Time Machine Sicherung (immer abwechselnd auf eine direkt angeschlossene Platte und ein NAS), aber dafür braucht er doch Nachts nicht 3,5 Stunden lang. Vor allem nicht, weil sich ja gar nichts geändert hat. Tagsüber läuft die Sicherung vielleicht fünf Minuten oder so, aber doch nicht Stunden.
Mails holen sollte auch nicht so lange dauern.

In den "Energie sparen" Einstellungen sieht es so aus:

Im Ruhezustand wird Bluetooth durch Bluesnooze ausgeschaltet (weil Apple das versaubeutelt hat!), ein Bluetooth Gerät kann den Mac also nicht aufwecken.

Das hier gibt das Log her:

% log show --last 10h --style syslog | fgrep "Wake reason"
2022-03-14 21:55:37.887354+0100  localhost kernel[0]: (AppleBCM5701Ethernet) AppleBCM5701Ethernet [en0]: Wake reason: Enet.TCPData - Incoming data on a kept-alive socket with TCP from 2c:3a:fd:d4:f9:8e 17.57.146.175.5223 to 192.168.178.84.61584
2022-03-14 21:55:37.887366+0100  localhost kernel[0]: (AppleBCM5701Ethernet) AppleBCM5701Ethernet [en0]: Wake reason: Enet.TCPData - Incoming data on a kept-alive socket with TCP from 2c:3a:fd:d4:f9:8e 17.57.146.175.5223 to 192.168.178.84.61584
2022-03-14 21:55:41.542824+0100  localhost apsd[141]: [com.apple.apsd:stream] <private>: Wake reason <private> matches <private>
2022-03-14 21:55:41.545922+0100  localhost apsd[141]: [com.apple.apsd:stream] <private>: Wake reason <private> matches <private>
2022-03-14 21:57:17.428532+0100  localhost kernel[0]: (corecapture) 198116.225122 wlan0.A[3563] systemWokenByWiFi@39704:Wake reason = wlan, kern.wakereason: 'SMC.OutboxNotEmpty smc.70070000 wifibt wlan'
2022-03-14 21:57:17.428543+0100  localhost kernel[0]: (AppleBCMWLANCore) Wake reason = wlan, kern.wakereason: 'SMC.OutboxNotEmpty smc.70070000 wifibt wlan'
2022-03-14 22:14:37.029434+0100  localhost kernel[0]: (AppleTopCaseHIDEventDriver) [HID] [ATC] AppleDeviceManagementHIDEventService::processWakeReason Wake reason: Button (0x03)
2022-03-14 22:24:01.314906+0100  localhost kernel[0]: (AppleTopCaseHIDEventDriver) [HID] [ATC] AppleDeviceManagementHIDEventService::processWakeReason Wake reason: Button (0x03)
2022-03-15 00:01:10.979301+0100  localhost kernel[0]: (AppleTopCaseHIDEventDriver) [HID] [ATC] AppleDeviceManagementHIDEventService::processWakeReason Wake reason: Button (0x03)
2022-03-15 00:17:59.977175+0100  localhost kernel[0]: (corecapture) 006858.217978 wlan0.A[600] systemWokenByWiFi@39704:Wake reason = wlan, kern.wakereason: 'SMC.OutboxNotEmpty smc.70070000 wifibt wlan'
2022-03-15 00:17:59.977187+0100  localhost kernel[0]: (AppleBCMWLANCore) Wake reason = wlan, kern.wakereason: 'SMC.OutboxNotEmpty smc.70070000 wifibt wlan'
2022-03-15 07:16:24.351800+0100  localhost kernel[0]: (AppleTopCaseHIDEventDriver) [HID] [ATC] AppleDeviceManagementHIDEventService::processWakeReason Wake reason: Button (0x03)

Was kann das für ein Buch sein, daß der mini da liest?

 

[oneOeight]

Der flüstert heimlich per Ethernet mit Apple und dann hat der auch zusätzlich WLAN an?
Und irgendwer drückt einen Knopf.

 

[carsten_h]

Und irgendwer drückt einen Knopf.

Ich habe das oben noch einmal korrigiert. Das Schlafen sollte eigentlich um 00:05 anfangen. Das vorher waren Tests.
Denn der Knopf, den ich um 7:16 gedrückt habe ist die Apple Fernbedienung gewesen, die den Mac aufwecken soll. Da steckt ein FLIRC, damit das klappt, da der mini ja keinen Infrarot-Empfänger mehr hat.

dann hat der auch zusätzlich WLAN an?

Ja, denn sonst funktionieren Airdrop/Handover ja nicht.

 

[oneOeight]

Versuch mal das tcpkeepalive auszuschalten, ob der dann durchschläft.

sudo pmset -a tcpkeepalive 0

 

[carsten_h]

ob der dann durchschläft.

An so etwas dachte ich auch schon, nur warum ist er dann 3,5 Stunden durchgehend wach?

Die Fehlermeldungen sind schön, die man beim Ausschalten bekommt, da hat man richtig Angst:

Warning: This option disables TCP Keep Alive mechanism when sytem is sleeping. This will result in some critical features like 'Find My Mac' not to function properly.
Warning: Idle sleep timings for "AC Power" may not behave as expected.
- Disk sleep should be non-zero whenever system sleep is non-zero.

Das sieht dann so aus:

% pmset -g                  
System-wide power settings:
Currently in use:
 standby              0
 Sleep On Power Button 1
 autorestart          0
 SleepServices        1
 powernap             1
 networkoversleep     0
 disksleep            0
 sleep                1 (sleep prevented by bluetoothd, powerd, sharingd)
 ttyskeepawake        1
 displaysleep         20
 tcpkeepalive         0
 womp                 0

Ich habe es jetzt auch noch einmal in einen Bugreport verpackt, ist ja erst der dritte diesen Monat. Langsam macht es richtig Spaß die zu schreiben. Allerdings sind die aus den letzten beiden Jahren noch nicht einmal kommentiert worden. Das ist wahrscheinlich so etwas wie /dev/null.

 

[Stargate]

Doch was verflucht macht der mini Nachts die ganze Zeit wenn der Verbrauch so bei 30W läuft?

macOS räumt Nachts auf UND telefoniert nach Hause.
BSD-Standardscripte laufen, die whatis Database wird beackert und Log-Files werden rotierend gewechselt.
Dazu laufen natürlich dann auch mal alle externen Laufwerke an.

SMC.OutboxNotEmpty smc.70070000 wifibt wlan hat deinen Mac geweckt.

Bei den neuen M1 Notebooks scheint das zu helfen:

1. Run command in terminal: sudo pmset -a tcpkeepalive 0
2. Run command in terminal: sudo pmset -a powernap 0
3. Make sure these options is not checked:

"System Preferences->Battery->Optimized battery charging" and "System Preferences->Battery->Power Adapter->Wake for network access"

Was kann das für ein Buch sein, daß der mini da liest?

Der Titel des Buches lautet: "Wie programmiere ich ein möglichst nervtötendes macOS" :->

 

[lisanet]

Disk sleep should be non-zero whenever system sleep is non-zero.

Diesen Hinweis solltest du befolgen, sprich das Häcken setzen bei "Wenn möglich, Ruhezustand der Festplatten aktivieren". Interessant ist eher, dass diese Option bei dir überhaupt auftaucht. Ich habe auch einen M1 Mini und diese Option nicht. Vielleicht hängt das mit dem Dock zusammen. Erfahrungsgemäß sind es nahezu immer Docks/Hubs/USB-Gadgets, die den Ruhezustand verhindern.

Zudem würde es sich anbieten, auf deinem NAS mal die smb.conf zu prüfen und dort ein eventuelles "SO_KEEPALIVE" zu entfernen.

sleep 1 (sleep prevented by bluetoothd, powerd, sharingd)

Das sind die Dinge, die deinen Mac wach halten: Du hast irgendeine Bluetooth-Verbindung (Lautsprecher?) Sharingd dürfte die Verbindung zum NAS sein oder eine Freigabe die du anbietest.

Auch deine USV könnte der Grund sein, den Mac wachzuhalten.

 

[Torrester]

aber sie sind in vielerlei Hinsicht wirklich gut

 

[lisanet]

Noch was wegen der USV:

Verhindern USV nicht per se den Ruhezustand? Ich meine mich so zu erinnern. Wie soll sonst eine USV bei einem Stromausfall den Mac erst aufwecken um ihn ggf. sauber runter zu fahren?

 

[carsten_h]

sprich das Häcken setzen bei "Wenn möglich, Ruhezustand der Festplatten aktivieren"

Ok, mache ich. Jetzt kommt die Meldung nicht mehr. Powernap habe ich auch auf die Terminalart abgestellt.

Vielleicht hängt das mit dem Dock zusammen.

Das mag sein.

Erfahrungsgemäß sind es nahezu immer Docks/Hubs/USB-Gadgets, die den Ruhezustand verhindern.

Die hatte ich ja schon alle ausgeschlossen (es gibt da einen anderen Thread, bei dem ich herausgefunden habe, daß zwei WD Platten im stromlosen Zustand den Mac wach halten).

auf deinem NAS mal die smb.conf zhu prüfen und dort ein eventuelles "SO_KEEPALIVE" zu entfernen.

Soweit ich das sehen kann, wird die Time Machine Freigabe nur dann gemountet, wenn auch die Sicherung läuft. Meintest Du das?

Du hast irgendeine Bluetooth-Verbindung

Ja, jetzt habe ich die MX Keys, die MX Vertical und ein Magic Trackpad 2 an Bluetooth. Im Ruhezustand sind sie aber durch Bluesnooze abgeklemmt. Nur pmset -g kann ich natürliich nur im wachen Zustand aufrufen.

Sharingd dürfte die Verbindung zum NAS sein oder eine Freigabe die du anbietest.

Freigaben sind es definitiv nicht:

Aber ich habe ein Laufwerk von einem Pi 4 und eines von einem QNAP NAS (ist nicht das für Time Machine) gemountet.
Soll ich die zum Ruhezustand unmounten? Das ist doch irgendwie widersinnig.

"Wie programmiere ich ein möglichst nervtötendes macOS"

Hast Du einmal die ISBN?

Verhindern USV nicht per se den Ruhezustand?

Hmm. Gute Frage. Ich ziehe einmal den Stecker. Eine Option gibt es jedenfalls nicht dafür.

 

[lisanet]

Soweit ich das sehen kann, wird die Time Machine Freigabe nur dann gemountet, wenn auch die Sicherung läuft. Meintest Du das?

Nein.

In der smb.conf des Samba-Servers auf deinem NAS oder Raspi kann diese Option aktiviert sein. Diese meine ich. Ob und wie du die entfernen kannst, kann ich dir nicht sagen, das hängt von der Software deines NAS und Raspis ab. Ich habe mein QNAP NAS mit einem selbst installierten Samba-Server ausgestattet aus genau dem Grund, dass ich die Konfiguration selbst vornehmen kann.

Zu Bluetooth:

Wie weckst du deinen Mac denn auf? Wenn "bluesnooze" so funktioniert wie beworben, dann schaltet es ja Bluetooth aus unmittelbar bevor der Mac in den Ruhezustand geht. "bluesnooze" soll aber Bluetooth erst dann wieder einschalten, nachdem der Mac wieder wach ist.

Nun die Frage: Wie soll nun eine Bluetooth-Tastatur oder eine Bluetooth-Maus oder Bluetooth-Trackpad einen Mac aufwecken, wenn Bluetooth im Mac abgeschaltet ist?

Daher glaube ich der Aussage von "bluesnooze" nicht.

 

[oneOeight]

Nun die Frage: Wie soll nun eine Bluetooth-Tastatur oder eine Bluetooth-Maus oder Bluetooth-Trackpad einen Mac aufwecken, wenn Bluetooth im Mac abgeschaltet ist?

Daher glaube ich der Aussage von "bluesnooze" nicht.

Er schrieb was von Fernbedienung.
Wobei die BT Standby Bug doch seit 12.2.1 eh gefixt sein sollte.

 

[lisanet]

Er schrieb was von Fernbedienung.

stimmt. .... sorry for the noise.

Dann bin ich wieder bei den USB-Gadgets, also beim FLIRC-USB-Stick, der den Ruhezustand verhindern könnte, neben der Möglichkeit dass dies die USV tut.

 

[carsten_h]

also beim FLIRC-USB-Stick

Der macht aber nur etwas, wenn er die konfigurierten Infrarot Signale empfängt. Ich glaube nicht, daß da irgendwer aktiv war.
Außerdem müßte auch dann der Rechner nach der eingestellten Zeit wieder schlafen geht, er bleibt aber 3,5 Stunden an. Und einen Weckgrund gibt es im Log ja auch nicht zu der Zeit.

Er schrieb was von Fernbedienung.

Richtig! Genau die weckt den Mac wieder auf über den FLIRC Empfänger.

Wobei die BT Standby Bug doch seit 12.2.1 eh gefixt sein sollte.

Der interessiert mich auch nicht. Ich möchte nicht, daß eines meiner Bluetooth Geräte den Mac aufweckt, denn es stößt gerne einmal jemand anderes gegen/auf Tastatur/Maus/Trackpad. Bis macOS 11 gab es dazu eine Option in den erweiterten Bluetooth Einstellungen, aber seit macOS 12 sind die ganzen erweiterten Bluetooth Einstellungen einfach so weg.

 

[lisanet]

Eine Idee habe ich noch, was der Mac nachts machen könnte. Das ist bei mir neulich erst so aufgetreten.

Ich habe auf dem NAS auch ein TimeMachine-Backup. TimeMachine aktiviert nun auch immer Spotlight für sein Volume. Das kann man auch nicht deaktivieren.

Bei mir ist Spotlight an irgendwas hängen geblieben. Sowohl der mds als auch mdworker_shared. Die Folge war, dass permanent Zugriffe aufs NAS erfolgten. Die Ursache habe ich noch nicht eindeutig ermittlen können, aber ich vermute den 2,5 GBit Ethernet-Adapter. Das ganze ist mir zweimal passiert.

Lösungen waren hier das erste Mal, TimeMachine zu deaktivieren, das Backup-Sparsbundle auf dem NAS zu löschen und TimeMachine neu zu starten und das Backup neu anzulegen. Das zweite Mal als es passierte, habe ich kurzerhand mit sudo killall mds den hängenden mds abgeschossen, was nun seither für Ruhe gesorgt hat.

Vielleicht ist das auch bei dir der Fall.

 

[carsten_h]

aber ich vermute den 2,5 GBit Ethernet-Adapter. Das ganze ist mir zweimal passiert.

2,5 GBit habe ich hier noch nicht, obwohl das NAS das könnte, aber da ist noch ein Switch dazwischen, der das nicht kann.

Bezüglich mds/mdworker habe ich das hier in der Aktivitätsanzeige gefunden:

Da sind schon viele Prozesse im Gange und der eine mdworker und mds hab auch schon ziemlich viel CPU-Zeit verbraten.

Ich habe gerade gesehen, daß die letzte Sicherung auf dem NAS um 8:45 war. Es gibt aber folgendes Verzeichnis, was für Deine Vermutung sprechen könnte:

% ls -al /Volumes/.timemachine
total 0
drwxr-xr-x   5 root  wheel   160 15 Mär 08:46 .
drwxr-xr-x  12 root  wheel   384 15 Mär 09:43 ..
drwxr-xr-x  36 root  wheel  1152 15 Mär 08:40 48843C11-897C-4665-938D-0751137C1C08
drwxr-xr-x  31 root  wheel   992 15 Mär 10:40 C06900EE-A4A7-466C-986A-AA60B9015197
drwxr-xr-x   4 root  wheel   128 15 Mär 08:40 WDMyCloud._afpovertcp._tcp.local.

 

[lisanet]

muss das WD-Teil echt über afp angebunden sein? Muss jetzt nichts mit dem Ruhezustand zu tun haben, könnte aber sein, da AFP in den ganze open-source-Implentierungen, die auf netatalk basieren, um einiges anfälliger ist, als Samba. Gerade netatalk 2 hat so einige Macken. Und eine instabile Verbindung kann dann wiederum die Ursache sein, das mds und/oder mdworker_shared hängen bleiben.

Am besten erkennst du es, wenn du im Terminal mal "top" eingibst. Da siehst du dann ob irgendwelche Prozess als Status "stuck" haben.

 

[carsten_h]

Da siehst du dann ob irgendwelche Prozess als Status "stuck" haben.

Ja, davon sind mdworker_shared, mdsync und mdworker betroffen.

Das WD-Teil hat noch das OS 3 drauf. Dort kann man nirgendwo einstellen, daß smb benutzt werden soll. Zumindest nicht auf der Oberfläche. Ich suche mal, das stört mich auch.

 

[lisanet]

Ja, davon sind mdworker_shared, mdsync und mdworker betroffen.

genau so war es auch bei mir, mit der Folge, dass permanente, nie endende Zugriffe auf das NAS erfolgen. Erst als ich den mds mit sudo killall mds beendet habe, war Ruhe.

Diese dauernden Zugriffe können durchaus die Ursache bei dir sein, dass der Mini nicht schläft.

Wie gesagt, habe ich den Grund für die "stuck" Prozesse noch nicht raus gefunden. Das Problem ist aber auch seither nicht mehr aufgetreten.

 

[carsten_h]

Diese dauernden Zugriffe können durchaus die Ursache bei dir sein, dass der Mini nicht schläft.

Ich habe sie gekillt, mal sehen wie sich das verhält. Danke!