systemctl: wszystkie sposoby na listę usług w Linuksie

Jedno polecenie, które trzeba znać: systemctl list-units --type=service

W każdej dystrybucji z systemd — Ubuntu od 15.04, Debian od 8, RHEL i CentOS od 7, a także Fedora, Arch i openSUSE — każda usługa jest jednostką systemd, a systemctl to narzędzie, które je wypisuje:

systemctl list-units --type=service

Domyślnie polecenie wypisuje każdą jednostkę usługi, którą systemd ma aktualnie w pamięci: usługi aktywne, mające zakolejkowane zadania lub takie, które zakończyły się błędem. Nie pokazuje usług zainstalowanych, ale nigdy nieuruchomionych. Gdy wynik jest dłuższy niż okno terminala, systemctl przekazuje go do przeglądarki tekstu (less) — naciśnij q, aby wyjść, albo dodaj --no-pager, aby pisać bezpośrednio na stdout.

Każdy wiersz ma pięć kolumn:

• UNIT — nazwa jednostki, na przykład ssh.service. To dokładnie ta nazwa, którą przekazujesz do systemctl status, start i stop.
• LOAD — czy plik jednostki został poprawnie przetworzony: loaded, not-found, bad-setting, error lub masked.
• ACTIVE — stan ogólny: active, inactive, activating, deactivating lub failed.
• SUB — stan szczegółowy, właściwy dla danego typu jednostki: usługa może być running, exited, dead i tak dalej.
• DESCRIPTION — czytelny dla człowieka opis z pliku jednostki.

Parę ACTIVE/SUB czytaj razem: active (running) oznacza, że proces działa w tej chwili, natomiast active (exited) oznacza, że usługa typu oneshot wykonała się poprawnie i zakończyła — to normalne dla zadań konfiguracyjnych, nie problem do naprawy.

Filtrowanie: działające, nieudane albo wszystkie

Flaga --state= filtruje po dowolnej wartości LOAD, ACTIVE lub SUB i przyjmuje listy rozdzielone przecinkami:

# Only services with a live process
systemctl list-units --type=service --state=running

# Everything loaded, including stopped and dead services
systemctl list-units --type=service --all

# Only failures
systemctl list-units --type=service --state=failed

# Combine states
systemctl list-units --type=service --state=running,exited

systemctl --failed to wbudowany skrót filtru nieudanych jednostek i warto uruchamiać go odruchowo na każdej maszynie, na którą się logujesz. Dla wyników czytelnych maszynowo --no-legend usuwa nagłówek i wiersze podsumowania, a --plain usuwa znaki wypunktowania, więc kolumny pozostają stabilne dla awk czy cut. Aby szukać po nazwie, przekaż wynik do grep: systemctl list-units --type=service --all --no-pager | grep ssh.

Co startuje przy uruchomieniu: systemctl list-unit-files

list-units odpowiada na pytanie „co działa teraz?”. Aby odpowiedzieć na „co uruchomi się przy starcie?”, wypisz zamiast tego pliki jednostek zainstalowane na dysku:

systemctl list-unit-files --type=service
systemctl list-unit-files --type=service --state=enabled

Tutaj kolumna STATE opisuje konfigurację startu, a nie stan działania:

• enabled — uruchamia się automatycznie przy starcie (lub po wyzwoleniu, w przypadku usług aktywowanych gniazdem albo timerem).
• disabled — zainstalowana, ale nic nie uruchamia jej automatycznie.
• static — nie ma sekcji [Install]; działa tylko jako zależność innej jednostki i nie można jej włączyć bezpośrednio.
• masked — dowiązana symbolicznie do /dev/null; systemd w ogóle odmawia jej uruchomienia.
• generated — utworzona w czasie działania przez generator, zwykle na podstawie starego skryptu init.

Nowsze wydania systemd wypisują też kolumnę presetu (VENDOR PRESET lub PRESET, zależnie od wersji), pokazującą domyślne ustawienie dystrybucji. Pułapka, której trzeba unikać: enabled nie znaczy działa, a disabled nie znaczy zatrzymana. Usługa może być wyłączona, a jednak działać, bo ktoś uruchomił ją ręcznie, albo włączona, a jednak martwa, bo się wysypała. Gdy to ma znaczenie, sprawdź obie listy.

