Hi Forum,

seit dem letzten Sicherheits- und Safari-Update geht bei meinem MacBook der Bildschirm nicht mehr aus.
Systemeinstellungen Energie sparen steht auf Standard.

MacBook Pro 2013, High Sierra

Hat jemand eine Lösung

Hast du vielleicht ein Programm wie z.B. Caffeine im Hintergrund laufen, das verhindert, dass der Mac in den Ruhezustand geht und somit den Bildschirm ausschaltet?

Anmerkung:
Wenn der Bildschirm nicht dunkel wird, geht das MacBook wohl auch nicht in den Ruhezustand. Beides ist jedoch nicht dasselbe. Häufiger ist der andere Fall, dass zwar der Bildschirm dunkel wird, sich jedoch anschließend der Ruhezustand nicht einstellt.

Und eine Frage:
Hat das MacBook Pro an der Frontseite eine LED, die den Status des Computers signalisiert? Mein MacBook Pro 2010 hat die noch, das MacBook Air von 2013/2014 jedoch nicht und das MacBook Pro von 2013 dann wohl auch nicht?

Analysewerkzeuge im Terminalfenster:
liefert eine Tabelle der Einstellungen. Die Werte "disksleep", "sleep" und "displaysleep" sollten bei Standardeinstellung jeweils den Wert "10" (Minuten) haben.

liefert als erstes eine Tabelle mit "Assertions" (Zusicherungen) und anfordernden Prozessen, die das Herstellen des Ruhezustands verzögern.

Und anschließend werden laufend Anforderungen ("Created") und Rücknahmen ("Released") der Zusicherungen und Änderungen des Zustands derselben protokolliert.

Jede Benutzeraktivität startet jenen Timer, der das Ausschalten des Bildschirms eine Zeit lang (10 Minuten in unserem Fall) verzögert. Falls der Timer schon lief, setzt Aktivität des Benutzers das Zeitintervall zurück auf den Anfangswert.

Wenn man die Bedienungsoberfläche des Computers nach dem Absenden des Befehls in Ruhe lässt, sollten 10 Minuten später folgende Einträge auftauchen:
[Die Zeitmarken und den Namen des anfordernden Systemteils "com.apple.iohideventsystem.queue.tickle...." habe ich weggelassen]

12 Minuten nach dem Start der Protokollierung ist es vielleicht hilfreich, durch Betätigen von Ctrl-T die Tabelle mit dem aktuellen Zustand der Assertions erneut ins Protokoll schreiben zu lassen.
Die Protokollierung läuft danach jedoch weiter.
Taste esc stoppt sie.

Übrigens:
liefert die Tabelle der Assertions, ohne ein Log zu starten.

Bei sowas würde ich als allererstes einen SMC-resett machen. Wie das geht ist für die einzelnen Baureihen unterschiedlich, such mal direkt bei Apple nach der passenden Anleitung.

Nachtrag und Korrektur:
Zu beenden ist "pmset -g assertionslog" durch die Tastenkombination Ctrl-C.
Die zuvor erwähnte Taste esc ist wirkungslos.

Hi,

danke für eure Vorschläge. Problem hat sich inzwischen erledigt. Hatte zwar Safari- und Sicherheitsupdate heruntergeladen, aber erstmal nur das Safariupdate installiert. Nachdem ich auch das Sicherheitsupdate installiert hatte, ging der Ruhezustand wieder. Ob es daran lag?

Bei UserIsActive steht bei mir nach 10 min eine 1, Idle sleep preventer ist IODisplayWrangler. Was ist das?

IODisplayWrangler steuert die Beleuchtung des Displays (normale Leuchtstärke, halbe Leuchtstärke, aus).
Wenn der Timer "UserIsActive" den Status 0 erreicht hat, wird IODisplayWrangler normalerweise das Display dimmen.
Und während IODisplayWrangler das Display noch nicht gedimmt hat, hindert es den Computer daran, sich schlafen zu legen ( "Idle sleep preventers: IODisplayWrangler" ).
Zu diesem Zeitpunkt wird aber auch das Display noch hell gewesen sein? Ursache: Während der Beobachtungsdauer wird etwas passiert sein, was den Timer "Displaysleep" neu getriggert hat.

Wo stand nach 10 Minuten immer noch "UserIsActive = 1"?
In der Tabelle "Assertion status system-wide"? Das ist normal und muss so sein. Denn wenn sie erzeugt worden ist, ist dem unmittelbar eine Aktion des Benutzers vorausgegangen.

Ich meine die Einträge
die automatisch nach 10 Minuten der Inaktivität in das Protokoll "pmset -g assertionslog" geschrieben werden.

Leider hat UserIsActive = 0 nicht unbedingt zur Folge, dass das Display verdunkelt wird.

Das von Dattelpalme erwähnte Tool Caffeine ist so ein Fall, jedenfalls die letzte Originalversion 1.1.1 von Lighthead Software. Sie umgeht den Assertions-Mechanismus und manipuliert anscheinend den Displaymanager. Wenn das Symbol der Kaffeetasse mit dampfendem Kaffee gefüllt ist, geht zwar nach der vorgesehenen Zeit UserIsActive auf 0. Das Display bleibt in dem Fall jedoch hell. Im Log der Assertions finde ich keinen Hinweis auf die Aktivität von Caffeine.

In der Konsole erzeugt Windowserver immer dann die Fehlermeldung
wenn auf dem Desktop der Fokus auf ein anderes Fenster gerichtet wird (wenn an anderes Fenster angeklickt wird).

Es existieren jedoch moderne Nachfolger wie "KeepingYouAwake". Diese App ist in Version 1.5 bei GitHub erhältlich (Autor: "Newmarcel"). Sie benutzt die Schnittstelle zum Manager der Assertions und ist zudem von Apple notariziert worden, wurde also auf die Abwesenheit bekannter Schadroutinen geprüft.

Korrektur:
Die Fehlermeldung des Windowserver hat wohl nichts mit der App Caffeine zu tun.

Wenn es dich interessiert, kannst du ja mal einen Blick draufwerfen.


Caffeine oder ein ähnliches Programm benutze ich nicht. Aber ich habe immer seeeehr viele Webseiten und -tabs auf. Vielleicht war da was dabei, was das Einschlafen verhindert hat.

In diesem Fall hat sich der Mac allerdings 14 Minuten lang schlafen gelegt: Um 19:02 Uhr.

Der Parameter Displaysleep war auf 2 Minuten gesetzt. Wohl nur für diesen Test?
Der Parameter Sleep stand sogar bei nur 1 Minute. Ich hatte nicht erwartet, dass der überhaupt niedriger als Displaysleep werden kann.

"Handoff" hat via sharingd zeitweise die Assertion PreventUserIdleSystemSleep hochgesetzt und wurde gelöscht kurz nachdem der Timer UserIsActive abgelaufen war. Dann hat das System 15 Sekunden lang InternalPreventSleep hochgesetzt. Dann war noch weitere 15 Sekunden lang etwas anderes im Gange. Danach ging der Computer schlafen.

Nee, die Minuten hab ich nicht eingestellt. Das sind die Standardeinstellungen bei Batteriebetrieb.

Das Log habe ich ja erst gemacht, nachdem der Ruhezustand wieder ging. Also werden wir nicht erfahren, woran es gelegen hat. 🤔

Ach so.
Die beobachteten Werte sind auf meinem MacBook Air in Standardeinstellung genauso. Wähle ich allerdings einen anderen Wert, dann stimmen beide Werte wie zu erwarten überein.