Mac friert nach dem Aufwachen mit VPN ein: Was festhalten

Berichte über einen eingefrorenen Mac nach dem Aufwachen fassen oft drei Fehler in einer Beschwerde zusammen. Der Zeiger kann sich noch bewegen, während der VPN-Client Klicks ignoriert, der Client kann arbeiten, während eine einzelne Remotesitzung ausläuft, oder der ganze Schreibtisch kann aufhören, Eingaben anzunehmen. Jeder dieser Fälle braucht andere Belege, und die erste Minute nach dem Einfrieren entscheidet, welchen Sie vor sich haben. Eine falsche Vermutung schickt jeden späteren Schritt in die falsche Richtung.

Was aufgehört hat zu antworten, und was nur aufgehört hat zu warten

Beginnen Sie mit den billigsten Tests: Bewegen Sie den Zeiger und tippen Sie in ein lokales Textfeld, öffnen Sie die eigene Statusansicht des Clients und lesen Sie den Zustand, den sie meldet, und starten Sie dann einen neuen Vorgang in der privaten Anwendung, statt die bereits offene Sitzung fortzusetzen. Schreiben Sie die drei Antworten auf, bevor Sie etwas anderes anfassen, denn die Reihenfolge des Versagens ist das erste Detail, das Menschen vergessen.

Jedes Ergebnis weist woanders hin. Eine einzelne hängende Sitzung legt den Beleg auf die andere Seite des Tunnels, und der Mac ist nur Zuschauer. Ein Client, der Klicks ignoriert, während der Schreibtisch noch arbeitet, verengt die Suche auf diesen Prozess und sein Log. Eine Maschine, die den Zeiger ignoriert, nimmt die Möglichkeit, überhaupt etwas auszuführen, denn jeder Prüfbefehl braucht eine Shell, die antwortet.

Halten Sie die drei Fälle getrennt, auch wenn der Nutzer sie in einem Satz beschreibt. Der Bericht, den Sie einreichen, sollte sagen, welcher Test zuerst versagt hat und welche noch bestanden, nicht dass die Maschine eingefroren ist. Genau diese Unterscheidung lässt einen Supporttechniker entscheiden, ob er Netzwerk, Client oder Hardware ansehen soll.

Eine Zeitlinie, die Sie morgen noch verteidigen können

Die Uhr ist der Teil des Protokolls, der sich später nicht rekonstruieren lässt. Notieren Sie, wann der Deckel aufging oder die Maschine aufwachte, wann die erste fehlgeschlagene Aktion geschah und ob diese beiden Momente Sekunden oder Minuten auseinanderlagen. Schreiben Sie dann auf, ob der Mac wirklich schlief oder nur den Bildschirm sperrte, denn das sind verschiedene Zustände mit verschiedenen Wegen des Aufwachens. Das Schlafprotokoll ist der einzige Teil dieser Zeitlinie, den Sie später prüfen können.

pmset -g log | grep -i -E 'wake|sleep'
log show --last 15m --predicate 'process == "<client-process>"' --style compact

Der erste Befehl verwandelt eine vage Erinnerung in einen Zeitstempel, den Sie in den zweiten eintippen können. Beschränken Sie die Logabfrage auf den Clientprozess und ein kurzes Fenster, und Sie erhalten eine Seite Ausgabe statt eines ganzen Tages. Kopieren Sie Modellkennung, Client-Build und das Netzwerk, in dem Sie waren, in dieselbe Notiz, solange der Bildschirm noch vor Ihnen steht; ein am nächsten Morgen zusammengestellter Bericht verliert die Reihenfolge, die ihn lesbar machte.

Wählen Sie die Aufzeichnung, die zum Symptom passt

Apple dokumentiert drei Aufzeichnungen im Diagnosehandbuch von Activity Monitor, und sie beantworten unterschiedliche Fragen. Sample Process beobachtet einen ausgewählten Prozess drei Sekunden lang, spindump zielt auf eine Anwendung, die nicht mehr antwortet und gleich zum Beenden gezwungen wird, und System Diagnostics sammelt Systemprotokolle in einem Paket.

