Systemctl: jak sprawdzić, dlaczego usługa nie działa

KROK 01

Najpierw sprawdź listę jednostek

Zanim przejdziesz do szczegółów konkretnej usługi, zorientuj się w ogólnym stanie systemu. Polecenie systemctl --failed wyświetla wszystkie jednostki, które zakończyły się błędem. To najszybszy sposób, aby sprawdzić, czy problem dotyczy jednej usługi, czy kilku naraz. Jeśli lista jest pusta, nie ma jednostek w stanie failed – nie oznacza to jednak, że wszystko działa poprawnie, bo usługa może być po prostu nieuruchomiona.

Polecenie list-unit-files --type=service pokazuje pliki jednostek i stan powiązań używanych do ich aktywowania. Enabled oznacza utworzone powiązania zgodne z sekcją Install; nie gwarantuje, że usługa wystartuje i pozostanie sprawna. Disabled oznacza brak takich powiązań, ale jednostkę nadal może uruchomić zależność, gniazdo lub administrator. Static oznacza brak instrukcji bezpośredniego włączania w sekcji Install, a nie zakaz uruchamiania.

Pamiętaj, że list-unit-files nie pokazuje aktualnie uruchomionych procesów, tylko to, co systemd wie o plikach .service. Jeśli jednostki w ogóle nie ma na liście, to znaczy, że nie jest zainstalowana lub plik .service nie znajduje się w standardowych lokalizacjach.

systemctl --failed
systemctl list-unit-files --type=service

Pusta lista --failed oznacza brak jednostek w stanie failed w danym menedżerze systemd. Nie jest to potwierdzenie działania wszystkich aplikacji: zatrzymana usługa lub błąd wewnętrzny aplikacji może nie wystąpić na tej liście.

systemctl list-unit-files --type=service wyświetla tabelę z nazwami plików .service i stanem w kolumnie STATE. Możesz od razu zobaczyć, które usługi są wyłączone.

KROK 02

Odczytaj status właściwej usługi

Sprawdź status konkretnej jednostki. Nginx.service jest przykładem — użyj nazwy usługi faktycznie zainstalowanej na swoim serwerze. Status pokazuje między innymi stan, procesy i dostępne ostatnie komunikaty. Opcja --no-pager wyłącza dodatkowy program do przeglądania wyniku: odpowiedź trafia bezpośrednio do terminala.

Is-active i is-enabled odpowiadają na różne pytania. Pierwsze dotyczy aktualnego stanu jednostki, drugie jej powiązań aktywacji. Aktywna usługa nie musi mieć stanu enabled; enabled nie oznacza, że proces działa. Stan inactive może być też oczekiwany dla zadania, które poprawnie zakończyło pracę. Interpretuj go zgodnie z rolą konkretnej jednostki.

Jeśli polecenie status zwróci kod wyjścia 3 i komunikat inactive, nie oznacza to błędu polecenia. Kod 3 to standardowy sygnał dla jednostki nieaktywnej. Gdy systemd zwraca unit not found, oznacza to, że jednostka o podanej nazwie nie istnieje – sprawdź pisownię lub czy pakiet w ogóle jest zainstalowany.

systemctl status nginx.service --no-pager
systemctl is-active nginx.service
systemctl is-enabled nginx.service

systemctl status pokazuje pełny stan: Active: active (running) oznacza działającą usługę; inactive (dead) to zatrzymana; failed to błąd. Linia Loaded wskazuje, czy jednostka jest enabled czy disabled.

systemctl is-active zwraca słowo active, inactive lub failed. systemctl is-enabled zwraca enabled, disabled lub static.

KROK 03

Podejrzyj konfigurację bez edycji

Zanim cokolwiek zmienisz, obejrzyj zawartość pliku jednostki poleceniem systemctl cat. Wyświetla ono pełną treść pliku .service wraz z plikami drop-in, które nadpisują oryginalne ustawienia. To bezpieczniejszy sposób niż otwieranie pliku edytorem, ponieważ nie ryzykujesz przypadkowej modyfikacji.

Systemctl show z parametrem -p wybiera konkretne pola. ActiveState i SubState opisują stan jednostki, Result wynik działania, a ExecMainStatus wartość statusu głównego procesu. To ostatnie pole należy czytać wraz ze sposobem zakończenia procesu i dziennikiem: nie każdy numer ma takie samo znaczenie w każdej aplikacji, a zakończenie sygnałem różni się od zwykłego kodu wyjścia.

Definicja jednostki może zawierać dane wrażliwe wpisane w argumentach lub zmiennych środowiska. Systemctl cat pokazuje tekst plików jednostki i dodatków, a nie zanonimizowany raport. Przed przekazaniem wyniku do wsparcia usuń hasła, tokeny i prywatne adresy. Sama ścieżka EnvironmentFile nie oznacza, że cat odczyta też zawartość tego wskazanego pliku.

systemctl cat nginx.service
systemctl show nginx.service -p ActiveState -p SubState -p Result -p ExecMainStatus

