Systemctl – do czego służy? Najważniejsze polecenia z przykładami

systemctl to polecenie, którym sterujesz systemd — menedżerem systemu i usług używanym przez niemal wszystkie popularne dystrybucje Linuksa. Służy do uruchamiania, zatrzymywania i restartowania usług, ustawiania ich autostartu, sprawdzania stanu, a także do wyłączania lub restartu całego systemu. Jeśli administrujesz serwerem z Ubuntu, Debianem, Fedorą, RHEL czy Archem, będziesz go używać codziennie.

Poniżej znajdziesz wyjaśnienie, jak systemctl ma się do systemd, zestaw najważniejszych poleceń z przykładami, tworzenie własnej usługi i timera oraz rozwiązanie najczęstszych błędów.

systemd i systemctl — co jest czym

systemd to proces startowy (init), który jądro Linuksa uruchamia jako pierwszy, z identyfikatorem PID 1. Od niego zaczyna się cały system: systemd montuje dyski, konfiguruje sieć, uruchamia usługi i pilnuje, żeby działały. Zastąpił starsze rozwiązania — SysVinit ze skryptami w /etc/init.d oraz Upstart z dawnych wersji Ubuntu.

systemctl jest tylko narzędziem wiersza poleceń, które wysyła polecenia do działającego systemd. W tym samym ekosystemie są też inne narzędzia, m.in.:

• journalctl — przeglądanie logów zbieranych przez systemd-journald,
• systemd-analyze — analiza czasu uruchamiania i weryfikacja plików jednostek,
• hostnamectl, timedatectl, localectl — ustawienia nazwy hosta, czasu i języka.

systemd nie jest wszędzie. Alpine Linux używa OpenRC, Devuan i część instalacji Gentoo — innych systemów init. Tam systemctl nie zadziała. Jeśli dopiero wybierasz system, przyda się przegląd najpopularniejszych dystrybucji Linuksa.

Jednostki (units) — czym zarządza systemctl

systemd nie operuje tylko na usługach. Wszystko, czym zarządza, to jednostki (units), opisane w plikach tekstowych. Typ jednostki poznasz po rozszerzeniu:

Jeśli pominiesz rozszerzenie, systemctl przyjmie .service. Dlatego systemctl restart nginx i systemctl restart nginx.service robią to samo.

Najważniejsze polecenia systemctl do zarządzania usługami

Polecenia zmieniające stan systemu wymagają uprawnień roota, więc na zwykłym koncie poprzedzaj je sudo. Samo sprawdzanie stanu działa bez tego.

Uruchamianie, zatrzymywanie i restart

sudo systemctl start nginx
sudo systemctl stop nginx
sudo systemctl restart nginx
sudo systemctl reload nginx
sudo systemctl reload-or-restart nginx

restart zatrzymuje i ponownie uruchamia proces, więc na chwilę przerywa działanie usługi. reload każe usłudze tylko wczytać konfigurację od nowa — bez rozłączania klientów. Nie każda usługa to obsługuje, dlatego wygodne jest reload-or-restart, które przeładuje, jeśli się da, a w przeciwnym razie zrestartuje.

Autostart: enable, disable i mask

sudo systemctl enable nginx
sudo systemctl disable nginx
sudo systemctl enable --now nginx
sudo systemctl disable --now nginx

To najczęstsze źródło nieporozumień. enable nie uruchamia usługi — tylko tworzy dowiązania symboliczne, dzięki którym systemd wystartuje ją przy następnym uruchomieniu systemu. Z kolei start uruchamia usługę teraz, ale po restarcie jej nie będzie. Przełącznik --now łączy oba działania.

Jeśli usługa ma nie startować w żadnych okolicznościach — nawet jako zależność innej — użyj maskowania:

sudo systemctl mask cups
sudo systemctl unmask cups

Zamaskowana jednostka jest dowiązana do /dev/null i każda próba jej uruchomienia kończy się błędem.

Sprawdzanie stanu usługi

systemctl status sshd
systemctl is-active sshd
systemctl is-enabled sshd
systemctl is-failed sshd

status pokazuje najwięcej: czy plik jednostki jest załadowany i gdzie leży (Loaded:), czy usługa działa i od kiedy (Active: active (running)), numer głównego procesu, drzewo procesów w cgroup oraz ostatnie linie logów. Warto zwrócić uwagę na wartość po Loaded: — słowo enabled lub disabled mówi, czy usługa ma autostart.

