MacBook Pro Insomnia

• Ich habe beim MacBook Pro Silicon M1 Max ein Phänomen von starker Akkuentladung über Nacht beobachtet.
• Ich habe versucht, die Energieverwaltungsprotokolle selbst zu analysieren, stieß dabei jedoch an Grenzen bei der Ursachenfindung.
• Mit der dedizierten App Sleep Aid konnte ich Wake-Events visuell einsehen.
• In den Einstellungen von Sleep Aid entdeckte ich, dass die Deaktivierung von „Wake for maintenance“ (für Wartungszwecke aufwecken) die Ursache war.
• Nachdem ich diese Option wieder aktiviert hatte, war die Batterieentladung über Nacht behoben.

---

Erfahrungsbericht: Nachtweise Akkuentladung am MacBook Pro

• Ich nutze ein MacBook Pro Silicon M1 Max seit vielen Jahren.
• In letzter Zeit zeigte sich unerwartet ein starker Akkuverbrauch über Nacht, wenn der Laptop nicht am Stromnetz angeschlossen war.
• Da das Problem zunehmend schlimmer wurde, begann ich, die Ursache selbst zu analysieren.

Versuch der Analyse der Energieverwaltungsprotokolle

• In macOS kann man mit dem Terminal-Befehl pmset -g log die energiebezogenen Log-Daten der Energieverwaltung einsehen.
• Die Ausgabe dieses Logs ist sehr umfangreich und schwer zu interpretieren, deshalb habe ich zur Auswertung das von mir selbst entwickelte, einfache Werkzeug pmset-analyzer eingesetzt.
• Allein mit diesem Tool brachte es jedoch keine nennenswerte Fortschritt bei der tatsächlichen Lösung.

Feineinstellung der Konfiguration und weitere Untersuchung

• Ich habe die von offizieller Dokumentation und der Community genannten Energieeinstellungen, darunter tcpkeepalive, der Reihe nach angepasst.
• Mit bloßen Konfigurationsänderungen zeigte sich jedoch kaum eine spürbare Wirkung auf die Problemlösung.

Problemlösung mit der App Sleep Aid

• Im Rahmen der weiteren Untersuchung habe ich die App Sleep Aid entdeckt.
  • Diese App visualisiert Wake-Events und stellt eine intuitive Oberfläche bereit, um diverse Energieeinstellungen bequem zu verändern.
• In Sleep Aid zeigte sich, dass die Option „Wake for maintenance“ deaktiviert war.
• Laut der Beschreibung der App kann bei deaktiviertem Schalter ein häufiges Auftreten von Wake-Events auftreten.
• Ich habe diese Option wieder aktiviert, und danach trat über Nacht keine auffällige Batterieentladung mehr auf.

[ahwjdekf]

Ich versetze mein MacBook in den Ruhezustand und schlafe, und plötzlich geht mitten in der Nacht der Bildschirm an, sodass das ganze Zimmer hell erleuchtet ist. Ich bin oft davon aufgewacht und habe es dann einfach komplett heruntergefahren. Das ist doch schon seit Ewigkeiten umstritten, und immer noch...

[GN⁺]

Hacker-News-Kommentare