systemctl cat wyświetla połączoną konfigurację jednostki, w tym pliki drop-in. Widać sekcje Unit, Service, Install i wszystkie parametry.

Wybrane pola pomagają zestawić stan jednostki z jej ostatnim wykonaniem. Dla różnych typów usług można zobaczyć między innymi running, exited lub dead. Wynik success nie potwierdza poprawności wszystkich funkcji aplikacji, a pojedynczy numer ExecMainStatus nie zastępuje analizy dziennika.

KROK 04

Połącz status z logami

Sam status usługi często nie wystarcza do diagnozy. Polecenie journalctl z parametrem -u wyświetla komunikaty dziennika powiązane z daną jednostką. Parametr -b ogranicza wyniki do bieżącego rozruchu, a -n 100 pokazuje ostatnie 100 wpisów. To standardowy zestaw do szybkiej diagnostyki.

Jeśli nie masz uprawnień do odczytu dziennika, dodaj sudo przed poleceniem. W niektórych dystrybucjach zwykły użytkownik może czytać tylko własne logi, a logi systemowe wymagają podniesienia uprawnień. Brak wpisów w dzienniku nie musi oznaczać, że usługa jest zdrowa – może po prostu nie generować logów do journald.

Przeglądając logi, zwróć uwagę na daty i godziny i kody błędów. Komunikat błędu często pojawia się kilka linii przed faktycznym wpisem o niepowodzeniu. Nie ograniczaj się tylko do ostatnich 100 wpisów, jeśli podejrzewasz, że problem wystąpił wcześniej – zwiększ liczbę lub usuń -n, aby zobaczyć cały dziennik z bieżącego uruchomienia systemu.

journalctl -u nginx.service -b -n 100 --no-pager

Dziennik pokazuje chronologicznie wpisy dla jednostki od bieżącego rozruchu. Każdy wpis zawiera datę, nazwę procesu, PID i komunikat. Szukaj fraz error, failed, cannot, permission denied.

KROK 05

Restart i reload rozwiązują różne problemy

Restart zatrzymuje jednostkę i uruchamia ją ponownie. Może przerwać pracę, a jego wpływ na połączenia zależy od aplikacji. Reload zleca przeładowanie konfiguracji w sposób obsługiwany przez daną usługę; nie zawsze jest to wysłanie jednego sygnału. Nie każda jednostka wspiera tę operację. Zanim wybierzesz którąś z nich, sprawdź dokumentację aplikacji i potrzebę zmiany.

Jeśli edytowałeś plik jednostki systemd, musisz wykonać systemctl daemon-reload, aby systemd odczytał zmiany. To nie to samo co przeładowanie konfiguracji aplikacji – daemon-reload dotyczy tylko definicji jednostek. Pominięcie tego kroku to jedna z najczęstszych przyczyn, dla których zmiany w pliku .service nie działają.

Pamiętaj: włączenie usługi (enable) nie uruchamia jej od razu – dopiero start uruchamia proces. I odwrotnie: samo uruchomienie (start) nie powoduje, że usługa wystartuje automatycznie po restarcie systemu. To częste źródło nieporozumień, zwłaszcza u osób zaczynających pracę z systemd.

W sekcji diagnostycznej nie wykonujemy restartów ani przeładowań – najpierw trzeba zrozumieć przyczynę problemu. Te operacje wykonuj dopiero po analizie logów i konfiguracji.

KROK 06

Jak rozpoznać brakującą jednostkę lub restart loop

Komunikat Unit nginx.service not found różni się od inactive. Not found oznacza, że systemd nie zna takiej jednostki – nie ma pliku .service w standardowych lokalizacjach. Sprawdź, czy pakiet jest zainstalowany, lub czy nazwa jednostki jest poprawna (np. httpd.service zamiast nginx.service na dystrybucjach z Apache). Z kolei failed to stan, w którym jednostka istnieje, ale nie udało się jej uruchomić.

Restart loop to sytuacja, gdy usługa ciągle restartuje się po krótkim czasie. W systemctl status zobaczysz wpisy Active: activating (auto-restart) lub wiele następujących po sobie wpisów start/stop. W logach journalctl pojawią się powtarzające się błędy. Przyczyną może być błąd składni konfiguracji aplikacji, brakujące zależności, konflikt portów lub zbyt szybkie kończenie procesu przez Restart=always.

Nie próbuj na siłę resetować stanu usługi za pomocą systemctl reset-failed, jeśli nie znasz przyczyny awarii – maskujesz objaw, nie leczysz problemu. Zawsze najpierw sprawdź logi, kod wyjścia i konfigurację. W przypadku Nginx sprawdź składnię konfiguracji narzędziem nginx -t. W innych aplikacjach szukaj dedykowanych narzędzi do walidacji składni.

Przy Unit not found zacznij od poprawności nazwy i listy dostępnych jednostek. Zmiana ExecStart w innej jednostce nie rozwiązuje braku szukanego pliku. Przy pętli restartów najważniejsze są powtarzający się komunikat aplikacji, stan jednostki i przyczyna jej zakończenia. Nie usuwaj historii awarii przed jej sprawdzeniem.