Polecenia is-active, is-enabled i is-failed zwracają jedno słowo i odpowiedni kod wyjścia, więc nadają się do skryptów:

if ! systemctl is-active --quiet nginx; then
  sudo systemctl restart nginx
fi

Więcej o takich konstrukcjach przeczytasz w poradniku o instrukcjach warunkowych w Bashu.

Listowanie jednostek

systemctl list-units --type=service --state=running
systemctl list-units --failed
systemctl list-unit-files --type=service
systemctl list-dependencies multi-user.target
systemctl list-timers

list-units pokazuje jednostki załadowane do pamięci, a list-unit-files — wszystkie pliki jednostek zainstalowane w systemie wraz ze stanem (enabled, disabled, static, masked). Stan static oznacza jednostkę bez sekcji [Install], której nie da się włączyć samodzielnie — startuje tylko jako zależność innej.

Logi usług: journalctl

systemctl pokazuje w statusie tylko kilka ostatnich linii logu. Pełną historię znajdziesz w dzienniku systemd:

journalctl -u nginx
journalctl -u nginx -f
journalctl -u nginx -b
journalctl -u nginx --since "1 hour ago"
journalctl -p err -b

Kolejno: wszystkie logi usługi, podgląd na żywo (jak tail -f), logi od ostatniego uruchomienia systemu, logi z ostatniej godziny oraz wszystkie błędy od startu systemu. Gdy usługa nie chce wystartować, to właśnie tutaj najczęściej znajdziesz przyczynę — literówkę w konfiguracji, zajęty port albo brak uprawnień do pliku.

Gdzie leżą pliki jednostek i jak je bezpiecznie zmieniać

Pliki jednostek są w trzech głównych katalogach. Jeśli ta sama nazwa występuje w kilku, wygrywa ten o wyższym priorytecie:

Jednostki użytkownika (uruchamiane przez systemctl --user) mieszkają w ~/.config/systemd/user/ i /etc/systemd/user/.

Nigdy nie edytuj plików w /usr/lib/systemd/system/ — aktualizacja pakietu nadpisze Twoje zmiany. Zamiast tego użyj:

sudo systemctl edit nginx

Polecenie otworzy edytor i zapisze tylko Twoje zmiany jako nadpisanie w /etc/systemd/system/nginx.service.d/override.conf. Oryginał zostaje nietknięty. Jeśli wolisz skopiować i edytować całą jednostkę, użyj systemctl edit --full nginx. Bieżącą, scaloną konfigurację pokaże systemctl cat nginx.

Ważne: Po ręcznej zmianie lub dodaniu pliku jednostki uruchom sudo systemctl daemon-reload. Bez tego systemd dalej używa starej wersji, a przy statusie zobaczysz ostrzeżenie, że plik na dysku się zmienił. systemctl edit robi przeładowanie automatycznie.

Tworzenie własnej usługi krok po kroku

Załóżmy, że chcesz, żeby skrypt lub aplikacja (np. serwer w Pythonie) uruchamiała się przy starcie systemu i była automatycznie restartowana po awarii.

1. Utwórz plik /etc/systemd/system/moja-aplikacja.service:

[Unit]
Description=Moja aplikacja
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=aplikacja
WorkingDirectory=/opt/moja-aplikacja
ExecStart=/usr/bin/python3 /opt/moja-aplikacja/app.py
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

2. Przeładuj konfigurację systemd: sudo systemctl daemon-reload.
3. Uruchom usługę i włącz autostart: sudo systemctl enable --now moja-aplikacja.
4. Sprawdź wynik: systemctl status moja-aplikacja i w razie problemów journalctl -u moja-aplikacja -e.

Co oznaczają poszczególne sekcje:

• [Unit] — opis i zależności. After= ustala kolejność (uruchom po sieci), a Wants= sprawia, że systemd faktycznie spróbuje uruchomić wskazaną jednostkę.
• [Service] — jak uruchomić proces. Type=simple oznacza, że proces z ExecStart działa na pierwszym planie i nie „forkuje się” w tło. User= uruchamia go na koncie bez uprawnień roota — tak powinno być zawsze, gdy się da. Restart=on-failure restartuje usługę po nieoczekiwanym zakończeniu.
• [Install] — co ma się stać przy enable. WantedBy=multi-user.target podpina usługę pod standardowy tryb pracy serwera.

