Generator pliku usługi systemd

Utrzymaj program w Node.js, Pythonie lub Go na serwerze z Linuksem, uruchamiaj go przy starcie systemu i restartuj po awarii — bez pamiętania każdej opcji systemd. Wpisz polecenie i użytkownika, wybierz restart i zmienne środowiskowe, a potem skopiuj plik .service razem z komendami instalacji i startu. Zaznacz Uruchamiaj według harmonogramu, aby dostać .timer — nowoczesną alternatywę dla crona.

Działa w przeglądarce — nic, co wpiszesz, nie jest wysyłane

Nazwa usługi

Staje się nazwą pliku, np. myapp → myapp.service

Opis

Polecenie (ExecStart)

Użyj pełnej ścieżki do programu, np. /usr/bin/python3 app.py

Katalog roboczy

Uruchom jako użytkownik

Grupa

Type

Polecenie działa stale na pierwszym planie (większość aplikacji webowych i skryptów).

Restart

Czekaj przed restartem (s)

Zmienne środowiskowe

Jedna para KEY=value w wierszu; wartości ze spacjami zostaną ujęte w cudzysłów.

Plik środowiska

Maks. liczba otwartych plików (LimitNOFILE)

0 zostawia domyślną wartość systemu.

Uruchom po połączeniu z sieciąPodstawowe utwardzanie (bez nowych uprawnień, prywatny /tmp, system tylko do odczytu)Uruchamiaj według harmonogramu (utwórz .timer)

myapp.service

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

[Service]
Type=simple
User=www-data
WorkingDirectory=/srv/myapp
Environment=NODE_ENV=production
Environment=PORT=3000
ExecStart=/usr/bin/node /srv/myapp/server.js
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

Instalacja i start

sudo tee /etc/systemd/system/myapp.service > /dev/null << 'EOF'
[Unit]
Description=My application
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=www-data
WorkingDirectory=/srv/myapp
Environment=NODE_ENV=production
Environment=PORT=3000
ExecStart=/usr/bin/node /srv/myapp/server.js
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target
EOF
sudo systemctl daemon-reload
sudo systemctl enable --now myapp.service
systemctl status myapp.service
journalctl -u myapp.service -f

Wklej polecenia na serwerze jako root. Po edycji pliku jednostki uruchom ponownie systemctl daemon-reload. Logi: journalctl -u <nazwa>.

Jak używać

Wpisz nazwę usługi, polecenie z pełną ścieżką i katalog roboczy.
Ustaw użytkownika, restart i ewentualne zmienne środowiskowe.
Opcjonalnie dodaj podstawowe utwardzanie albo harmonogram (OnCalendar), aby utworzyć timer.
Skopiuj wygenerowane pliki albo wklej komendy instalacji do powłoki roota na serwerze.

Opis opcji

Type: simple pasuje do programów działających na pierwszym planie; oneshot pasuje do skryptów uruchamianych raz, np. zadań cyklicznych.
Restart: Po błędzie restartuje usługę, gdy zakończy się błędem lub się zawiesi; Zawsze restartuje ją także po normalnym zakończeniu.
OnCalendar: Kiedy timer się uruchamia, np. daily albo *-*-* 03:00:00 dla 3:00 każdego dnia. Wyrażenia sprawdzisz poleceniem systemd-analyze calendar.

Przykład: nocne zadanie jako timer

Aby uruchamiać skrypt co noc o 3:00, ustaw Polecenie (ExecStart) na /usr/local/bin/backup.sh, nazwę usługi na backup, Type na oneshot i Restart na Nigdy, a następnie zaznacz „Uruchamiaj według harmonogramu (utwórz .timer)” i „Podstawowe utwardzanie”. Przy domyślnym użytkowniku i katalogu roboczym generator tworzy dwa pliki. backup.service:

[Unit]
Description=Nightly backup

[Service]
Type=oneshot
User=www-data
WorkingDirectory=/srv/myapp
ExecStart=/usr/local/bin/backup.sh
NoNewPrivileges=true
PrivateTmp=true
ProtectSystem=full
ProtectHome=read-only

oraz backup.timer:

[Unit]
Description=Run backup on a schedule

[Timer]
OnCalendar=*-*-* 03:00:00
Persistent=true
Unit=backup.service

[Install]
WantedBy=timers.target

Gdy timer jest włączony, zmieniają się dwie rzeczy. Plik usługi traci sekcję [Install], ponieważ uruchamia ją timer, a polecenia instalacji włączają timer, a nie usługę:

sudo systemctl daemon-reload
sudo systemctl enable --now backup.timer
systemctl list-timers backup.timer
journalctl -u backup.service -f

Type nie jest zmieniany automatycznie po zaznaczeniu opcji timera, więc dla zadań, które się kończą, wybierz oneshot samodzielnie. Usługa oneshot połączona z Restart Zawsze jest niepoprawna, więc generator pomija Restart i pokazuje ostrzeżenie.

Najczęściej zadawane pytania

Gdzie umieścić plik?

W /etc/systemd/system/. Potem uruchom systemctl daemon-reload i systemctl enable --now <nazwa>.service — wygenerowane komendy robią to wszystko.

Dlaczego usługa kończy się błędem „Executable path is not absolute”?

Starsze wersje systemd wymagają pełnej ścieżki do programu w ExecStart. Znajdziesz ją poleceniem which, np. which node.

Timer czy cron?

Timery zapisują logi w dzienniku, potrafią nadrobić uruchomienia pominięte, gdy serwer był wyłączony, i nigdy nie działają dwa razy naraz. Cron jest prostszy dla jednolinijkowców i nadal działa świetnie.

Prywatność

To narzędzie działa w całości w przeglądarce. Twoje pliki i tekst są przetwarzane na Twoim urządzeniu i nigdy nie trafiają na nasze serwery.