Rapporter om en frossen Mac efter opvågning slår ofte tre fejl sammen i én klage. Markøren kan stadig bevæge sig, mens VPN-klienten ignorerer klik, klienten kan virke, mens én fjernsession løber ud, eller hele skrivebordet kan holde op med at tage imod input. Hver af dem kræver forskellige beviser, og det første minut efter frysningen afgør, hvilken du ser på. En forkert gætning sender hvert senere skridt i den forkerte retning.

Hvad holdt op med at svare, og hvad holdt blot op med at vente

Start med de billigste tests: flyt markøren, og skriv i et lokalt tekstfelt, åbn klientens egen statusvisning, og læs den tilstand, den rapporterer, og start derefter en ny handling i den private app i stedet for at genoptage den session, der allerede var åben. Skriv de tre svar ned, før du rører noget andet, fordi rækkefølgen af det, der svigtede, er den første detalje, folk glemmer.

Hvert udfald peger et andet sted hen. Én fastlåst session placerer beviset på den anden side af tunnelen, og Macen er kun tilskuer. En klient, der ignorerer klik, mens skrivebordet stadig virker, indsnævrer søgningen til den proces og dens log. En maskine, der ignorerer markøren, fjerner muligheden for at køre noget som helst, fordi hver inspektionskommando kræver et shell, der svarer.

Hold de tre tilfælde adskilt, selv når brugeren beskriver dem i én sætning. Den rapport, du indsender, skal sige, hvilken test der svigtede først, og hvilke der stadig bestod, ikke at maskinen frøs. Den forskel er det, der lader en supportingeniør afgøre, om der skal ses på netværket, klienten eller hardwaren.

En tidslinje, du stadig kan forsvare i morgen

Uret er den del af registreringen, der ikke kan genopbygges senere. Notér, hvornår låget blev åbnet, eller maskinen vågnede, hvornår den første mislykkede handling skete, og om de to øjeblikke lå sekunder eller minutter fra hinanden. Skriv derefter, om Macen faktisk sov eller kun låste skærmen, fordi det er forskellige tilstande med forskellige opvågningsveje. Søvnloggen er den eneste del af den tidslinje, du kan kontrollere bagefter.

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

Den første kommando forvandler en vag erindring til et tidsstempel, du kan skrive ind i den anden. Begræns logforespørgslen til klientprocessen og et kort vindue, og du får en side output i stedet for en hel dag. Kopiér model-id, klientbuild og det netværk, du var på, ind i samme note, mens skærmen stadig er foran dig; en rapport samlet næste morgen mister den rækkefølge, der gjorde den læsbar.

Vælg den optagelse, der passer til symptomet

Apple dokumenterer tre optagelser i Activity Monitors diagnostikguide, og de svarer på forskellige spørgsmål. Sample Process overvåger én valgt proces i tre sekunder, spindump retter sig mod en app, der er holdt op med at svare og snart bliver tvunget til at lukke, og System Diagnostics samler systemlogge i en pakke.

Vælg efter, hvad du observerede, ikke efter vane. En klient, der kører, men opfører sig forkert, får en sample, taget med sample <pid> 3 -file ~/Desktop/sample.txt eller fra tandhjulsmenuen. En app, der snurrer evigt og skal dræbes, får Spindump-punktet fra samme menu. Et problem, der spænder over klienten og systemet, får sudo sysdiagnose -f ~/Desktop. Tag en sample, før du tvinger lukning, når du kan, fordi afslutning ødelægger præcis den tilstand, du ville undersøge, og navngiv filen efter hændelsen og tiden i stedet for efter din gæt på årsagen.

Behandl hver pakke som følsom. Disse rapporter bærer kontonavne, værtsnavne, stier og netværksdetaljer, så send dem gennem den supportkanal, din organisation bruger, i stedet for at vedhæfte dem til en offentlig tråd. Hvis en rapport skal trimmes, så trim en kopi og lad originalen være intakt.

Når markøren selv ikke vil flytte sig

En død grænseflade ændrer rækkefølgen af handlinger. Du kan ikke sample en proces eller køre en forespørgsel fra et shell, der ikke svarer, så det første mål er genopretning, og det andet er en registrering. En tvungen genstart er nogle gange den eneste vej ud, og det er også det øjeblik, hvor de mest nyttige detaljer forsvinder. Notér tiden, de åbne vinduer og om netværksmenuen viste en forbindelse, før du genstarter; de observationer overlever genstarten, selv om procestilstanden ikke gør.

Når maskinen er tilbage, modstå konklusionen om, at genstarten fandt synderen. Den genskabte tjenesten og navngav intet. Kun en gentagelse med én kontrolleret ændring kan pege på en komponent.

Hvis frysningen vender tilbage, ændr én betingelse per forsøg: netværket, klientversionen eller søvntilstanden. Gem fjernarbejde først, og undgå at gentage tvungne søvn på en produktionsmaskine, fordi gentagne hårde cyklusser risikerer datatab og ofte giver en anden fejl end den, du jager. Skriv hvert forsøg ned med dets betingelser, så det næste er sammenligneligt og ikke anekdotisk.

Aflever én hændelse, ikke en stemning

Den overdragelse, der får handling, navngiver fire ting: hvad der holdt op med at svare, hvornår det skete, hvordan netværket så ud i det øjeblik, og hvilken optagelse der dækker vinduet. Tilføj klientversionen og macOS-build, og stop så. Både platformsteamet og klientleverandøren kan handle på den sætning, og ingen af dem kan handle på en beskrivelse af frustration. Hold registreringen på ét sted, og føj til den i stedet for at genfortælle historien hver gang; hvis en opdatering ændrede adfærden, notér hvilken, fordi det også er bevis.

En god registrering siger også, hvad du allerede har udelukket. Hvis en lokal app svarede under frysningen, så sig det; hvis søvnloggen viser en rigtig opvågning og ikke en låsning, så sig det også. Den næste person bør ikke skulle gentage tests, du allerede har kørt.

Før du lukker sagen, kontroller tre ting: tidsstemplet kommer fra søvnloggen og ikke fra hukommelsen, optagelsen passer til det symptom, du faktisk så, og pakken ligger på det godkendte sted. Hvis bare én af de tre mangler, er rapporten ikke klar til at sende.

Relaterede artikler