Odnaleźć, dlaczego usługa systemd jest w stanie niepowodzenia

Usługa, która przechodzi w failed, nie potrzebuje natychmiastowego ponownego uruchomienia. Na serwerze ten nawyk czasami usuwa wiadomość, która wyjaśnia awarię, lub uruchamia program z nadal nieprawidłową konfiguracją.

Zacznij od zidentyfikowania jednostki, sprawdzenia jej stanu i dziennika, a następnie napraw przyczynę. Restart następuje później.

Tux sprawdza lampkę błędu na serwerze Linux — Usługę, która jest w awarii, diagnostykuje się w jej stanie i dzienniku przed ponownym uruchomieniem.

Lista jednostek rzeczywiście w awarii

To polecenie wyświetla usługi i jednostki, które systemd uznaje za niedziałające:

systemctl --failed

Zapisz pełną nazwę, na przykład nginx.service lub moja-aplikacja.service. Jednostka exited nie jest koniecznie w awarii: niektóre usługi wykonują krótkie zadanie, a następnie normalnie się zatrzymują. Status failed wskazuje, że uruchomienie, polecenie kontrolne lub monitorowany proces zakończył się błędem.

Aby przeglądać usługi aktywne, zatrzymane i ich stany, sprawdź również listę usług za pomocą systemctl.

Sprawdź stan usługi przed jakimkolwiek restartem

Podmień nginx na swoją jednostkę. Opcja --no-pager wypisuje wynik bezpośrednio w terminalu, co zapobiega pozostaniu w less podczas sesji SSH.

sudo systemctl status nginx --no-pager

Przede wszystkim zwróć uwagę na linię Active:, kod wyjścia oraz ostatnie wyświetlane linie. Już zajęty port, brakująca ścieżka, nieczytelny certyfikat lub źle napisany dyrektyw często pojawiają się tutaj. Jeśli usługa uruchamia binarne, które ma swój własny walidator, uruchom najpierw ten walidator. Dla Nginx, na przykład:

sudo nginx -t

Nie uruchamiaj tego polecenia na maszynie, która nie używa Nginxa. Każda usługa ma swoją składnię sprawdzania.

Zlokalizuj wiadomość o błędzie za pomocą journalctl

systemctl status pokazuje tylko fragment. Dziennik jednostki daje pełny kontekst:

sudo journalctl -u nginx -b --no-pager
sudo journalctl -u nginx -n 50 --no-pager

-b ogranicza poszukiwania do bieżącego uruchomienia. -n 50 zachowuje ostatnie 50 linii, jeśli awaria jest starsza. Aby śledzić na bieżąco ponowne uruchomienie, użyj sudo journalctl -fu nginx w drugiej sesji SSH. Przewodnik journalctl i wiadomości z ostatniego uruchomienia pomaga poszerzyć diagnostykę, gdy błąd dotyczy wielu usług.

Poprawić, uruchomić ponownie, a następnie sprawdzić

Po dokonaniu zmian w pliku jednostki lub drop-in systemd, przeładuj konfigurację. Ten krok nie uruchamia ponownie usługi.

sudo systemctl daemon-reload
sudo systemctl restart nginx
systemctl is-active nginx
systemctl --failed

is-active powinno odpowiedzieć active. Jeśli usługa nasłuchuje na porcie, sprawdź również ten port i przetestuj z poprawnego klienta. Odpowiedź active nie gwarantuje, że aplikacja webowa, proxy lub baza danych akceptuje już żądania.

W przypadku usługi krytycznej, trzymaj otwartą drugą sesję SSH przed ponownym uruchomieniem i skopiuj dokładny błąd do swojego zgłoszenia lub notatek. Unikniesz powtarzania tej samej diagnostyki podczas następnego zdarzenia.