Macen fryser etter oppvåkning med VPN: hva du skal registrere

Rapporter om en frossen Mac etter oppvåkning slår ofte sammen tre feil til én klage. Markøren kan fortsatt bevege seg mens VPN-klienten ignorerer klikk, klienten kan virke mens én fjernøkt løper ut, eller hele skrivebordet kan slutte å ta imot inndata. Hver av dem krever ulike bevis, og det første minuttet etter frysingen avgjør hvilken du ser på. En feil gjetning sender hvert senere steg i feil retning.

Hva sluttet å svare, og hva sluttet bare å vente

Start med de billigste testene: flytt markøren og skriv i et lokalt tekstfelt, åpne klientens egen statusvisning og les tilstanden den rapporterer, og start deretter en ny operasjon i den private appen i stedet for å gjenoppta økten som allerede var åpen. Skriv ned de tre svarene før du rører noe annet, fordi rekkefølgen av det som sviktet, er den første detaljen folk glemmer.

Hvert utfall peker et annet sted. Én fastlåst økt setter beviset på den andre siden av tunnelen, og Macen er bare tilskuer. En klient som ignorerer klikk mens skrivebordet fortsatt virker, snevrer søket inn til den prosessen og loggen dens. En maskin som ignorerer markøren, fjerner muligheten til å kjøre noe som helst, fordi hver inspeksjonskommando trenger et skall som svarer.

Hold de tre tilfellene atskilt selv når brukeren beskriver dem i én setning. Rapporten du leverer, skal si hvilken test som sviktet først og hvilke som fortsatt besto, ikke at maskinen frøs. Den forskjellen er det som lar en støtteingeniør avgjøre om han skal se på nettverket, klienten eller maskinvaren.

En tidslinje du fortsatt kan forsvare i morgen

Klokken er den delen av registreringen som ikke kan gjenoppbygges senere. Noter når lokket ble åpnet eller maskinen våknet, når den første mislykkede handlingen skjedde, og om de to øyeblikkene lå sekunder eller minutter fra hverandre. Skriv deretter om Macen faktisk sov eller bare låste skjermen, fordi det er forskjellige tilstander med forskjellige oppvåkningsveier. Søvnloggen er den eneste delen av den tidslinjen du kan kontrollere etterpå.

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

Den første kommandoen gjør et vagt minne om til et tidsstempel du kan skrive inn i den andre. Begrens loggspørringen til klientprosessen og et kort vindu, og du får én side med utdata i stedet for en hel dag. Kopier modellidentifikatoren, klientbyggingen og nettverket du var på, inn i samme notat mens skjermen fortsatt er foran deg; en rapport som settes sammen neste morgen, mister rekkefølgen som gjorde den lesbar.

Velg opptaket som passer til symptomet

Apple dokumenterer tre opptak i Activity Monitors diagnoseveiledning, og de svarer på forskjellige spørsmål. Sample Process overvåker én valgt prosess i tre sekunder, spindump retter seg mot en app som har sluttet å svare og snart blir tvunget til å lukke, og System Diagnostics samler systemlogger i en pakke.

Velg etter det du observerte, ikke etter vane. En klient som kjører men oppfører seg dårlig, får en sample, tatt med sample <pid> 3 -file ~/Desktop/sample.txt eller fra tannhjulmenyen. En app som snurrer i det uendelige og må drepes, får Spindump-elementet fra samme meny. Et problem som spenner over klienten og systemet, får sudo sysdiagnose -f ~/Desktop. Ta sample før du tvinger lukking når du kan, fordi avslutning ødelegger nøyaktig den tilstanden du ville undersøke, og navngi filen etter hendelsen og tiden i stedet for etter gjetningen din om årsaken.

Behandle hver pakke som sensitiv. Disse rapportene inneholder kontonavn, vertsnavn, stier og nettverksdetaljer, så send dem gjennom støttekanalen organisasjonen din bruker i stedet for å legge dem ved en offentlig tråd. Hvis en rapport må trimmes, trim en kopi og la originalen være intakt.

Når markøren selv ikke vil flytte seg

Et dødt grensesnitt endrer rekkefølgen på operasjonene. Du kan ikke ta sample av en prosess eller kjøre en spørring fra et skall som ikke svarer, så det første målet er gjenoppretting og det andre er en registrering. En tvungen omstart er noen ganger den eneste veien ut, og det er også øyeblikket da de mest nyttige detaljene forsvinner. Noter tiden, vinduene som var åpne og om nettverksmenyen viste en tilkobling før du starter på nytt; de observasjonene overlever omstarten selv om prosessens tilstand ikke gjør det.

Når maskinen er tilbake, motstå konklusjonen om at omstarten fant synderen. Den gjenopprettet tjenesten og navnga ingenting. Bare en gjentakelse med én kontrollert endring kan peke på en komponent.

Hvis frysingen kommer tilbake, endre én betingelse per forsøk: nettverket, klientversjonen eller søvnmodusen. Lagre fjernarbeid først, og unngå å gjenta tvungen søvn på en produksjonsmaskin, fordi gjentatte harde sykluser risikerer datatap og ofte gir en annen feil enn den du jager. Skriv ned hvert forsøk med betingelsene, slik at det neste blir sammenlignbart og ikke anekdotisk.

Overlever én hendelse, ikke en stemning

Overleveringen som får handling, navngir fire ting: hva som sluttet å svare, når det skjedde, hvordan nettverket så ut i det øyeblikket, og hvilket opptak som dekker vinduet. Legg til klientversjonen og macOS-byggingen, og stopp der. Både plattformteamet og klientleverandøren kan handle på den setningen, og ingen av dem kan handle på en beskrivelse av frustrasjon. Hold registreringen på ett sted og legg til i den i stedet for å gjenfortelle historien hver gang; hvis en oppdatering endret atferden, noter hvilken, fordi det også er bevis.

En god registrering sier også hva du allerede har utelukket. Hvis en lokal app svarte under frysingen, si det; hvis søvnloggen viser en ekte oppvåkning og ikke en låsing, si det også. Neste person bør ikke måtte gjenta tester du allerede har kjørt.

Før du lukker saken, kontroller tre ting: tidsstempelet kommer fra søvnloggen og ikke fra hukommelsen, opptaket passer til symptomet du faktisk så, og pakken ligger på det godkjente stedet. Hvis én av de tre mangler, er rapporten ikke klar til å sendes.