Generator systemd service

Generator jednostki systemd

Systemd zarządza usługami w nowoczesnych dystrybucjach Linuksa. Dzięki jednostce .service Twoja aplikacja uruchomi się automatycznie i wznowi po awarii.

Sekcje pliku

Polityka restartu

• always — zawsze po zakończeniu.
• on-failure — tylko przy błędzie.
• no — bez automatycznego restartu.

Przykład wdrożenia

sudo cp myapp.service /etc/systemd/system/
sudo systemctl daemon-reload
sudo systemctl enable --now myapp
journalctl -u myapp -f

Jak działa generator jednostki systemd

Generator zamienia wartości, które podajesz w formularzu — nazwę usługi, polecenie uruchomieniowe, użytkownika, politykę restartu, opóźnienie RestartSec, typ jednostki oraz moment startu — na gotowy plik jednostki w formacie INI, który systemd odczyta po skopiowaniu do katalogu systemowego. Narzędzie nie łączy się z Twoim systemem ani nie sprawdza, czy podane ścieżki istnieją; pełni rolę składniowego szablonu, który eliminuje literówki w nazwach sekcji i dyrektyw.

Mechanizm opiera się na trzech blokach. Sekcja [Unit] zawiera opis i zależności, sekcja [Service] definiuje sposób uruchomienia procesu, a sekcja [Install] mówi, kiedy usługa ma być włączana. Generator wypełnia je na podstawie pól formularza i pilnuje, aby dyrektywy takie jak Type, User, Restart czy RestartSec trafiły do właściwej sekcji — systemd zignoruje bowiem dyrektywę wpisaną w złym miejscu.

Logika warunkowa dotyczy przede wszystkim typu. Przy Type=simple systemd uznaje, że proces główny działa na pierwszym planie i nie kończy się od razu. Przy Type=forking oczekuje, że proces rodzicielski zakończy pracę, a usługa pozostanie w tle. Od tego wyboru zależy, czy systemd poprawnie rozpozna stan aktywności i czy polityka restartu zadziała w oczekiwanym momencie.

Przykład krok po kroku

1. W polu nazwy usługi wpisujesz myapp. Generator tworzy z tego nazwę pliku myapp.service oraz nazwę jednostki używaną w poleceniach systemctl.
2. Jako polecenie uruchomieniowe podajesz /usr/bin/myapp --config /etc/myapp.conf, a jako użytkownika www-data. Dzięki temu proces nie działa z uprawnieniami roota.
3. Wybierasz Type=simple, ponieważ aplikacja działa na pierwszym planie i nie odłącza się sama od terminala.
4. Ustawiasz Restart=on-failure oraz RestartSec=5. Usługa wznowi działanie po błędnym zakończeniu, ale dopiero po 5 sekundach przerwy, co chroni przed pętlą natychmiastowych restartów.
5. W sekcji [Install] wybierasz WantedBy=multi-user.target. To wystarczy, aby usługa startowała przy normalnym uruchomieniu systemu.
6. Otrzymany plik kopiujesz do /etc/systemd/system/myapp.service, następnie wykonujesz systemctl daemon-reload i systemctl enable --now myapp. Sprawdzenie stanu: systemctl status myapp.

Dyrektywy i ich znaczenie

Praktyczne wskazówki

• Zawsze podawaj pełną ścieżkę w ExecStart — systemd nie korzysta z PATH powłoki, więc samo myapp zwykle zakończy się błędem.
• Dobierz typ do zachowania procesu: dla aplikacji na pierwszym planie wybierz simple, dla klasycznych daemonów odłączających się od terminala — forking.
• Nie ustawiaj zbyt krótkiego RestartSec przy Restart=always. Zbyt szybkie restarty obciążają CPU i mogą zamaskować rzeczywistą przyczynę awarii.
• Testuj jednostkę przed włączeniem poleceniem systemctl start, a dopiero potem używaj enable, aby usługa nie startowała automatycznie z błędną konfiguracją.
• Pamiętaj o daemon-reload po każdej zmianie pliku .service — bez tego systemd nadal używa starej definicji.