W ExecStart podawaj pełną ścieżkę do programu — systemd nie korzysta z PATH Twojej powłoki. Poprawność pliku sprawdzisz poleceniem systemd-analyze verify /etc/systemd/system/moja-aplikacja.service. Pełny opis dyrektyw znajdziesz w dokumentacji systemd.service.

Timer zamiast crona

systemd potrafi też uruchamiać zadania cyklicznie. Do usługi z przykładu wyżej (albo dowolnej innej jednostki .service z Type=oneshot) dodajesz plik .timer o tej samej nazwie, np. /etc/systemd/system/kopia.timer:

[Unit]
Description=Codzienna kopia zapasowa

[Timer]
OnCalendar=*-*-* 03:00:00
Persistent=true

[Install]
WantedBy=timers.target

Włączasz timer, a nie usługę: sudo systemctl enable --now kopia.timer. Opcja Persistent=true sprawi, że zadanie pominięte, bo komputer był wyłączony, wykona się zaraz po starcie. Przewagą nad cronem są logi w journalctl, zależności od innych usług i podgląd najbliższych uruchomień w systemctl list-timers. Różnice między zadaniami systemowymi a pseudo-cronem aplikacji opisuję w tekście WP-Cron vs Cron.

Zarządzanie systemem: restart, wyłączanie i targety

systemctl steruje też całym systemem:

sudo systemctl reboot
sudo systemctl poweroff
sudo systemctl suspend
systemctl get-default
sudo systemctl set-default multi-user.target
sudo systemctl isolate rescue.target

Targety zastąpiły dawne poziomy uruchomienia (runlevele):

set-default multi-user.target sprawi, że komputer z zainstalowanym środowiskiem graficznym będzie startował w trybie tekstowym — przydatne na serwerach. isolate przełącza tryb od razu, zatrzymując wszystko, czego nowy target nie potrzebuje.

Stare polecenia a systemctl

W starszych poradnikach zobaczysz polecenia z czasów SysVinit. Na systemach z systemd zwykle nadal działają dzięki warstwie zgodności, ale warto znać odpowiedniki:

Najczęstsze błędy i ich przyczyny

„System has not been booted with systemd as init system (PID 1). Can’t operate.” — systemd nie jest procesem startowym. Dzieje się tak w kontenerach Dockera (tam zwykle nie ma systemd i procesy uruchamia się bezpośrednio) oraz w WSL bez włączonego systemd. W WSL 2 włączysz go, dodając do /etc/wsl.conf sekcję:

[boot]
systemd=true

Następnie w Windowsie wykonaj wsl --shutdown i uruchom dystrybucję ponownie. W nowszych obrazach Ubuntu dla WSL ta opcja jest już domyślnie włączona.

„Unit nazwa.service not found” — literówka w nazwie, pakiet nie jest zainstalowany albo po dodaniu pliku nie wykonano daemon-reload. Sprawdź dokładną nazwę przez systemctl list-unit-files | grep fraza — np. serwer SSH w Debianie i Ubuntu to ssh.service, a w Fedorze i RHEL sshd.service.

„Job for nazwa.service failed because the control process exited with error code” — usługa się nie uruchomiła. Przyczynę pokaże journalctl -xeu nazwa.service. Po naprawie, jeśli systemd blokuje ponowne próby z powodu zbyt wielu restartów, wyczyść licznik: sudo systemctl reset-failed nazwa.

Usługa działa, ale po restarcie serwera jej nie ma — uruchomiłeś ją przez start, a nie włączyłeś przez enable.

Co dalej

Jeśli wolisz zarządzać usługami z poziomu przeglądarki, zobacz Cockpit — panel, który sam włączasz poleceniem sudo systemctl enable --now cockpit.socket i który pod spodem korzysta właśnie z systemd. Przy wielu serwerach zarządzanie usługami warto przenieść do automatyzacji, np. modułem systemd w Ansible. Pełną listę opcji znajdziesz w podręczniku systemctl lub lokalnie przez man systemctl.