systemd i systemctl w praktyce administratora Linux

Przez /

W większości współczesnych dystrybucji Linux to właśnie systemd odpowiada za uruchamianie usług, pilnowanie ich zależności i organizowanie startu systemu. Na co dzień administrator najczęściej spotyka się z nim przez polecenie systemctl. W praktyce warto jednak rozumieć nie tylko kilka komend typu start i restart, ale też to, skąd bierze się stan usługi, jak systemd interpretuje zależności oraz dlaczego usługa czasem nie wstaje mimo poprawnego pliku konfiguracyjnego.

Ten materiał jest nastawiony na codzienną administrację. Nie będziemy omawiać całej architektury systemd, tylko te elementy, które realnie przydają się podczas wdrożeń i awarii.

1. Najpierw stan usługi, dopiero potem restart

Pierwszym odruchem przy problemie z usługą nie powinno być ślepe restart. Najpierw warto zobaczyć, co systemd wie o danej jednostce.

systemctl status nginx
systemctl status sshd
systemctl status minio

Wynik pokazuje m.in. bieżący stan, PID procesu głównego, czas uruchomienia oraz kilka ostatnich wpisów z journala. W praktyce szczególnie interesują nas stany active, inactive, failed i activating.

Jeżeli usługa jest w stanie failed, sam restart może tylko na chwilę ukryć problem. Najpierw sprawdź powód zatrzymania i logi z momentu awarii.

2. Start, stop, restart i reload – nie są tym samym

sudo systemctl start nginx
sudo systemctl stop nginx
sudo systemctl restart nginx
sudo systemctl reload nginx

restart zatrzymuje usługę i uruchamia ją ponownie. reload prosi proces o przeładowanie konfiguracji bez pełnego restartu — ale tylko wtedy, gdy dana usługa to obsługuje. To ważne np. przy serwerach WWW, gdzie nie zawsze chcemy przerywać istniejące połączenia.

Jeżeli nie wiesz, czy reload jest obsługiwany, sprawdź definicję unity albo dokumentację konkretnej usługi.

3. Autostart po restarcie systemu

Działająca usługa nie musi automatycznie startować po ponownym uruchomieniu serwera. Za włączenie jej do odpowiedniego targetu odpowiada enable.

sudo systemctl enable nginx
sudo systemctl enable --now nginx
sudo systemctl disable nginx
systemctl is-enabled nginx

Opcja --now jest wygodna, bo jednocześnie włącza autostart i uruchamia usługę. Warto też pamiętać, że disable nie zatrzymuje działającego procesu — usuwa tylko powiązania odpowiedzialne za start przy bootowaniu.

4. Gdzie systemd trzyma definicję usługi

Najczęściej spotkasz pliki unit w /usr/lib/systemd/system/, /lib/systemd/system/ albo /etc/systemd/system/. Nie warto edytować pliku dostarczonego przez pakiet bezpośrednio, bo aktualizacja może go nadpisać.

Do zmian lokalnych używaj drop-inów:

sudo systemctl edit nginx

System utworzy plik w katalogu typu /etc/systemd/system/nginx.service.d/override.conf. Po zmianie definicji unity wykonaj:

sudo systemctl daemon-reload
sudo systemctl restart nginx

5. Minimalny własny unit

Własna aplikacja lub skrypt może być uruchamiany jako normalna usługa systemowa. Przykładowy plik /etc/systemd/system/myapp.service:

[Unit]
Description=My application
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=myapp
Group=myapp
WorkingDirectory=/opt/myapp
ExecStart=/opt/myapp/bin/start
Restart=on-failure
RestartSec=5s

[Install]
WantedBy=multi-user.target

Po zapisaniu pliku:

sudo systemctl daemon-reload
sudo systemctl enable --now myapp.service
systemctl status myapp.service

6. Restart policy – kiedy systemd ma próbować ponownie

Jednym z najbardziej praktycznych parametrów jest Restart=. Nie zawsze dobrym pomysłem jest użycie always. Jeżeli aplikacja kończy się przez błędną konfigurację, systemd może wejść w szybką pętlę restartów.

  • Restart=no – brak automatycznego restartu
  • Restart=on-failure – restart po błędzie, sygnale lub niezerowym kodzie wyjścia
  • Restart=always – restart również po poprawnym zakończeniu procesu
  • RestartSec=5s – opóźnienie między próbami

Dla większości usług aplikacyjnych on-failure jest rozsądniejszym punktem startowym niż always.

7. Zależności: After, Wants i Requires

Te trzy dyrektywy są często mylone. After= określa kolejność uruchamiania, ale nie powoduje automatycznie startu drugiej jednostki. Wants= tworzy słabszą zależność, a Requires= mocniejszą — jeżeli wymagana jednostka nie wystartuje, zależna usługa również może nie ruszyć.

Przy usługach sieciowych często spotyka się zestaw:

[Unit]
Wants=network-online.target
After=network-online.target

8. Mask i unmask – mocniejsze niż disable

Jeżeli usługa nie powinna być uruchamiana nawet ręcznie lub przez inną zależność, można ją zamaskować:

sudo systemctl mask myservice
sudo systemctl unmask myservice

mask jest znacznie mocniejsze niż disable. W sytuacji awaryjnej jest przydatne, ale łatwo o nim zapomnieć. Gdy systemd odpowiada komunikatem o masked unit, warto sprawdzić to zanim zacznie się szukać problemu w konfiguracji aplikacji.

9. Co sprawdzam, gdy usługa nie startuje

  • systemctl status nazwa – ogólny stan i ostatnie błędy
  • journalctl -u nazwa -b – logi jednostki z bieżącego uruchomienia
  • systemctl cat nazwa – finalna definicja unity razem z override
  • systemctl show nazwa – wszystkie właściwości widziane przez systemd
  • systemctl list-dependencies nazwa – zależności
  • systemd-analyze verify plik.service – kontrola składni własnego unity

Jeżeli problem dotyczy logów, dobrym uzupełnieniem tego materiału jest istniejący artykuł Systemy logowania i audytu w systemie Linux. Przy problemach z procesem warto też zajrzeć do Procesy i zarządzanie nimi w systemie Linux.

Podsumowanie

systemd jest znacznie bardziej przewidywalny, gdy traktuje się go jako menedżer stanu i zależności, a nie tylko miejsce do wpisania restart. W codziennej administracji najwięcej daje umiejętność czytania status, poprawnego używania enable, bezpiecznego tworzenia override oraz powiązania systemd z journalem. To wystarcza do rozwiązania dużej części typowych problemów z usługami.

Przewijanie do góry