Mac zamrzne po probuzení s VPN: co zaznamenat

Zprávy o zamrzlém Macu po probuzení často slučují tři poruchy do jedné stížnosti. Ukazatel se může ještě pohybovat, zatímco klient VPN ignoruje kliknutí, klient může fungovat, zatímco jedna vzdálená relace vyprší, nebo celá plocha může přestat přijímat vstup. Každý z těchto případů potřebuje jiné důkazy a první minuta po zamrznutí rozhoduje, na který se díváte. Špatný odhad pošle každý další krok špatným směrem.

Co přestalo odpovídat a co jen přestalo čekat

Začněte nejlevnějšími testy: pohněte ukazatelem a pište do místního textového pole, otevřete vlastní zobrazení stavu klienta a přečtěte stav, který hlásí, potom spusťte novou operaci v soukromé aplikaci, místo abyste obnovovali již otevřenou relaci. Zapište tři odpovědi, než se dotknete čehokoli dalšího, protože pořadí toho, co selhalo, je první detail, který lidé zapomínají.

Každý výsledek ukazuje jinam. Jedna zaseknutá relace staví důkaz na druhou stranu tunelu a Mac je jen přihlížející. Klient, který ignoruje kliknutí, zatímco plocha ještě funguje, zužuje hledání na tento proces a jeho log. Stroj, který ignoruje ukazatel, odstraňuje možnost cokoli spustit, protože každý inspekční příkaz potřebuje shell, který odpovídá.

Držte tři případy oddělené, i když je uživatel popisuje jednou větou. Zpráva, kterou podáváte, má říct, který test selhal první a které ještě prošly, ne že stroj zamrzl. Právě tento rozdíl umožňuje podpornímu inženýrovi rozhodnout, zda se dívat na síť, klienta nebo hardware.

Časová osa, kterou můžete obhájit i zítra

Hodiny jsou částí záznamu, kterou nelze později znovu sestavit. Poznamenejte, kdy se otevřelo víko nebo se stroj probudil, kdy se stala první neúspěšná akce, a zda ty dva okamžiky dělily sekundy nebo minuty. Pak zapište, zda Mac skutečně spal, nebo jen zamkl obrazovku, protože to jsou různé stavy s různými cestami probuzení. Log spánku je jediná část této časové osy, kterou můžete potom zkontrolovat.

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

První příkaz promění mlhavou vzpomínku na časové razítko, které můžete zadat do druhého. Omezte dotaz na log na proces klienta a krátké okno a dostanete stránku výstupu místo celého dne. Zkopírujte identifikátor modelu, build klienta a síť, na které jste byli, do stejné poznámky, dokud je obrazovka ještě před vámi; zpráva sestavená příští ráno ztrácí pořadí, které ji dělalo čitelnou.

Vyberte snímek, který odpovídá symptomu

Apple dokumentuje tři snímky v průvodci diagnostikou Activity Monitor a ty odpovídají na různé otázky. Sample Process sleduje jeden vybraný proces tři sekundy, spindump cílí na aplikaci, která přestala odpovídat a brzy bude nucena ukončit, a System Diagnostics shromažďuje systémové logy do balíku.

Vybírejte podle toho, co jste pozorovali, ne podle zvyku. Klient, který běží, ale chová se špatně, dostane sample, pořízený s sample <pid> 3 -file ~/Desktop/sample.txt nebo z nabídky ozubeného kola. Aplikace, která se točí věčně a musí být zabita, dostane položku Spindump ze stejné nabídky. Problém, který zahrnuje klienta i systém, dostane sudo sysdiagnose -f ~/Desktop. Pořiďte sample před nuceným ukončením, kdykoli můžete, protože ukončení ničí přesně ten stav, který jste chtěli prohlédnout, a pojmenujte soubor podle události a času, ne podle svého odhadu příčiny.

Ke každému balíku přistupujte jako k citlivému. Tyto zprávy nesou názvy účtů, názvy hostitelů, cesty a síťové podrobnosti, proto je posílejte kanálem podpory, který vaše organizace používá, místo abyste je přikládali k veřejnému vláknu. Pokud je třeba zprávu zkrátit, zkraťte kopii a originál nechte nedotčený.

Když se sám ukazatel nehýbe

Mrtvé rozhraní mění pořadí operací. Nemůžete pořídit sample procesu ani spustit dotaz ze shellu, který neodpovídá, takže prvním cílem je obnova a druhým záznam. Nucený restart je někdy jediná cesta ven a je to také okamžik, kdy mizí nejužitečnější detaily. Poznamenejte čas, otevřená okna a zda síťová nabídka před restartem ukazovala připojení; tato pozorování přežijí restart, i když stav procesu ne.

Když je stroj zpět, odolejte závěru, že restart našel viníka. Obnovil službu a nic nepojmenoval. Pouze opakování s jednou kontrolovanou změnou může ukázat na komponentu.

Pokud se zamrznutí vrací, měňte jednu podmínku na pokus: síť, verzi klienta nebo režim spánku. Nejprve uložte vzdálenou práci a vyhněte se opakování nucených spánků na produkčním stroji, protože opakované tvrdé cykly riskují ztrátu dat a často dávají jinou poruchu, než kterou pronásledujete. Zapište každý pokus s jeho podmínkami, aby byl další srovnatelný, ne anekdotický.

Předejte jednu událost, ne náladu

Předání, které přinese akci, pojmenuje čtyři věci: co přestalo odpovídat, kdy se to stalo, jak v tu chvíli vypadala síť a který snímek pokrývá okno. Přidejte verzi klienta a build macOS a pak přestaňte. Tým platformy i dodavatel klienta mohou na tu větu reagovat a ani jeden nemůže reagovat na popis frustrace. Držte záznam na jednom místě a doplňujte ho, místo abyste příběh pokaždé znovu vyprávěli; pokud aktualizace změnila chování, uveďte kterou, protože i to je důkaz.

Dobrý záznam také uvádí, co jste už vyloučili. Pokud místní aplikace během zamrznutí odpovídala, řekněte to; pokud log spánku ukazuje skutečné probuzení, a ne zamčení, řekněte i to. Další člověk by neměl opakovat testy, které jste už provedli.

Než zavřete tiket, zkontrolujte tři věci: časové razítko pochází z logu spánku, ne z paměti, snímek odpovídá symptomu, který jste skutečně viděli, a balík leží na schváleném místě. Pokud některá ze tří chybí, zpráva není připravena k odeslání.