Wählen Sie nach dem, was Sie beobachtet haben, nicht nach Gewohnheit. Ein Client, der läuft, sich aber falsch verhält, bekommt ein Sample, aufgenommen mit sample <pid> 3 -file ~/Desktop/sample.txt oder aus dem Zahnradmenü. Eine App, die endlos dreht und beendet werden muss, bekommt den Spindump-Eintrag aus demselben Menü. Ein Problem, das Client und System umfasst, bekommt sudo sysdiagnose -f ~/Desktop. Nehmen Sie das Sample vor dem erzwungenen Beenden auf, wenn Sie können, denn das Beenden zerstört genau den Zustand, den Sie prüfen wollten, und benennen Sie die Datei nach dem Ereignis und der Uhrzeit statt nach Ihrer Vermutung über die Ursache.

Behandeln Sie jedes Paket als sensibel. Diese Berichte enthalten Kontonamen, Hostnamen, Pfade und Netzwerkdetails, also senden Sie sie über den Supportkanal Ihrer Organisation, statt sie an einen öffentlichen Thread anzuhängen. Wenn ein Bericht gekürzt werden muss, kürzen Sie eine Kopie und lassen Sie das Original unverändert.

Wenn sich der Zeiger selbst nicht bewegt

Eine tote Oberfläche ändert die Reihenfolge der Vorgänge. Sie können keinen Prozess samplen und keine Abfrage aus einer Shell starten, die nicht antwortet, also ist das erste Ziel die Wiederherstellung und das zweite ein Protokoll. Ein erzwungener Neustart ist manchmal der einzige Ausweg, und er ist zugleich der Moment, in dem die nützlichsten Details verschwinden. Notieren Sie die Uhrzeit, die offenen Fenster und ob das Netzwerkmenü vor dem Neustart eine Verbindung zeigte; diese Beobachtungen überleben den Neustart, auch wenn der Prozesszustand es nicht tut.

Wenn die Maschine zurück ist, widerstehen Sie dem Schluss, der Neustart habe den Übeltäter gefunden. Er stellte den Dienst wieder her und nannte nichts. Nur eine Wiederholung mit einer kontrollierten Änderung kann auf eine Komponente zeigen.

Kehrt das Einfrieren zurück, ändern Sie pro Versuch eine Bedingung: das Netzwerk, die Clientversion oder den Schlafmodus. Speichern Sie zuerst Remote-Arbeit, und vermeiden Sie wiederholte erzwungene Schlafphasen auf einer Produktionsmaschine, denn wiederholte harte Zyklen riskieren Datenverlust und erzeugen oft einen anderen Fehler als den, den Sie verfolgen. Schreiben Sie jeden Versuch mit seinen Bedingungen auf, damit der nächste vergleichbar ist und nicht anekdotisch.

Übergeben Sie ein Ereignis, keine Stimmung

Die Übergabe, die Handlung auslöst, nennt vier Dinge: was aufgehört hat zu antworten, wann es geschah, wie das Netzwerk in diesem Moment aussah und welche Aufzeichnung das Fenster abdeckt. Fügen Sie die Clientversion und den macOS-Build hinzu, und hören Sie dann auf. Sowohl das Plattformteam als auch der Clienthersteller können auf diesen Satz reagieren, und keiner kann auf eine Beschreibung von Frustration reagieren. Halten Sie das Protokoll an einem Ort und ergänzen Sie es, statt die Geschichte jedes Mal neu zu erzählen; wenn ein Update das Verhalten geändert hat, nennen Sie welches, denn auch das ist ein Beleg.

Ein gutes Protokoll sagt auch, was Sie bereits ausgeschlossen haben. Wenn eine lokale Anwendung während des Einfrierens antwortete, sagen Sie es; wenn das Schlafprotokoll ein echtes Aufwachen und keine Sperre zeigt, sagen Sie auch das. Die nächste Person sollte Tests, die Sie schon gemacht haben, nicht wiederholen müssen.

Bevor Sie das Ticket schließen, prüfen Sie drei Dinge: Der Zeitstempel stammt aus dem Schlafprotokoll und nicht aus der Erinnerung, die Aufzeichnung passt zum Symptom, das Sie tatsächlich gesehen haben, und das Paket liegt am freigegebenen Ort. Fehlt einer der drei Punkte, ist der Bericht nicht versandbereit.