Macen fryser efter uppvaknande med VPN: vad du ska registrera

Rapporter om en frusen Mac efter uppvaknande slår ofta ihop tre fel till ett enda klagomål. Markören kan fortfarande röra sig medan VPN-klienten ignorerar klick, klienten kan fungera medan en fjärrsession löper ut, eller hela skrivbordet kan sluta ta emot inmatning. Var och en av dessa kräver olika bevis, och den första minuten efter frysningen avgör vilken du tittar på. En felaktig gissning skickar varje senare steg i fel riktning.

Vad slutade svara, och vad slutade bara vänta

Börja med de billigaste testerna: flytta markören och skriv i ett lokalt textfält, öppna klientens egen statusvy och läs tillståndet den rapporterar, och starta sedan en ny åtgärd i den privata appen i stället för att återuppta sessionen som redan var öppen. Skriv ned de tre svaren innan du rör något annat, eftersom ordningen på det som misslyckades är den första detalj folk glömmer.

Varje utfall pekar någon annanstans. En enda fastlåst session sätter beviset på andra sidan tunneln, och Macen är bara åskådare. En klient som ignorerar klick medan skrivbordet fortfarande fungerar begränsar sökningen till den processen och dess logg. En maskin som ignorerar markören tar bort möjligheten att köra något alls, eftersom varje inspektionskommando behöver ett skal som svarar.

Håll de tre fallen åtskilda även när användaren beskriver dem i en enda mening. Rapporten du lämnar ska säga vilket test som misslyckades först och vilka som fortfarande gick igenom, inte att maskinen frös. Den skillnaden är det som låter en supportingenjör avgöra om han ska titta på nätverket, klienten eller hårdvaran.

En tidslinje du fortfarande kan försvara i morgon

Klockan är den del av registreringen som inte kan byggas upp igen senare. Notera när locket öppnades eller maskinen vaknade, när den första misslyckade åtgärden inträffade, och om de två ögonblicken låg sekunder eller minuter isär. Skriv sedan om Macen verkligen sov eller bara låste skärmen, eftersom det är olika tillstånd med olika uppvakningsvägar. Sömnloggen är den enda delen av den tidslinjen du kan kontrollera efteråt.

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

Det första kommandot förvandlar ett vagt minne till en tidsstämpel som du kan skriva in i det andra. Begränsa loggfrågan till klientprocessen och ett kort fönster, och du får en sida utdata i stället för en hel dag. Kopiera modellidentifieraren, klientbygget och nätverket du var på till samma anteckning medan skärmen fortfarande är framför dig; en rapport som sammanställs nästa morgon tappar den ordning som gjorde den läsbar.

Välj den inspelning som passar symptomet

Apple dokumenterar tre inspelningar i Activity Monitors diagnosguide, och de svarar på olika frågor. Sample Process följer en vald process i tre sekunder, spindump riktar sig mot en app som har slutat svara och snart tvingas stänga, och System Diagnostics samlar systemloggar i ett paket.

Välj efter vad du observerade, inte efter vana. En klient som körs men beter sig illa får en sample, tagen med sample <pid> 3 -file ~/Desktop/sample.txt eller från kugghjulsmenyn. En app som snurrar i evighet och måste dödas får Spindump-posten från samma meny. Ett problem som omfattar klienten och systemet får sudo sysdiagnose -f ~/Desktop. Ta sample innan du tvingar stängning när du kan, eftersom avslut förstör exakt det tillstånd du ville undersöka, och namnge filen efter händelsen och tiden i stället för efter din gissning om orsaken.

Behandla varje paket som känsligt. Dessa rapporter innehåller kontonamn, värdnamn, sökvägar och nätverksdetaljer, så skicka dem via supportkanalen som din organisation använder i stället för att bifoga dem till en offentlig tråd. Om en rapport måste kortas, korta en kopia och låt originalet vara intakt.

När markören själv inte rör sig

Ett dött gränssnitt ändrar ordningen på åtgärderna. Du kan inte ta sample av en process eller köra en fråga från ett skal som inte svarar, så det första målet är återställning och det andra är en registrering. En påtvingad omstart är ibland den enda vägen ut, och det är också ögonblicket då de mest användbara detaljerna försvinner. Notera tiden, fönstren som var öppna och om nätverksmenyn visade en anslutning innan du startar om; de observationerna överlever omstarten även om processtillståndet inte gör det.

När maskinen är tillbaka, stå emot slutsatsen att omstarten hittade boven. Den återställde tjänsten och namngav ingenting. Bara en upprepning med en kontrollerad ändring kan peka på en komponent.

Om frysningen återkommer, ändra ett villkor per försök: nätverket, klientversionen eller sömnläget. Spara fjärrarbete först, och undvik att upprepa påtvingad sömn på en produktionsmaskin, eftersom upprepade hårda cykler riskerar dataförlust och ofta ger ett annat fel än det du jagar. Skriv ned varje försök med dess villkor så att nästa blir jämförbart och inte anekdotiskt.

Lämna över en händelse, inte en stämning

Överlämningen som leder till handling namnger fyra saker: vad som slutade svara, när det hände, hur nätverket såg ut i det ögonblicket, och vilken inspelning som täcker fönstret. Lägg till klientversionen och macOS-bygget, och stanna sedan. Både plattformsteamet och klientleverantören kan agera på den meningen, och ingen av dem kan agera på en beskrivning av frustration. Håll registreringen på ett ställe och fyll på den i stället för att berätta historien igen varje gång; om en uppdatering ändrade beteendet, notera vilken, eftersom det också är bevis.

En bra registrering säger också vad du redan har uteslutit. Om en lokal app svarade under frysningen, säg det; om sömnloggen visar ett verkligt uppvaknande och inte en låsning, säg det också. Nästa person ska inte behöva upprepa tester som du redan har gjort.

Innan du stänger ärendet, kontrollera tre saker: tidsstämpeln kommer från sömnloggen och inte från minnet, inspelningen passar symptomet du faktiskt såg, och paketet ligger på den godkända platsen. Om någon av de tre saknas är rapporten inte redo att skickas.