Usługa systemd właśnie się zawiesiła i znasz już jej nazwę, ale dziennik nie wystarcza, aby zidentyfikować proces, który faktycznie się zawiesił. Zanim ponownie uruchomisz jednostkę lub zmodyfikujesz jej konfigurację, zanotuj godzinę incydentu, a następnie poszukaj zrzutu pamięci powiązanego z coredumpctl.
Przed pierwszym poleceniem sprawdź następujące punkty:
- znana jest jednostka systemd, której dotyczy problem;
- aproksymacyjny czas awarii jest dostępny;
- masz niezbędne uprawnienia do odczytu dziennika i zrzutu;
- plik nie może być wysyłany poza maszynę ani dzielony w tej formie.
Rozpocznij od czasu i procesu awarii
Wyświetl dostępne wpisy bez otwierania paginacji:
coredumpctl --no-pager listPolecenie wyświetla między innymi TIME, PID, użytkownika, sygnał, stan przechowywania oraz ścieżkę do pliku wykonywalnego. Zwróć uwagę na linię, której godzina odpowiada zatrzymaniu usługi. PID pozwala uniknąć zamieszania pomiędzy dwoma procesami o podobnych nazwach.
Kolumna COREFILE wskazuje na możliwy sposób postępowania. present oznacza, że plik jest dostępny, podczas gdy journal wskazuje na treść zachowaną w dzienniku. missing oznacza, że wpis istnieje, mimo że plik zniknął. Wartość none, error lub truncated ogranicza analizę. Dziennik może zatem zachować ślad awarii po usunięciu powiązanego pliku, szczególnie w /var/lib/systemd/coredump.
Jeszcze nie uruchamiaj coredumpctl debug. To polecenie otwiera debuggery na wybranym zrzucie pamięci, nie wyjaśniając automatycznie przyczyny ani nie przywracając usługi do stanu.
Odczytanie zrzutu celowego z coredumpctl info
Po zanotowaniu PID, poproś o metadane tego wpisu:
coredumpctl info <PID>Jeśli lista dostarcza raczej ścieżki do wykorzystania, skieruj się na tę ścieżkę:
coredumpctl info /usr/bin/nazwa-wykonywalnegoZamień wartości w nawiasach kątowych na te z Twojego wyjścia. Polecenie wyświetli PID, sygnał, znacznik czasu, linię polecenia, plik wykonywalny i zajmowaną przestrzeń. Może także ujawnić jednostkę systemd w polu Unit, a także ścieżkę przechowywania i jej status.
Pole Unit łączy zrzut z diagnostyką systemd. Sprawdź, czy odpowiada on usłudze, która się zawiesiła i czy czas pokrywa się z obserwowanym objawem. Sam PID nie wystarczy, jeśli kilka wykonania nastąpiło z szybko. Użytkownik bez pełnego dostępu do dziennika może również widzieć tylko część wpisów, często tych dotyczących jego własnych procesów.
Krzyżować zrzut z dziennikiem jednostki
Po uzyskaniu dokładnej nazwy jednostki oraz godziny awarii, przejrzyj krótki wyciąg wokół tego momentu:
journalctl -u nazwa-jednostki --since "10 minut temu" --until "teraz"Dla starszego incydentu, zamień okno względne na dwa znaczniki czasowe, które otoczą ten wyświetlony przez coredumpctl info. Dziennik powinien pokazać zatrzymanie procesu, kod wyjścia lub sygnał, próby ponownego uruchomienia oraz wiadomości napisane tuż przed awarią.
Licznik awarii nie podaje przyczyny. Jeśli jednostka nadal jest oznaczona jako failed, przewodnik dotyczący systemctl reset-failed przypomina o różnicy między stanem śledzonym przez systemd a błędem, który pojawia się w dzienniku. Aby odczytać zdarzenia poprzedzające awarię, Twój dziennik usługi z journalctl zapewnia odpowiednie filtry.
Jeśli dziennik jednostki nie wystarcza, a wiadomości nawiązują do sterownika, dysku lub jądra, sprawdź także wiadomości jądra z dmesg. Ta weryfikacja ma na celu potwierdzenie niskopoziomowego incydentu, nie zastępując odczytu z usługi.
Przechowywanie zrzutów pamięci w kontrolowanej strefie
Zrzut pamięci może zawierać część pamięci procesu w momencie awarii. W zależności od aplikacji, ta pamięć może zawierać dane w trakcie przetwarzania, identyfikatory, tokeny lub fragmenty konfiguracji. Traktuj ten plik jak dane wrażliwe, nawet jeśli jego nazwa przypomina prosty artefakt techniczny.
Oficjalna dokumentacja coredumpctl rozróżnia odczyt metadanych, wydobywanie z użyciem dump i uruchamianie debuggera z debug. Na maszynie produkcyjnej zatrzymaj się po info, dopóki nie zostaną zweryfikowane obszar analizy, prawa dostępu i miejsce przechowywania roboczego. Improwizowany eksport lub wysłanie pliku osobie trzeciej może ujawnić znacznie więcej niż nazwa usługi, która zawiodła.
Jeśli coredumpctl jest nieobecny lub lista pozostaje pusta, dalsze kroki zależą od dystrybucji i jej polityki zbierania systemd-coredump. Sprawdź tę politykę z dokumentacją swojego systemu przed wprowadzeniem zmian w produkcji.