Stan usług systemd: co działa, co startuje i co zgłasza błąd

W systemd trzeba sprawdzić osobno, czy usługa działa teraz i w jaki sposób może zostać uruchomiona. Status „enabled” opisuje konfigurację uruchamiania, a nie sprawność procesu. Z kolei usługa wyłączona z autostartu nadal może działać po ręcznym uruchomieniu lub wskutek zależności. Kilka poleceń odczytu pozwala rozdzielić te przypadki bez zmieniania systemu.

Dwie listy, dwa różne pytania

Na komputerze korzystającym z systemd zacznij od usług aktualnie działających:

systemctl list-units --type=service --state=running

To widok jednostek załadowanych przez menedżera, ograniczony do wskazanego stanu. Nie jest spisem wszystkich zainstalowanych usług. Jeśli szukasz również jednostek nieaktywnych, ale obecnych w tym widoku, użyj:

systemctl list-units --type=service --all

Natomiast lista dostępnych plików jednostek i ich konfiguracji uruchamiania wygląda tak:

systemctl list-unit-files --type=service

Przykładowo usługa może występować na drugiej liście jako „disabled”, a na pierwszej jako „running”. Nie ma tu sprzeczności: ktoś mógł ją uruchomić ręcznie. Również „enabled” obok usługi nie daje pewności, że ostatni start się udał. Do oceny konkretnej jednostki potrzebny jest jej bieżący status.

Odczytaj konkretną usługę

Skopiuj dokładną nazwę z listy, razem z końcówką .service. W poniższym przykładzie nazwa.service jest miejscem na tę nazwę:

systemctl status nazwa.service --no-pager

Zwróć uwagę na pola „Loaded”, „Active”, proces główny i końcowe komunikaty. „Loaded” pomaga ustalić, czy definicja została znaleziona. „Active” opisuje stan wykonania. Fragment dziennika na dole jest wygodnym podglądem, ale może obejmować zbyt mało wierszy, aby pokazać pierwszą przyczynę problemu.

Nie oceniaj wszystkich usług według wzorca serwera działającego bez przerwy. Jednostka typu oneshot może wykonać pracę i zakończyć proces. Jej dalszy stan zależy między innymi od ustawienia RemainAfterExit. To zachowanie trzeba porównać z przeznaczeniem jednostki, zamiast automatycznie naprawiać każdy napis „exited”.

Krótka odpowiedź o stanie i autostarcie

systemctl is-active nazwa.service
systemctl is-enabled nazwa.service

Pierwsze polecenie sprawdza bieżący stan, drugie konfigurację uruchamiania. Zwracają też kod zakończenia, przydatny w skryptach. Wynik inny niż sukces nie musi oznaczać uszkodzenia narzędzia: może po prostu odpowiadać usłudze, która nie jest aktywna lub włączona zgodnie z kryterium polecenia. W automatyzacji sprawdzaj udokumentowaną semantykę kodów, a nie wyłącznie tekst na ekranie.

„Static” oznacza, że jednostki nie włącza się zwykłym mechanizmem instalacyjnym tak jak typowej usługi z autostartem. Może być uruchamiana przez zależność lub inną jednostkę. „Masked” jest mocniejszym ograniczeniem niż „disabled”: blokuje uruchamianie jednostki. Samo wyłączenie autostartu nie zatrzymuje działającej usługi, a włączenie go bez odpowiedniej opcji nie jest równoznaczne z natychmiastowym startem.

Znajdź błędy, ale ustal ich znaczenie

systemctl --failed --type=service
systemctl is-system-running

Pierwsza lista pokazuje usługi w stanie błędu. Drugie polecenie opisuje stan menedżera systemowego; „degraded” może wynikać z nieudanej jednostki, nawet jeśli komputer realizuje podstawowe zadania. Sprawdź, która usługa zawiodła i do czego służy. Nie czyść listy błędów przed zapisaniem informacji, bo stracisz wygodny punkt odniesienia.

Jeżeli konkretna usługa nie startuje, skorzystaj z poradnika o szukaniu przyczyny nieudanego startu. Do szerszej historii przyda się filtrowanie dziennika za pomocą journalctl. Sam wpis „failed” opisuje wynik, nie wybiera jeszcze poprawki.

Nie pomyl usług systemowych z usługami użytkownika

Część aplikacji działa w menedżerze przypisanym do zalogowanego użytkownika. Sprawdza się je w tym samym koncie z opcją --user:

systemctl --user list-units --type=service --all
systemctl --user status nazwa.service --no-pager

Nie dodawaj automatycznie sudo do poleceń użytkownika: może to zmienić kontekst lub uniemożliwić dotarcie do właściwej sesji. Usługa niewidoczna w widoku systemowym nie musi być nieobecna na komputerze. Warto też sprawdzić, czy uruchamia ją timer lub socket; od tego zależy, kiedy proces powinien istnieć.

Na koniec potwierdź działanie funkcji: serwer powinien odpowiadać, a zadanie kopii tworzyć oczekiwany rezultat. Aktywny proces może pracować ze złą konfiguracją. Jeżeli diagnozujesz maszynę przez SSH, pozostań przy odczycie do czasu ustalenia roli jednostki. Przypadkowe zatrzymanie sieci lub dostępu zdalnego potrafi przerwać właśnie tę sesję, której potrzebujesz do naprawy.