Segfault klienta VPN na Pi? Najpierw zapisz proces
Powłoka wypisuje segmentation fault, a karta jest ponownie wgrywana. Zapisz plik wykonywalny, wersję i zapis awarii, zanim wymienisz jakikolwiek sprzęt.
Uruchamiasz klienta, terminal wypisuje Segmentation fault (core dumped), a następna godzina idzie na ponowne wgrywanie karty. Ten komunikat opisuje, jak jeden proces zginął w jednej chwili. Nie mówi, że płytka jest uszkodzona, i nie oczyszcza z podejrzeń zasilania, pamięci masowej ani obrazu.
Zacznij od wiersza wypisanego przez powłokę i cofnij się do procesu, który za nim stoi. Przydatne fakty to: który plik wykonywalny zawiódł, w jakim środowisku i na którym etapie połączenia.
Zacznij od wiersza wypisanego przez powłokę
Nazwa w twoim poleceniu jest często nakładką lub programem uruchamiającym, który startuje inny plik binarny, więc potwierdź, który plik wykonywalny jądro rzeczywiście zakończyło. Zapisz pełną ścieżkę, wersję pakietu i aplikacji, architekturę, wydanie systemu i jądra, konto, które go uruchomiło, oraz dokładny czas. Polecenie powłoki o nazwie VPN łatwo uruchamia proces pomocniczy, a zapis wskaże właśnie ten proces pomocniczy. Skopiowanie ciągu wersji z pakietu zainstalowanego w zeszłym miesiącu nie mówi nic o tym, co działało.
Zanotuj, co bezpośrednio poprzedziło awarię: uruchomienie, parsowanie profilu, uwierzytelnianie albo sesję, która już przepuszczała ruch. Te cztery etapy zawężają poszukiwania znacznie bardziej niż słowo segfault. Zachowaj krótkie okno logów wokół tego zdarzenia, a domysły, która niedawna zmiana to spowodowała, zostaw, dopóki zapis tego nie powie.
Sprawdź, czy istnieje obraz pamięci
Dokumentacja pliku core opisuje zrzut jako obraz pamięci procesu zapisywany przy zakończeniu i wymienia także warunki, które temu zapisowi przeszkadzają. Należą do nich zerowy limit zasobów oraz wzorzec core kierujący zrzut poza katalog roboczy. Brak pliku o nazwie core nic więc nie dowodzi w kwestii tego, czy awaria wystąpiła. Sprawdź skonfigurowany wzorzec i limit, zanim uznasz, że system nie wytworzył dowodu.
W systemie korzystającym z kolektora systemd obsługiwany widok wiąże zapisany rekord z plikiem wykonywalnym i czasem. Wpis w dzienniku i czytelny obraz pamięci to dwa różne artefakty: polityka retencji i uprawnienia mogą zostawić ci jeden bez drugiego. Zapytaj dystrybucję lub opiekuna aplikacji o obsługiwany przez nich przepływ diagnostyczny, ponieważ ślad z innej kompilacji lub innego zestawu bibliotek zwykle marnuje ich czas.
sysctl kernel.core_pattern
ulimit -c
coredumpctl list --since "1 hour ago" --no-pager
coredumpctl info /usr/sbin/openvpn
Powtórz te odczyty na maszynie, która naprawdę się wysypała. Robienie ich na świeżej instalacji odpowiada na pytanie, którego nikt nie zadał.
Traktuj zrzut jako materiał zawierający sekrety
Pamięć procesu może zawierać poświadczenia, klucze sesji i zawartość profilu, co czyni zrzut wrażliwszym niż sąsiedni log tekstowy. Redagowanie logu nic nie daje w przypadku nieprzejrzystego obrazu pamięci, a zwykłe systemy zgłoszeń trzymają załączniki znacznie dłużej, niż trwa wątek wsparcia. Przenieś plik prywatnym kanałem udostępnionym przez dostawcę lub opiekuna. Opublikowanie surowego zrzutu w publicznym zgłoszeniu ujawnia wszystko, co było w pamięci w chwili śmierci procesu, a nie możesz wiedzieć co to było, dopóki ktoś tego nie zbada.
Jeśli opiekun prosi o ślad, zapytaj, z którego pliku wykonywalnego i których bibliotek go chce. Backtrace, którego ramki nie pasują do zgłoszonej kompilacji, trudno zaufać i łatwo odczytać błędnie.
Sprawdź pochodzenie, zanim cokolwiek wymienisz
Zweryfikuj pochodzenie pakietu i integralność plików u tego, kto posiada instalację, i zachowaj konfigurację oraz materiał tożsamości przed każdą kontrolowaną naprawą. Nie nadpisuj jedynej kopii dowodu tylko po to, by zobaczyć, czy czysta instalacja się uruchomi. Świeży obraz, który się uruchamia, mówi, że nowy obraz się uruchamia. Nie mówi, czy stary zawierał uszkodzony pakiet, zawodną kartę albo plik binarny, który zawsze zawiódłby na tej architekturze.
Jeśli zawodzą też niepowiązane programy albo system rejestruje błędy pamięci masowej, zasilania lub jądra, zachowaj te obserwacje do dochodzenia platformowego. Poszerzają zakres; nie dowodzą, że każdy segfault pochodzi od zawodnej pamięci RAM lub uszkodzonego obrazu.
Po ukierunkowanej poprawce powtórz to samo autoryzowane uruchomienie i tę samą operację VPN na tym samym sprzęcie. Powiedz, która awaria ustała i pod którą wersją. Czysty start sam w sobie nie wskazuje wadliwego podzespołu ani nie przewiduje następnej usterki sprzętowej.