Správy o zamrznutom Macu po prebudení často spájajú tri poruchy do jednej sťažnosti. Ukazovateľ sa môže ešte pohybovať, zatiaľ čo klient VPN ignoruje kliknutia, klient môže fungovať, zatiaľ čo jedna vzdialená relácia vyprší, alebo celá plocha môže prestať prijímať vstup. Každý z týchto prípadov potrebuje iné dôkazy a prvá minúta po zamrznutí rozhoduje, na ktorý sa pozeráte. Nesprávny odhad pošle každý ďalší krok nesprávnym smerom.

Čo prestalo odpovedať a čo len prestalo čakať

Začnite najlacnejšími testami: pohnite ukazovateľom a píšte do lokálneho textového poľa, otvorte vlastné zobrazenie stavu klienta a prečítajte hlásený stav, potom spustite novú operáciu v súkromnej aplikácii namiesto obnovenia už otvorenej relácie. Zapíšte tri odpovede, skôr než sa dotknete čohokoľvek iného, pretože poradie toho, čo zlyhalo, je prvý detail, ktorý ľudia zabúdajú.

Každý výsledok ukazuje inam. Jedna zaseknutá relácia umiestni dôkaz na druhú stranu tunela a Mac je len prizeralec. Klient, ktorý ignoruje kliknutia, zatiaľ čo plocha ešte funguje, zúži hľadanie na tento proces a jeho log. Stroj, ktorý ignoruje ukazovateľ, odoberá možnosť čokoľvek spustiť, pretože každý kontrolný príkaz potrebuje shell, ktorý odpovedá.

Držte tri prípady oddelene, aj keď ich používateľ opisuje jednou vetou. Správa, ktorú podávate, má povedať, ktorý test zlyhal prvý a ktoré ešte prešli, nie že stroj zamrzol. Práve ten rozdiel umožňuje podpornému inženýrovi rozhodnúť, či sa pozrieť na sieť, klienta alebo hardvér.

Časová os, ktorú zajtra ešte obhájite

Hodiny sú časťou záznamu, ktorú neskôr nemožno znovu zostaviť. Poznamenajte, kedy sa otvoril kryt alebo sa stroj prebudil, kedy nastala prvá neúspešná akcia a či tie dva okamihy delili sekundy alebo minúty. Potom napíšte, či Mac naozaj spal, alebo len zamkol obrazovku, pretože to sú rôzne stavy s rôznymi cestami prebúdzania. Log spánku je jediná časť tej časovej osi, ktorú môžete skontrolovať neskôr.

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

Prvý príkaz premení hmlistú spomienku na časovú pečiatku, ktorú môžete zadať do druhého. Obmedzte dopyt na log na proces klienta a krátke okno, a dostanete jednu stránku výstupu namiesto celého dňa. Skopírujte identifikátor modelu, build klienta a sieť, v ktorej ste boli, do tej istej poznámky, kým je obrazovka ešte pred vami; správa zostavená na druhý deň ráno stráca poradie, ktoré ju robilo čitateľnou.

Vyberte zachytenie, ktoré zodpovedá symptómu

Apple dokumentuje tri zachytenia v sprievodcovi diagnostikou Activity Monitor, a tieto odpovedajú na rôzne otázky. Sample Process sleduje jeden vybraný proces tri sekundy, spindump cieli na aplikáciu, ktorá prestala odpovedať a čoskoro bude nútene ukončená, a System Diagnostics zhromažďuje systémové logy do balíka.

Vyberajte podľa toho, čo ste pozorovali, nie podľa zvyku. Klient, ktorý beží, ale správa sa zle, dostane sample, zhotovený s sample <pid> 3 -file ~/Desktop/sample.txt alebo z ponuky ozubeného kolieska. Aplikácia, ktorá sa točí donekonečna a treba ju zabiť, dostane položku Spindump z tej istej ponuky. Problém, ktorý zahŕňa klienta aj systém, dostane sudo sysdiagnose -f ~/Desktop. Urobte sample pred núteným ukončením, keď môžete, pretože ukončenie ničí presne ten stav, ktorý ste chceli preskúmať, a súbor pomenujte podľa udalosti a času, nie podľa svojho odhadu príčiny.

Každý balík berte ako citlivý. Tieto správy obsahujú názvy účtov, názvy hostiteľov, cesty a sieťové podrobnosti, takže ich posielajte kanálom podpory, ktorý používa vaša organizácia, namiesto pripájania k verejnému vláknu. Ak treba správu skrátiť, skráťte kópiu a originál nechajte nedotknutý.

Keď sa sám ukazovateľ nehýbe

Mŕtve rozhranie mení poradie operácií. Nemôžete urobiť sample procesu ani spustiť dopyt zo shellu, ktorý neodpovedá, preto je prvým cieľom obnova a druhým záznam. Nútený reštart je niekedy jediná cesta von a je to aj okamih, keď miznú najužitočnejšie detaily. Poznamenajte čas, otvorené okná a to, či ponuka siete pred reštartom ukazovala pripojenie; tie pozorovania prežijú reštart, aj keď stav procesu nie.

Keď je stroj späť, odolajte záveru, že reštart našiel vinníka. Obnovil službu a nič nepomenoval. Iba opakovanie s jednou kontrolovanou zmenou môže ukázať na komponent.

Ak sa zamrznutie vracia, meňte jednu podmienku na pokus: sieť, verziu klienta alebo režim spánku. Najprv uložte vzdialenú prácu a vyhnite sa opakovaniu nútených spánkov na produkčnom stroji, pretože opakované tvrdé cykly riskujú stratu dát a často dávajú inú poruchu než tú, ktorú prenasledujete. Zapisujte každý pokus s jeho podmienkami, aby bol ďalší porovnateľný a nie anekdotický.

Odovzdajte jednu udalosť, nie náladu

Odovzdanie, ktoré prinesie akciu, pomenuje štyri veci: čo prestalo odpovedať, kedy sa to stalo, ako vyzerala sieť v tej chvíli a ktoré zachytenie pokrýva okno. Pridajte verziu klienta a build macOS a potom sa zastavte. Tím platformy aj dodávateľ klienta môžu konať na základe tej vety a ani jeden nemôže konať na základe opisu frustrácie. Držte záznam na jednom mieste a dopĺňajte ho namiesto toho, aby ste príbeh zakaždým znova rozprávali; ak aktualizácia zmenila správanie, uveďte ktorá, pretože aj to je dôkaz.

Dobrý záznam tiež uvádza, čo ste už vylúčili. Ak lokálna aplikácia počas zamrznutia odpovedala, povedzte to; ak log spánku ukazuje skutočné prebudenie a nie zamknutie, povedzte aj to. Ďalší človek by nemal opakovať testy, ktoré ste už urobili.

Pred zatvorením ticketu skontrolujte tri veci: časová pečiatka pochádza z logu spánku, nie z pamäte, zachytenie zodpovedá symptómu, ktorý ste skutočne videli, a balík sa nachádza na schválenom mieste. Ak chýba čokoľvek z troch, správa nie je pripravená na odoslanie.

Súvisiace články