• Noch ein nützlicher Tipp. Wenn man im Activity Monitor den Reiter „Energy“ öffnet und nach der Spalte „Preventing sleep“ sortiert, kann man sehen, welche Apps macOS am Ruhezustand hindern. In meinem Fall stellte sich die App Devonthink als Ursache heraus. Einen Bug-Report habe ich noch nicht eingereicht. Ich finde es seltsam, dass Apples Energieverwaltung die Nutzer nicht auf so ein Problem hinweist. Es ist doch ein wichtiges Problem, wenn ein Mac im Rucksack heiß wird und der Akku leerläuft. Gleichzeitig wirkt es deutlich weniger wichtig, dass Chrome ständig fragt, ob es Netzwerkgeräte suchen darf
  • Erstaunlich ist nicht nur, dass Apples Energieverwaltung davor nicht warnt, sondern noch mehr, dass irgendeine App den Ruhezustand des Systems verhindern kann, selbst wenn der Deckel geschlossen ist. Ich verstehe, dass ein zeitbasiertes Verhindern des Ruhezustands bei Videoplayern manchmal sinnvoll ist. Aber dass eine App entscheiden darf, dass das System beim Zuklappen oder beim Drücken der Sleep-Taste nicht schlafen geht, hat kaum wirklich nützliche Anwendungsfälle. Meist erhöht so etwas am Ende nur die Wahrscheinlichkeit, einen im Rucksack überhitzten Laptop dabeizuhaben. Dazu kommt, dass sogar schon eine einzelne Webseite das System am Einschlafen hindern kann, was es schwer macht, unter 70 Tabs den Übeltäter zu finden. Es wäre gut, die Berechtigung für timeoutbasiertes Verhindern des Ruhezustands von der Berechtigung zu trennen, Kernverhalten wie „Deckel zu = immer schlafen“ zu ändern. Timeouts kann man erlauben, aber Dinge wie das Schließen des Deckels sollten den Nutzer zwingend informieren und seine Zustimmung erfordern
  • Mir war nicht klar, dass beliebige Apps den systemweiten Ruhezustand verhindern können. So eine Berechtigung sollte klar unter Nutzerkontrolle stehen. Ich frage mich, ob Entwickler für den Aufruf dieser API nicht zumindest ein Entitlement brauchen sollten
  • In der Shell kann man mit dem Befehl pmset -g assertions sehen, welche Prozesse den Systemschlaf verhindern, und Details zu ausstehenden Power-Assertions anzeigen. pmset hat auch Befehle, die nicht in der offiziellen Dokumentation stehen; man kann sie sehen, weil Apple sie im Quellcode offengelegt hat. Es gibt auch einen Befehl, mit dem sich bestimmte Assertions ignorieren lassen. Nur sollte man die Assertion „UserIsActive“ nicht deaktivieren, denn dann könnte es schwierig werden, das System wieder aufzuwecken
  • Dass es diese Funktion gibt, wusste ich nicht, danke. Ich hatte mich kürzlich gefragt, warum der Akku meines selten genutzten MacBook ständig leerer wurde, und es stellte sich heraus, dass Firefox den Ruhezustand verhinderte. Vermutlich wegen automatisch abspielender Videos. Nicht perfekt, aber immerhin ein behebbares Problem
  • Safari zeigt dagegen Benachrichtigungen an, dass man es schließen solle, wenn man Netflix schaut, weil der Stromverbrauch hoch ist
• Ich hatte ein ähnliches Verhalten auch bei meinem MacBook Pro. Es war kein Apple-Silicon-Modell, sondern ein älteres. Damals hatte ich auf meinem Router die DHCP-Lease-Zeit deutlich unter den Standardwert auf 15 Minuten gesetzt. Meiner Vermutung nach ist das MacBook dann alle 15 Minuten zum Erneuern der IP aufgewacht, hat kurz geschlafen und ist dann wieder aufgewacht. Nachdem ich die Lease-Zeit des Routers wieder auf den früheren Standardwert zurückgesetzt hatte, war das Akkuproblem vollständig behoben. Auf diese Ursache wäre ich kaum gekommen, aber ich hatte gerade erst ein neues MacBook Pro gekauft und deshalb auf allerlei Probleme besonders geachtet, wodurch ich es schnell gefunden habe
  • Ein korrekt arbeitender DHCP-Client sendet die Erneuerungsanfrage nach 50 % der Lease-Zeit. Das heißt, wahrscheinlich ist es sogar noch häufiger aufgewacht, als du denkst
  • Ich frage mich, warum du die DHCP-Lease-Zeit auf 15 Minuten gesetzt hast. Was war der Zweck dahinter?
  • Habe ich auch gerade erst gelernt: Der von mir verwendete mikrotik-Router nutzt standardmäßig Lease-Zeiten von 10 Minuten
  • Das ist wirklich faszinierend. Ich frage mich, wie viele mAh so ein einzelnes Aufwachen zur IP-Erneuerung kostet. Vermutlich eher im Bereich einiger Milliampere-Millisekunden, denn am Ende wird wohl nur kurz das WLAN aktiviert und ein paar Pakete ausgetauscht. Natürlich war es ein Modell vor Apple Silicon, also könnte es beim Aufwachen in Wirklichkeit noch andere Dinge gemacht haben
  • Ich halte das für einen macOS-Bug. Im Schlaf braucht das System keine IP, daher ist ein Aufwachen nur zur Erneuerung der DHCP-Lease nicht normal. Bei einem nicht quelloffenen Betriebssystem sind solche Dinge eben problematisch
• Wenn die Option „Wake for maintenance“ deaktiviert ist, weist Sleep Aid im Einstellungsfenster darauf hin, dass das zu häufigem Aufwachen führen kann. Vielleicht hat der Autor versehentlich geschrieben, „die Option war ausgeschaltet“
  • Das dachte ich auch. Meine Vermutung ist, dass bei deaktivierter Einstellung Wake-Events nicht stündlich gebündelt und gesammelt abgearbeitet werden, sondern irgendwann über die Nacht verteilt mehrfach auftreten können. Genau dieses Verhalten scheint damit gemeint zu sein
  • Das verwirrt mich. Heißt das, wenn man die Option zum expliziten Aufwecken des Computers einschaltet, wacht er am Ende seltener auf?
  • Ich bin auch verwirrt. Im Screenshot des Autors ist es auf „Enable“ gesetzt. Das wirkt wie der „normale“ Zustand, daher ist nicht intuitiv nachvollziehbar, warum „Disabled“ mehr Wake-Ereignisse auslösen sollte
  • Solche kontraintuitiven Erklärungen sollten näher erläutert werden oder zumindest klar als Ausnahme gekennzeichnet sein. Solche Probleme im Nachhinein beim Überarbeiten eines Artikels einzufangen, ist schwierig