Ograniczenia narzędzia

• Nie sprawdza ścieżek ani uprawnień — generator nie wie, czy plik podany w ExecStart istnieje i czy użytkownik ma prawo go uruchomić.
• Nie waliduje składni względem wersji systemd — niektóre dyrektywy są dostępne dopiero w nowszych wersjach, a narzędzie tego nie rozróżnia.
• Nie uwzględnia zależności pośrednich — wpisanie After=network.target nie gwarantuje, że sieć jest w pełni gotowa; to wymaga dodatkowej analizy jednostek.
• Nie generuje sekcji opcjonalnych takich jak [Socket], [Timer] czy dyrektyw środowiskowych EnvironmentFile; dla nich trzeba przygotować plik ręcznie.

Kiedy generator jednostki systemd realnie się przydaje

• Wdrożenie aplikacji z własnym środowiskiem — gdy program działa w virtualenv, z katalogu node_modules albo z lokalnie zbudowanego binarium, sprawdź ścieżkę do interpretera w ExecStart, katalog roboczy oraz zmienne środowiskowe. Te ostatnie wpisujesz jako osobne dyrektywy Environment, a nie doklejasz do polecenia.
• Migracja ze skryptu startowego — zastępujesz wpis w rc.local, skrypt z katalogu init.d albo zadanie z crona uruchamiane po restarcie. Sprawdź, czy polecenie nie korzysta z potoków, przekierowań i zmiennych powłoki, bo systemd nie uruchamia powłoki.
• Zadanie jednorazowe przy starcie — montowanie zasobu sieciowego, przygotowanie katalogów, migracja bazy. Wybierz Type=oneshot, a gdy usługa ma pozostać uznana za aktywną po zakończeniu pracy, włącz RemainAfterExit. Kolejność ustal przez After i Requires.
• Usługa zależna od sieci — serwer API, worker kolejki, aplikacja pobierająca dane z zewnątrz. Sprawdź, czy wystarczy network.target, czy potrzebne jest network-online.target razem z Wants, ponieważ samo After nie wymusza czekania na gotowość sieci.
• Audyt cudzej konfiguracji — przepisujesz istniejącą jednostkę z serwera do formularza, żeby zobaczyć, w których sekcjach powinny znaleźć się poszczególne dyrektywy, i porównać wynik z plikiem, który faktycznie działa.

Najczęstsze błędy przy generowaniu jednostki

Najczęstszy błąd to traktowanie ExecStart jak wiersza poleceń powłoki. Systemd dzieli tę wartość na argumenty samodzielnie, więc potoki, łączenie poleceń i przekierowania nie zadziałają, a ścieżka ze spacją rozsypie się na kilka argumentów. Jeśli naprawdę potrzebujesz logiki powłoki, wywołaj jawnie interpreter i przekaż całe polecenie jako jeden argument, pamiętając, że utrudnia to systemd śledzenie procesu głównego. Podobnie jest z katalogiem roboczym i zmiennymi — bez WorkingDirectory oraz Environment program może startować z innego miejsca, niż zakładasz, i nie znaleźć plików konfiguracyjnych.

Drugi typ błędów dotyczy nazewnictwa i wdrożenia. Nazwa pliku musi odpowiadać nazwie jednostki, inaczej systemctl jej nie znajdzie, a po każdej zmianie pliku trzeba wykonać daemon-reload. Nie edytuj jednostek w katalogu pakietowym, bo aktualizacja je nadpisze — trzymaj własny plik w katalogu systemowym albo użyj drop-in. Pamiętaj też, że enable nie sprawdza poprawności konfiguracji, więc najpierw uruchom usługę ręcznie i obejrzyj status oraz dziennik. W kontenerze lub środowisku bez działającego systemd żadna jednostka nie wystartuje, choćby była bezbłędna.

Najczęstsze pytania