Zarządzanie usługami za pomocą systemd

Moduł 6: Usługi i logi · Czas czytania: 10 min

Cel lekcji: Po tej lekcji będą Państwo potrafili uruchamiać, zatrzymywać i przeładowywać usługi oraz ustawiać ich uruchamianie przy starcie systemu, odczytywać status usługi, a także bezpiecznie zmieniać ustawienie usługi za pomocą pliku drop-in.

Kluczowe pojęcia: systemd, unit, service, systemctl, start, stop, restart, reload, enable, disable, --now, active, inactive, failed, systemctl --failed, drop-in, systemctl edit, daemon-reload, Restart=

Kto dba o to, żeby wszystko działało?

Na serwerze działają dziesiątki programów, które muszą być dostępne przez cały czas: serwer SSH, serwer WWW, baza danych, synchronizacja czasu. Takie programy nazywamy usługami (services lub daemons). Ktoś musi je uruchomić przy starcie systemu, pilnować ich i uruchomić ponownie, gdy przestaną działać. W systemach Debian, Ubuntu, AlmaLinux i Rocky Linux robi to systemd. Jest to pierwszy program uruchamiany przez jądro (proces 1), który następnie uruchamia wszystko inne.

systemd pracuje z jednostkami (units): opisami czegoś, czym ma zarządzać. Najważniejsze rodzaje:

Z systemd komunikują się Państwo za pomocą polecenia systemctl. Rozszerzenie .service można pominąć: systemctl status nginx oznacza to samo co systemctl status nginx.service.

Odczytywanie statusu

Polecenie, którego będą Państwo używać najczęściej:

anna@web1:~$ systemctl status nginx
● nginx.service - A high performance web server and a reverse proxy server
     Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; preset: enabled)
     Active: active (running) since Mon 2026-11-09 08:12:44 CET; 3h 2min ago
       Docs: man:nginx(8)
    Process: 902 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, status=0/SUCCESS)
   Main PID: 905 (nginx)
      Tasks: 3 (limit: 2275)
     Memory: 4.1M (peak: 6.3M)
        CPU: 213ms
     CGroup: /system.slice/nginx.service
             ├─905 "nginx: master process /usr/sbin/nginx -g daemon on; master_process on;"
             └─906 "nginx: worker process"

nov 09 08:12:44 web1 systemd[1]: Starting nginx.service - A high performance web server...
nov 09 08:12:44 web1 systemd[1]: Started nginx.service - A high performance web server...

Proszę czytać od góry do dołu:

• Kropka przed nazwą jest zielona przy działającej usłudze, biała przy zatrzymanej i czerwona przy usłudze, która uległa awarii.
• Loaded informuje, gdzie znajduje się plik jednostki i czy usługa uruchamia się przy starcie systemu (enabled), czy nie (disabled).
• Active informuje, czy usługa teraz działa (active (running)), jest zatrzymana (inactive (dead)) lub uległa awarii (failed), oraz od kiedy.
• Main PID i CGroup pokazują, które procesy należą do usługi.
• Na dole widać ostatnie wiersze z logu usługi. Często już tam widać, dlaczego coś nie działa; więcej można odczytać za pomocą journalctl (lekcja 6.2).

Uruchamianie, zatrzymywanie, restart i przeładowanie

anna@web1:~$ sudo systemctl start nginx      # uruchom teraz
anna@web1:~$ sudo systemctl stop nginx       # zatrzymaj teraz
anna@web1:~$ sudo systemctl restart nginx    # zatrzymaj i uruchom ponownie
anna@web1:~$ sudo systemctl reload nginx     # wczytaj konfigurację ponownie bez zatrzymywania

Różnica między restart a reload ma w praktyce duże znaczenie. Przy restarcie usługa na chwilę się zatrzymuje: trwające połączenia zostają przerwane, a jeśli nowa konfiguracja zawiera błąd, usługa już się nie uruchomi i Państwa strona przestanie działać. Przy przeładowaniu (reload) usługa ponownie wczytuje swoją konfigurację, nie przestając działać; w razie błędu w konfiguracji nginx zachowuje poprzednią. Dlatego po zmianie konfiguracji nginx, Caddy, SSH i fail2ban prosimy używać reload, a konfigurację najpierw przetestować (nginx -t, sshd -t, fail2ban-client -t). Nie każda usługa obsługuje reload; systemctl reload-or-restart sam wybiera właściwą opcję.

Przy starcie systemu: enable i disable

Uruchomienie i „uruchamianie przy starcie systemu” to dwie różne rzeczy:

anna@web1:~$ sudo systemctl enable nginx         # od teraz uruchamiaj przy starcie systemu
anna@web1:~$ sudo systemctl disable nginx        # nie uruchamiaj już przy starcie systemu
anna@web1:~$ sudo systemctl enable --now nginx   # oba: uruchom teraz i przy starcie systemu
anna@web1:~$ systemctl is-enabled nginx
enabled

Klasyczny błąd: uruchamiają Państwo usługę poleceniem start, wszystko działa, a po następnym restarcie (na przykład po aktualizacji jądra, lekcja 4.2) usługi nie ma. Dlatego dla nowej usługi prosimy używać enable --now.

Jeśli chcą Państwo mieć pewność, że usługa nigdy się nie uruchomi, także wtedy, gdy wymaga jej inna usługa, służy do tego mask: sudo systemctl mask <dienst>. Cofnięcie tej zmiany: unmask.