• Bei allen Mac-Laptops, die ich bisher hatte, habe ich das Problem gelöst, indem ich beim Schließen des Deckels immer den Hibernate-Modus aktiviert habe. Wenn man den Deckel wieder öffnet und weiterarbeiten will, dauert die Wiederherstellung zwar 20 bis 30 Sekunden, aber das ist für mich ein kleiner Preis dafür, dass ich mir deutlich weniger Gedanken über Sleep und Akkuverbrauch machen muss. Im Terminal geht das mit diesem Befehl: sudo pmset -a hibernatemode 25. Um es rückgängig zu machen, gibt man sudo pmset -a hibernatemode 3 ein
  • Ich frage mich, ob der Hibernate-Modus mit FDE (vollständiger Festplattenverschlüsselung) gut zusammenarbeitet. Unter Linux gibt es beim Schreiben des Speicherinhalts auf die Festplatte allerlei Dinge rund um Verschlüsselung zu beachten
  • Ich denke, das ist die einfachste Möglichkeit, das Verhalten einzustellen, das die meisten Leute eigentlich erwarten
• Ich habe wirklich lange an Macbook-Sleep-Problemen herumdiagnostiziert, aber bei mir ist offenbar der WindowServer die Ursache, und am Ende scheint wohl eine komplette Neuinstallation des Betriebssystems nötig zu sein. Fast nichts ist frustrierender, als alle ein, zwei Monate einen heißen, entladenen Laptop aus der Tasche zu holen und dann zu hören: „Mir ist das noch nie passiert, benutzt du ihn vielleicht falsch?“
• macOS fühlt sich für mich seit fast zehn Jahren an, als wäre es nur noch im Wartungsmodus. Die Portierung auf ARM/Mac Silicon war sicher enorm viel Arbeit. Auch die AI-Updates waren enttäuschend, und in letzter Zeit hatte ich nicht den Eindruck, dass es viele echte Verbesserungen gab. Früher hatte ich ein Intel Macbook Air, bei dem der Power-Button direkt neben der Rücktaste saß, und ich habe in einem Mac-Forum ein Skript gefunden, das bewirkte, dass der Rechner nicht sofort herunterfährt, wenn man den Power-Button nur einmal drückt, sondern dass man ihn gedrückt halten muss. In diesem Skript war aber ein Trojaner versteckt, sodass ich meinen Mac auf Werkseinstellungen zurücksetzen und alles aus iCloud löschen musste. Das Skript enthielt wohl auch GUIDs, die wie interne Variablen aussahen, und konnte Ressourcen von irgendwo herunterladen. Ich hielt das damals einfach für interne Variablen
• Laut dem offiziellen Apple-Supportdokument ist diese Funktion (Energieoption) integriert
  • Auf meinem M4 MacBook Air mit installiertem macOS 26 DB gibt es an dieser Stelle kein Power Nap mehr. Stattdessen gibt es „Wake for network access“, standardmäßig auf „Only on Power Adapter“
  • Ich hatte Power Nap und „wake for network access“ verwechselt. Unter macOS 26 scheint es die Option nicht mehr zu geben. Bei mir steht es auf „Only on Power Adapter“, was vernünftig wirkt. Gilt für ein M4 MacBook Air
• Ich habe letzte Woche fast denselben Blogpost geschrieben. Leider hat die Lösung in meinem Fall nicht geholfen, weil noch andere Prozesse außer Power Nap den Rechner weiter aufwecken. Verwandter Artikel: annoying.technology-Post
• Der Energy-Reiter im Activity Monitor ist in solchen Fällen nützlich. Man sieht, welche Apps den Systemschlaf vollständig verhindern, und auch den Stromverbrauch jedes Prozesses in den letzten 12 Stunden. Damit lässt sich die Ursache direkt über Nacht eingrenzen
• Ich habe auf meinem MacBook Pro (Apple Silicon) ebenfalls ein ähnliches Problem. Wenn ich es mit angeschlossener SSD in den Ruhezustand versetze, scheint das System periodisch aufzuwachen und das Laufwerk zu aktivieren. Dadurch werden sowohl der Laptop als auch die SSD warm, und der Akku ist schnell leer. Die einzige Gegenmaßnahme ist, vor dem Einschlafen alle externen Laufwerke abzuziehen und das Gerät am Ladegerät zu lassen. Ein ziemlich lästiger Bug. Das wirkt auf mich nach unzureichender Qualitätssicherung und zu wenig Tests