Czym jest jednostka systemd i po co ten kreator?
Na nowoczesnym Linuksie (Ubuntu, Debian, Fedora, Arch, Rocky, Alma...) systemd to program, który startuje usługi przy bocie, restartuje je gdy padną i odpala zadania według harmonogramu. Plik jednostki (unit file) to mały plik tekstowy w `/etc/systemd/system/`, który mówi systemd *co* uruchomić i *jak* tym zarządzać.
Ten kreator pisze za Ciebie dwa rodzaje jednostek:
- `.service` ExecStart dla długo działających programów (aplikacja Node, worker Python, baza danych).
- `.timer` OnCalendar dla zadań, które mają działać według harmonogramu (nowoczesny zamiennik crona).
Wybierz preset, wypełnij pola, skopiuj wynik do pliku w `/etc/systemd/system/`, uruchom `sudo systemctl daemon-reload && sudo systemctl enable --now myapp.service` i gotowe. Wszystko dzieje się w Twojej przeglądarce, bez uploadu, bez konta.
Jak używać
- Wybierz preset, który przypomina Twój przypadek (Node web app, Python worker, oneshot backup, baza, Go binary, docker compose, serwer statyczny). Formularz wypełnia się sensownymi domyślami, które możesz dopieścić.
- Ustaw nazwę jednostki (`myapp` da `myapp.service`), Description (widoczne w `systemctl status`) i zależności (After, Wants, Requires, gdzie prawie każdy chce `network-online.target`).
- W sekcji Service wybierz Type (`simple` dla większości aplikacji, `oneshot` dla skryptów które kończą pracę, `forking` dla daemonów które forkują się w tło), User i Group żeby zrzucić uprawnienia, oraz ExecStart z bezwzględną ścieżką do binarki.
- Wybierz politykę Restart. `on-failure` to bezpieczny domyślny: systemd restartuje tylko jeśli program wyjdzie z kodem niezerowym albo padnie. `always` dla długo żyjących workerów, które mają wracać niezależnie od powodu. RestartSec to opóźnienie między próbami (5 sekund w sam raz).
- Dodaj zmienne Environment (NODE_ENV, DATABASE_URL...). Wrażliwe (hasła, tokeny) trafiają do `EnvironmentFile=` zamiast unitu: zapisz je w pliku z `chmod 600` poza unitem.
- Opcjonalne hardeningi: włącz `PrivateTmp`, `ProtectSystem`, `NoNewPrivileges`. Nic nie kosztują, a ograniczają skutki włamania. Kreator opisuje każdy z nich.
- Przełącz na zakładkę .timer jeśli chcesz harmonogram zamiast (albo oprócz) długo działającej usługi. Wpisz OnCalendar (np. `daily`, `Mon *-*-* 03:00:00`), włącz Persistent, żeby pominięty run wykonał się po starcie systemu, w Unit wskaż swoją usługę.
- Kliknij Copy albo Download. Wrzuć plik do `/etc/systemd/system/myapp.service` (i `myapp.timer` jeśli trzeba), potem `sudo systemctl daemon-reload`, `sudo systemctl enable --now myapp.service`, a logi oglądaj przez `journalctl -u myapp.service -f`.
Kiedy się przydaje
Siedem konkretnych sytuacji, w których porządny unit systemd oszczędza realny czas:
- Napisałeś program w Node, Pythonie albo Go i chcesz, żeby startował przy bocie i wracał po crashu. Wrzuć `.service` do `/etc/systemd/system/` i zapomnij o `pm2`, `forever`, `screen` czy `nohup`.
- Masz skrypt, który ma się odpalać według harmonogramu (nocny backup, tygodniowy raport, cogodzinne odświeżanie cache). Para `.timer` plus `.service` to nowoczesny zamiennik crona, a logi lecą prosto do journalctl.
- Musisz uruchomić program jako użytkownik inny niż root z kontrolowanymi uprawnieniami. `User=` i `Group=` zrzucają uprawnienia; `ProtectSystem=strict`, `PrivateTmp=yes` i `NoNewPrivileges=yes` dorzucają hardening za darmo.
- Zarządzasz małą flotą serwerów i chcesz mieć tę samą definicję usługi na każdej maszynie. Plik jednostki to tekst: wersjonuj go w gicie, deployuj ansiblem / Makefile-em / scp.
- Twoja usługa musi czekać na sieć albo bazę danych zanim wystartuje. `After=network-online.target` i `Requires=postgresql.service` ustawiają kolejność wprost.
- Stos docker compose ma startować przy bocie. Oneshot `.service` z `ExecStart=docker compose up -d` plus `Requires=docker.service` ogarnia to czysto.
- Chcesz centralne logi bez konfigurowania niczego. `StandardOutput=journal` (domyślne) sprawia, że `journalctl -u myapp` pokazuje wszystko, a `journalctl --since "1 hour ago"` to Twoja pojedyncza wyszukiwarka.