Co jest nie tak?

Jedno polecenie pokazuje wszystkie jednostki, które uległy awarii:

anna@web1:~$ systemctl --failed
  UNIT                LOAD   ACTIVE SUB    DESCRIPTION
● php8.4-fpm.service  loaded failed failed The PHP 8.4 FastCGI Process Manager

1 loaded units listed.

Warto wyrobić sobie nawyk sprawdzania tego, na przykład po każdym restarcie i każdej aktualizacji (lekcja 4.3): lista powinna być pusta. Po usunięciu problemu komunikat można wyczyścić poleceniem sudo systemctl reset-failed.

Przegląd wszystkich działających usług:

anna@web1:~$ systemctl list-units --type=service --state=running

Jeśli działa coś, czego Państwo nie znają lub nie używają, prosimy sprawdzić, co to jest. Każda niepotrzebna usługa to zbędna powierzchnia ataku (lekcja 5.1 i 10.1).

Pliki jednostek i pliki drop-in

Plik jednostki to plik tekstowy. Wersja z pakietu znajduje się w /usr/lib/systemd/system/ (w starszych systemach /lib/systemd/system/). Tego pliku nigdy nie należy zmieniać: aktualizacja pakietu go nadpisze. Własne zmiany umieszcza się w pliku drop-in: małym pliku, który zawiera tylko te wiersze, które chcą Państwo zmienić. Najłatwiej zrobić to poleceniem:

anna@web1:~$ sudo systemctl edit nginx

Otworzy się edytor z pustym miejscem między dwoma wierszami komentarza. To, co Państwo tam wpiszą, trafi do /etc/systemd/system/nginx.service.d/override.conf. Przykład: automatyczne ponowne uruchomienie nginx, gdy nieoczekiwanie się zatrzyma.

[Service]
Restart=on-failure
RestartSec=5s

Po zapisaniu systemctl edit samodzielnie przeładowuje konfigurację systemd. Jeśli edytują Państwo plik jednostki w inny sposób, prosimy wykonać samodzielnie:

anna@web1:~$ sudo systemctl daemon-reload
anna@web1:~$ sudo systemctl restart nginx

daemon-reload sprawia, że systemd ponownie wczytuje pliki jednostek; sama usługa musi potem jeszcze zostać ponownie uruchomiona, aby zastosować zmianę. Pełny wynik (oryginał wraz z plikami drop-in) można zobaczyć za pomocą systemctl cat nginx.

Restart=on-failure to dobra praktyka dla ważnych usług. Nie należy jednak ukrywać w ten sposób prawdziwego błędu: przyczynę awarii usługi, która co pięć sekund się zawiesza i uruchamia ponownie, trzeba sprawdzić w logu. Po kilku szybkich awariach z rzędu systemd przestaje restartować usługę (domyślny limit to pięć uruchomień w ciągu dziesięciu sekund) i ustawia jej stan na failed.

W systemach AlmaLinux i Rocky Linux

systemd i systemctl działają dokładnie tak samo. Różnią się czasem tylko nazwy usług: usługa SSH nazywa się sshd, serwer WWW z dystrybucji to httpd (Apache) lub nginx, a zapora to firewalld.

W praktyce

Panel VPS Państwa dostawcy (w WebOké i gdzie indziej) pozwala wyłączyć cały serwer, zrestartować go lub „wymusić wyłączenie”. To ostatnie odpowiada wyciągnięciu wtyczki z gniazdka: usługi nie mają szansy na poprawne zatrzymanie się, a baza danych może zostać uszkodzona. Na samym serwerze prosimy używać sudo systemctl reboot lub sudo shutdown -h now, a w panelu zwykłego przycisku wyłączenia lub restartu.

Podsumowanie

• systemd uruchamia i nadzoruje wszystkie usługi; obsługuje się go za pomocą systemctl.
• systemctl status pokazuje, czy usługa działa, czy uruchamia się przy starcie systemu, oraz ostatnie wiersze logu.
• start/stop/restart dotyczą bieżącej chwili, enable/disable startu systemu; dla nowej usługi prosimy używać enable --now.
• Po zmianie konfiguracji: najpierw test, potem reload; systemctl --failed powinno zwracać pustą listę.
• Nigdy nie należy zmieniać pliku jednostki z pakietu; zamiast tego prosimy użyć pliku drop-in za pomocą systemctl edit.

Quiz

Zadanie

Zadanie O6.1: Przegląd Państwa usług. Prosimy sporządzić na swoim serwerze listę wszystkich działających usług (systemctl list-units --type=service --state=running) i sprawdzić, czy systemctl --failed zwraca pustą listę. Przy każdej usłudze prosimy zapisać, do czego służy i czy jest Państwu potrzebna. W przypadku jednej usługi, której Państwo nie znali, prosimy ustalić, czym jest (systemctl status, man). Następnie dla jednej ważnej usługi prosimy ustawić Restart=on-failure w pliku drop-in i sprawdzić za pomocą systemctl cat, że ustawienie jest widoczne.

Przeczytaj więcej

• Podręcznik systemctl(1): https://manpages.debian.org/trixie/systemd/systemctl.1.en.html
• Podręcznik systemd.service(5) (Restart=): https://manpages.debian.org/trixie/systemd/systemd.service.5.en.html
• Podręcznik systemd.unit(5) (pliki drop-in): https://manpages.debian.org/trixie/systemd/systemd.unit.5.en.html