Kernel Oops przy starcie VPN: dowody, które warto zachować

Uruchomienie klienta VPN to wygodny znacznik czasu, a nie przyczyna, i ta różnica decyduje, co stanie się dalej. Gdy w pobliżu tego momentu pojawia się kernel Oops, wybór jest między zebraniem użytecznego raportu o błędzie a wywołaniem tej samej awarii jeszcze pięć razy na maszynie produkcyjnej. Zapisz cztery rzeczy przed restartem: dokładny build jądra, pierwszy ślad błędu, stan taint i krótki opis wszystkiego innego, co zmieniło się w tej samej minucie. Reszta to interpretacja, a interpretacja może poczekać, aż dowody znajdą się w bezpiecznym miejscu.

Złap pierwszy błąd, a nie ostatnią linię

Pierwszy Oops w logu jest tym, który ma znaczenie, ponieważ każdy późniejszy błąd może być szkodą uboczną już niezdrowego jądra. Skopiuj nagłówek razem ze śladem wywołań, ponieważ nagłówek zawiera instrukcję, która zawiodła, oraz stan rejestrów identyfikujący ścieżkę kodu. Raport zaczynający się od ostatniej linii jest niewiele wart dla kogoś, kto przeczyta go tydzień później.

Jeśli maszyna została już zrestartowana, bufor jądra z poprzedniego uruchomienia często wciąż jest w dzienniku, pod warunkiem że wtedy było włączone trwałe przechowywanie. Odczytaj go z zapisanego pliku zamiast odtwarzać obciążenie, ponieważ druga reprodukcja może nadpisać to, czego potrzebujesz. Tam, gdzie maszyna nie może utrzymać dziennika między restartami, konsola szeregowa lub netconsole to jedyny sposób, by błąd kiedykolwiek stał się widoczny.

Ustal build, zanim przeczytasz jakikolwiek symbol

Nazwy funkcji i offsety mają znaczenie tylko względem pliku binarnego, który je utworzył, więc zapisz razem ciąg wydania jądra i identyfikator builda dystrybucji. Plik symboli z innego builda z pełnym przekonaniem wskazuje niewłaściwą linię, co jest gorsze niż brak jakiegokolwiek symbolu. Zachowaj wersję pakietu jądra, nie tylko numer upstream, ponieważ dystrybucje wiele przenoszą wstecz.

Moduły spoza drzewa zasługują na własną linię w zapisie, ponieważ jądro z taintem ogranicza to, co opiekun może wywnioskować. Odczytaj wartość taint zamiast wywnioskować ją z listy modułów.

Niezerowy taint nie jest oskarżeniem i nie czyni raportu bezwartościowym. Mówi czytelnikowi, które komponenty były załadowane w chwili błędu, a niektóre flagi powodują, że raport jest obniżany w priorytecie przez politykę, a nie przez osąd. Zapisz wartość, nazwy modułów i to, czy ten sam sprzęt i obciążenie kiedykolwiek uruchamiały jądro bez nich. Właśnie to ostatnie porównanie oddziela nową regresję od wieloletniego błędu.

Oddziel wyzwalacz od defektu

Uruchomienie tunelu zwykle ćwiczy ścieżkę, która już istniała: sterownik sieciowy, dyscyplinę kolejki, funkcję offload lub stan zasilania. Wyzwalacz wyjaśnia, kiedy błąd się pojawia, a nie który kod jest błędny, a traktowanie wyzwalacza jako przyczyny prowadzi do serii zmian konfiguracji, które nic nie naprawiają.

Działający wcześniejszy obraz to dowód, a nie dowodzenie. Przy porównywaniu zmieniaj jeden komponent na uruchomienie i trzymaj wyniki gdzieś, co przetrwa maszynę.

Sprawdź, czego opiekun naprawdę może użyć

Przeczytaj raport tak, jak przeczytałby go obcy, zanim go wyślesz. Jeśli konfiguracja, dokładna sekwencja i tożsamość builda są obecne, a dane uwierzytelniające usunięte, raport jest użyteczny. Jeśli to zrzut ekranu śladu stosu, wróci z prośbą o te same informacje. Przewodnik po tropieniu błędów jądra opisuje, jak wyglądają użyteczny ślad i pasujące symbole.

uname -r
cat /proc/sys/kernel/tainted
journalctl -k -b -1 --no-pager | sed -n '/BUG:/,/Call Trace/p'
dmesg -T | grep -A 40 'RIP:'

Każde polecenie powyżej tylko czyta stan, a pierwsze dwa należy uruchomić przed następnym restartem, jeśli maszyna wciąż potrafi na nie odpowiedzieć. Tam, gdzie dziennik nie jest trwały, właśnie te dwa będą jedynymi, które kiedykolwiek znów zadziałają.

Usuń klucze, hasła i niepowiązany ruch, ale zachowaj nazwy funkcji i offsety, których ktoś potrzebuje do odczytania śladu. Wyślij materiał drogą zgłoszeniową właściwą dla dystrybucji lub jądra, a nie publicznym wklejeniem z dołączoną nazwą hosta. Potem czekaj na pytanie zamiast zbierać kolejne awarie, ponieważ zlokalizowany błąd wobec pasującego builda to jedyny wynik, który posuwa raport do przodu. Jeśli nic nie wróci, rozwiązaniem zastępczym jest kontrolowana reprodukcja na zapasowym sprzęcie, nigdy na maszynie, od której zależą inni ludzie.