Jedna usługa naraz: status, is-active, is-enabled

Gdy jakaś usługa przyciągnie twoją uwagę, przyjrzyj się jej bliżej:

systemctl status nginx
systemctl is-active nginx    # prints: active | inactive | failed
systemctl is-enabled nginx   # prints: enabled | disabled | static | masked
systemctl is-failed nginx

status pokazuje pełny obraz: stan ACTIVE/SUB, główny PID, czas działania, zużycie pamięci, drzewo procesów cgroup oraz dziesięć ostatnich wierszy dziennika. Gdy dziesięć wierszy nie wystarcza, zajrzyj wprost do dziennika: journalctl -xeu nginx (-u filtruje po jednostce, -e przeskakuje na koniec, -x dodaje objaśnienia).

Polecenia is-* są stworzone do skryptów: wypisują jedno słowo i ustawiają odpowiedni kod wyjścia — is-active zwraca 0 tylko wtedy, gdy jednostka jest aktywna, a is-enabled zwraca wartość różną od zera dla jednostek wyłączonych lub zamaskowanych. Dodaj --quiet, aby wyciszyć wynik i zostawić tylko kod wyjścia.

Wszystkie powyższe polecenia listujące działają na koncie bez uprawnień administratora. Samo zarządzanie usługami — start, stop, enable, disable — wymaga roota, więc warto zrozumieć, jak działa sudo i przełączanie użytkowników w Ubuntu, przed wyjściem poza samo odczytywanie stanu. Pamiętaj też, że jednostki użytkownika żyją w osobnym menedżerze: systemctl --user list-units --type=service wypisuje usługi działające w twojej własnej sesji, dlatego niektóre usługi wydają się „brakować” na liście systemowej.

Ściągawka: listy, których naprawdę użyjesz

Scenariusze z praktyki

1. Znajdź usługę, która wciąż się wysypuje

systemctl --failed
systemctl status myapp.service --no-pager -l
journalctl -xeu myapp.service
systemctl reset-failed myapp.service

Zacznij szeroko od --failed, potem przeczytaj wynik status, aby poznać kod wyjścia i ostatnie wiersze logu, a następnie zajrzyj do dziennika po pełny ślad. Gdy przyczyna zostanie usunięta i usługa znów działa, reset-failed czyści nieaktualny wpis o błędzie, więc kolejny test kondycji startuje z czystą kartą.

2. Sprawdź, co uruchomi się przy następnym starcie

systemctl list-unit-files --type=service --state=enabled --no-legend | awk '{print $1}'
systemd-analyze blame

Pierwsze polecenie daje czystą listę wszystkiego, co uruchomi się automatycznie — przydatne przed hartowaniem serwera albo przy szukaniu czegoś, co zainstalowałeś wiele miesięcy temu i zapomniałeś. systemd-analyze blame pokazuje następnie, ile czasu zajęła każda jednostka podczas ostatniego startu, dzięki czemu wolno startujące usługi od razu się wyróżniają.

3. Jednolinijkowce do skryptów i monitoringu

systemctl is-active --quiet nginx && echo up || echo down
systemctl list-units --type=service --state=running --no-legend --plain | awk '{print $1}'
systemctl show -p ActiveState,SubState nginx
systemctl list-units --type=service -o json   # systemd 246 or newer

show -p wypisuje pary Key=Value, których format nigdy nie zmienia się między wersjami, a wynik w JSON trafia prosto do jq. Jeśli łapiesz się na powtarzaniu tych samych kontroli przy każdym logowaniu, zamknij je w małym skrypcie — nasz przewodnik po plikach .sh i skryptach powłoki opisuje, jak zamienić dokładnie taki fragment w narzędzie do wielokrotnego użytku.

Brak systemd? service --status-all i OpenRC

Zamiast zakładać, że systemctl istnieje, sprawdź, co maszyna faktycznie uruchamia — sprawdzenie systemu i jego wersji z wiersza poleceń zajmuje dziesięć sekund i mówi, czy w ogóle masz dystrybucję z systemd. Jeśli systemctl nie istnieje, jesteś na SysV init albo OpenRC:

