Generator jednostki systemd

Zbuduj plik .service z sekcjami [Unit], [Service] i [Install], ustaw ExecStart, Type, użytkownika oraz politykę restartu.

Bezpieczne (SSL)

Przetwarzanie Lokalne

100% Darmowe

Przejdź do narzędzia

Instrukcja

1

Wprowadź dane
Wpisz treść, wklej tekst lub załaduj plik z dysku.
2

Kliknij przycisk
Narzędzie natychmiast przetworzy Twoje dane w przeglądarce.
3

Pobierz wynik
Skopiuj gotowy tekst lub zapisz plik na urządzeniu.

                                                function runTool() {

                                                  return "Wynik gotowy w 0.1s";

                                                }

Usługa systemd

Nazwa usługi

Opis

ExecStart

Użytkownik

WorkingDirectory

Type

Restart

EnvironmentFile

Dodaj podstawowy hardening (NoNewPrivileges, ProtectSystem)

Uzupełnij dane i kliknij „Generuj unit”.

Oceń to narzędzie:

Powiązane narzędzia

Inne narzędzia, które mogą Ci się przydać

Generator jednostki systemd — plik .service dla usługi w Linuksie

Generator jednostki systemd składa gotowy plik .service z trzech sekcji: [Unit], [Service] i [Install]. Podaj nazwę usługi, polecenie ExecStart, użytkownika i katalog roboczy, wybierz Type oraz politykę restartu, a narzędzie zwróci treść do zapisania w /etc/systemd/system/. Zamiast screen czy nohup oddajesz aplikację pod nadzór systemd: wstaje po restarcie serwera i sama wraca do życia po awarii.

Co dokładnie generuje to narzędzie

Nazwa usługi jest sprawdzana wzorcem [A-Za-z0-9_.@-] o długości 1–64 znaków, bo trafia w ścieżkę /etc/systemd/system/<nazwa>.service. Pole ExecStart jest obowiązkowe: bez polecenia sekcja [Service] nie ma czego uruchomić, więc narzędzie zgłasza błąd zamiast zwracać pustą jednostkę. Pola User, WorkingDirectory i EnvironmentFile pojawiają się tylko po wypełnieniu.

W [Service] ląduje wybrany Type, opcjonalne pola środowiska, obowiązkowy ExecStart, Restart i — poza wariantem Restart=no — RestartSec=5. Sekcja [Install] zawiera WantedBy=multi-user.target, więc systemctl enable podepnie usługę do normalnego rozruchu.

Anatomia pliku .service

Sekcja / pole	Zapis	Rola
`[Unit]`	`Description=`, `After=network.target`	Opis usługi i kolejność startu względem innych jednostek
`Type`	`Type=simple`	Model procesu: `simple`, `forking` lub `oneshot`
`ExecStart`	`ExecStart=/usr/bin/app`	Polecenie startowe — pełna ścieżka, bo systemd nie zna PATH
`Restart`	`Restart=always`	Kiedy wznowić proces: zawsze, po błędzie albo nigdy
`User` / `WorkingDirectory`	`User=www-data`	Konto i katalog, w którym usługa działa
`[Install]`	`WantedBy=multi-user.target`	Cel, do którego podpina się `enable` — autostart po rozruchu

Type, Restart i pełne ścieżki — na co uważać

Type=simple to domyślny model: proces musi zostać na pierwszym planie. Aplikacja, która sama się demonizuje, wymaga Type=forking, a jednorazowe zadanie — Type=oneshot z ewentualnym RemainAfterExit=yes. W ExecStart podajesz pełną ścieżkę do binarki: systemd nie dziedziczy PATH z powłoki, więc samo php artisan … zwykle kończy się błędem No such file or directory.

Nie uruchamiaj usług jako root, jeśli nie musisz — ustaw User= na konto o minimalnych uprawnieniach, a sekrety trzymaj w EnvironmentFile z prawami 600. Opcja hardeningu dokłada NoNewPrivileges=true, ProtectSystem=full, ProtectHome=true i PrivateTmp=true; jeśli usługa zapisuje w /usr, wyłącz ProtectSystem.

Wdrożenie krok po kroku

Uzupełnij nazwę, opis i polecenie ExecStart, wybierz Type oraz politykę restartu i wygeneruj plik.
Zapisz zawartość jako /etc/systemd/system/nazwa.service (nazwa bez spacji).
Przeładuj konfigurację: sudo systemctl daemon-reload.
Włącz autostart i uruchom usługę: sudo systemctl enable --now nazwa.
Sprawdź stan przez systemctl status nazwa, a logi na żywo przez journalctl -u nazwa -f.

Jednostka systemd domyka warsztat serwerowy: obraz aplikacji ułożysz w generatorze pliku Dockerfile, powtarzalne komendy w generatorze pliku Makefile, a zadania cykliczne w generatorze crontab. Cały stos usług opiszesz w generatorze docker-compose, a reguły serwera WWW w generatorze pliku .htaccess.

Czego to narzędzie nie robi

Generator tworzy jedną usługę: długo działający proces lub zadanie jednorazowe. Nie buduje jednostek szablonowych ([email protected]), timerów, socketów ani zależności Requires/Wants — te dopisujesz ręcznie w gotowym szkielecie. Nie sprawdza też, czy binarka z ExecStart istnieje na serwerze.

Najczęściej zadawane pytania

Dlaczego usługa nie startuje?

Najczęstsze przyczyny to zła ścieżka w ExecStart (systemd nie zna PATH z powłoki), brak uprawnień konta z User= albo nieodczytany EnvironmentFile. Diagnozę zacznij od journalctl -u nazwa -e i systemctl status nazwa — pokażą kod wyjścia i ostatnie linie logu.

Czym różni się enable od start?

systemctl start uruchamia usługę teraz, ale tylko do najbliższego restartu serwera. systemctl enable tworzy dowiązanie w celu z WantedBy (tutaj multi-user.target), więc usługa wstaje automatycznie po rozruchu. Skrót enable --now robi jedno i drugie naraz.

Jaki Type wybrać dla mojej aplikacji?

simple pasuje do procesów, które zostają na pierwszym planie (workery, serwery). forking wybierz, gdy program sam się demonizuje i zwalnia terminal. oneshot nadaje się do zadań, które wykonują pracę i kończą działanie — często z RemainAfterExit=yes, żeby systemd traktował je jako aktywne po zakończeniu.

Jak działa Restart i RestartSec?

Restart=always wznawia proces po każdym zakończeniu, on-failure tylko po niezerowym kodzie wyjścia, a no wyłącza wznawianie. RestartSec=5 to pauza przed ponownym startem — chroni przed pętlą restartów. Przy Restart=no narzędzie nie dopisuje RestartSec.

Czy mogę uruchomić kilka kopii tej samej usługi?

Tak, przez jednostkę szablonową: zapisz plik jako [email protected] i uruchamiaj instancje systemctl start worker@1, worker@2. W ExecStart odwołasz się do numeru przez %i. Ten generator tworzy jedną, nazwaną usługę — szablon dostosowujesz ręcznie na jej podstawie.