Mac zawiesza się po wybudzeniu z VPN: co zarejestrować

Raporty o zawieszonym Macu po wybudzeniu często łączą trzy awarie w jedną skargę. Wskaźnik może jeszcze się poruszać, gdy klient VPN ignoruje kliknięcia, klient może działać, gdy jedna sesja zdalna wygasa, albo cały pulpit może przestać przyjmować dane wejściowe. Każdy z tych przypadków wymaga innych dowodów, a pierwsza minuta po zawieszeniu decyduje, z którym masz do czynienia. Błędne przypuszczenie kieruje każdy kolejny krok w złą stronę.

Co przestało odpowiadać, a co tylko przestało czekać

Zacznij od najtańszych testów: przesuń wskaźnik i wpisz tekst w lokalnym polu, otwórz własny widok stanu klienta i odczytaj zgłaszany stan, a następnie rozpocznij nową operację w aplikacji prywatnej zamiast wznawiać już otwartą sesję. Zapisz trzy odpowiedzi, zanim cokolwiek innego dotkniesz, bo kolejność tego, co zawiodło, jest pierwszym szczegółem, który ludzie zapominają.

Każdy wynik wskazuje gdzie indziej. Jedna zablokowana sesja umieszcza dowód po drugiej stronie tunelu, a Mac jest tylko obserwatorem. Klient, który ignoruje kliknięcia, podczas gdy pulpit jeszcze działa, zawęża poszukiwania do tego procesu i jego dziennika. Maszyna, która ignoruje wskaźnik, odbiera możliwość uruchomienia czegokolwiek, bo każde polecenie kontrolne potrzebuje powłoki, która odpowiada.

Trzymaj trzy przypadki osobno, nawet gdy użytkownik opisuje je jednym zdaniem. Raport, który składasz, powinien mówić, który test zawiódł pierwszy, a które jeszcze przeszły, a nie że maszyna się zawiesiła. Ta różnica pozwala inżynierowi wsparcia zdecydować, czy patrzeć na sieć, klienta czy sprzęt.

Oś czasu, której jutro nadal możesz bronić

Zegar to ta część zapisu, której nie da się później odtworzyć. Zanotuj, kiedy otworzyła się pokrywa lub obudziła maszyna, kiedy nastąpiła pierwsza nieudana czynność, i czy te dwa momenty dzieliły sekundy czy minuty. Następnie zapisz, czy Mac naprawdę spał, czy tylko zablokował ekran, bo to różne stany z różnymi ścieżkami wybudzania. Dziennik snu to jedyna część tej osi czasu, którą możesz sprawdzić później.

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

Pierwsze polecenie zamienia mgliste wspomnienie w znacznik czasu, który możesz wpisać w drugim. Ogranicz zapytanie dziennika do procesu klienta i krótkiego okna, a dostaniesz stronę wyników zamiast całego dnia. Skopiuj identyfikator modelu, kompilację klienta i sieć, w której byłeś, do tej samej notatki, dopóki ekran jest jeszcze przed tobą; raport złożony następnego ranka traci porządek, który czynił go czytelnym.

Wybierz przechwycenie pasujące do objawu

Apple dokumentuje trzy przechwycenia w przewodniku diagnostycznym Activity Monitor, i odpowiadają one na różne pytania. Sample Process obserwuje jeden wybrany proces przez trzy sekundy, spindump celuje w aplikację, która przestała odpowiadać i wkrótce zostanie wymuszona do zamknięcia, a System Diagnostics zbiera dzienniki systemowe do pakietu.

Wybieraj według tego, co zaobserwowałeś, a nie według przyzwyczajenia. Klient, który działa, ale zachowuje się źle, dostaje sample, pobrany przez sample <pid> 3 -file ~/Desktop/sample.txt lub z menu zębatki. Aplikacja, która kręci się bez końca i trzeba ją zabić, dostaje pozycję Spindump z tego samego menu. Problem obejmujący klienta i system dostaje sudo sysdiagnose -f ~/Desktop. Zrób sample przed wymuszonym zamknięciem, gdy możesz, bo zakończenie niszczy dokładnie ten stan, który chciałeś zbadać, a plik nazwij od zdarzenia i czasu, nie od swojego domysłu o przyczynie.

Traktuj każdy pakiet jako wrażliwy. Te raporty zawierają nazwy kont, nazwy hostów, ścieżki i szczegóły sieci, więc wysyłaj je kanałem wsparcia używanym przez twoją organizację, zamiast dołączać je do publicznego wątku. Jeśli raport trzeba skrócić, skróć kopię, a oryginał pozostaw nietknięty.

Kiedy sam wskaźnik się nie rusza

Martwy interfejs zmienia kolejność czynności. Nie możesz pobrać sample procesu ani uruchomić zapytania z powłoki, która nie odpowiada, więc pierwszym celem jest przywrócenie, a drugim zapis. Wymuszony restart jest czasem jedynym wyjściem i jest też momentem, w którym znikają najcenniejsze szczegóły. Zanotuj czas, otwarte okna i to, czy menu sieci pokazywało połączenie przed restartem; te obserwacje przetrwają restart, choć stan procesu nie.

Gdy maszyna wróci, opieraj się wnioskowi, że restart znalazł winnego. Przywrócił usługę i nic nie wskazał. Tylko powtórzenie z jedną kontrolowaną zmianą może wskazać komponent.

Jeśli zawieszenie wraca, zmieniaj jeden warunek na próbę: sieć, wersję klienta lub tryb uśpienia. Najpierw zapisz pracę zdalną i unikaj powtarzania wymuszonych uśpień na maszynie produkcyjnej, bo powtarzane twarde cykle grożą utratą danych i często dają inną awarię niż ta, którą ścigasz. Zapisuj każdą próbę z jej warunkami, aby następna była porównywalna, a nie anegdotyczna.

Przekaż jedno zdarzenie, nie nastrój

Przekazanie, które wywołuje działanie, nazywa cztery rzeczy: co przestało odpowiadać, kiedy to się stało, jak wyglądała sieć w tej chwili i które przechwycenie obejmuje to okno. Dodaj wersję klienta i kompilację macOS, a potem przestań. Zarówno zespół platformy, jak i dostawca klienta mogą działać na podstawie tego zdania, a żaden nie może działać na podstawie opisu frustracji. Trzymaj zapis w jednym miejscu i dopisuj do niego, zamiast za każdym razem opowiadać historię od nowa; jeśli aktualizacja zmieniła zachowanie, wskaż którą, bo to też dowód.

Dobry zapis mówi też, co już wykluczyłeś. Jeśli lokalna aplikacja odpowiadała podczas zawieszenia, powiedz to; jeśli dziennik snu pokazuje prawdziwe wybudzenie, a nie blokadę, powiedz i to. Następna osoba nie powinna powtarzać testów, które już wykonałeś.

Przed zamknięciem zgłoszenia sprawdź trzy rzeczy: znacznik czasu pochodzi z dziennika snu, a nie z pamięci, przechwycenie pasuje do objawu, który naprawdę widziałeś, a pakiet znajduje się w zatwierdzonym miejscu. Jeśli brakuje którejkolwiek z trzech, raport nie jest gotowy do wysłania.