service --status-all

W Debianie i Ubuntu polecenie przechodzi /etc/init.d i wypisuje [ + ] dla działających, [ - ] dla zatrzymanych i [ ? ] dla skryptów bez polecenia status. Działa nadal w dystrybucjach z systemd przez warstwę zgodności, ale widzi tylko skrypty init, więc tam lepiej używać systemctl. W Alpine i Gentoo systemem init jest OpenRC: rc-status wypisuje usługi w bieżącym runlevelu, a rc-update show pokazuje, co uruchamia każdy runlevel.

Wszystko powyżej zakłada, że masz maszynę z Linuksem, na której dysponujesz rootem i możesz swobodnie uruchamiać, psuć i naprawiać usługi. Jeśli potrzebujesz takiej do ćwiczeń — albo czystego serwera do prawdziwych zadań — Linux VPS z pełnym dostępem root od rdp.monster ma dedykowane CPU i RAM, nielimitowane pasmo (fair-use), brak KYC i jest dostarczany około 10 sekund po potwierdzeniu płatności, więc możesz uruchomić systemctl list-units na własnym serwerze w niespełna minutę.

Najczęściej zadawane pytania

Dlaczego usługa pokazuje active (exited) zamiast active (running)?

To usługa typu oneshot, która wykonała się poprawnie i zakończyła — nie jest to błąd.

Usługi z Type=oneshot (albo RemainAfterExit=yes) wykonują zadanie raz — montowanie, konfigurację zapory, porządki — i kończą pracę. systemd raportuje wtedy active (exited): jednostka zakończyła się sukcesem i jest uznawana za „włączoną”, ale żaden proces nie pozostaje w tle. Tylko demony takie jak nginx czy sshd pokazują active (running). Jeśli usługa, po której oczekujesz demona, pokazuje exited, sprawdź jej plik jednostki poleceniem systemctl cat nazwa.service, aby zobaczyć, jak została zadeklarowana.

Co oznaczają kolorowe kropki w wyniku systemctl?

Zielony oznacza aktywną, biały nieaktywną, a czerwony nieudaną lub w stanie błędu.

Znak wypunktowania przed nazwą jednostki w systemctl status i systemctl list-units to szybki wskaźnik stanu: zielony dla aktywnej, biały dla nieaktywnej lub wyłączanej i czerwony dla stanów failed lub error. Wiersze z błędem są też podświetlone na czerwono na listach, dzięki czemu systemctl --failed łatwo przejrzeć. W skryptach lub logach, gdzie kody kolorów przeszkadzają, dodaj --plain albo przekaż wynik potokiem, a ozdobniki znikną.

Czy istnieje odpowiednik chkconfig --list w systemctl?

Tak — systemctl list-unit-files --type=service zastępuje chkconfig --list.

W RHEL i CentOS 7 lub nowszych chkconfig --list zostało zastąpione przez systemctl list-unit-files --type=service, które pokazuje każdą zainstalowaną usługę oraz to, czy jest enabled, disabled, static czy masked. Dla jednej usługi systemctl is-enabled name zastępuje chkconfig name, a systemctl enable name zastępuje chkconfig name on. Stare polecenie może nadal istnieć jako warstwa zgodności, ale obejmuje wyłącznie starsze skrypty SysV.

Jak zapobiec uruchamianiu usługi przy starcie systemu?

Użyj systemctl disable, aby usunąć ją ze startu, albo mask, aby zablokować ją całkowicie.

Uruchom sudo systemctl disable name, aby usunąć dowiązanie startowe; dodaj --now, aby jednocześnie ją zatrzymać. Wyłączoną usługę można wciąż uruchomić ręcznie lub pociągnąć jako zależność innej jednostki. Jeśli chcesz, aby nie startowała nigdy, użyj sudo systemctl mask name, co dowiązuje jednostkę do /dev/null, więc każda próba uruchomienia kończy się niepowodzeniem. Później odwrócisz to poleceniem systemctl unmask. Wynik sprawdź przez systemctl is-enabled name.