systemd Service erstellen: .service- und .timer-Datei Generator

systemd-Service-Datei-Generator

Halten Sie ein Node.js-, Python- oder Go-Programm auf einem Linux-Server am Laufen, starten Sie es beim Booten und neu, wenn es abstürzt – ohne sich jede systemd-Option merken zu müssen. Tragen Sie Befehl und Benutzer ein, wählen Sie eine Neustart-Richtlinie und Umgebungsvariablen und kopieren Sie die .service-Datei samt den Befehlen zum Installieren und Starten. Aktivieren Sie Nach Zeitplan ausführen (.timer erstellen), um einen .timer als moderne Alternative zu cron zu erhalten.

Läuft in Ihrem Browser – Ihre Eingaben werden nicht hochgeladen

Dienstname

Wird zum Dateinamen, z. B. myapp → myapp.service

Beschreibung

Befehl (ExecStart)

Verwenden Sie den vollständigen Pfad zum Programm, z. B. /usr/bin/python3 app.py

Arbeitsverzeichnis

Ausführen als Benutzer

Gruppe

Type

Der Befehl läuft dauerhaft im Vordergrund (die meisten Web-Apps und Skripte).

Restart

Wartezeit vor Neustart (s)

Umgebungsvariablen

Eine SCHLÜSSEL=Wert-Zeile pro Variable; Werte mit Leerzeichen werden für Sie in Anführungszeichen gesetzt.

Umgebungsdatei

Max. offene Dateien (LimitNOFILE)

0 behält den Systemstandard bei.

Erst starten, wenn das Netzwerk online istGrundlegende Härtung (keine neuen Privilegien, privates /tmp, schreibgeschütztes System)Nach Zeitplan ausführen (.timer erstellen)

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

Installieren und starten

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

Fügen Sie die Befehle auf dem Server als root ein. Führen Sie nach dem Bearbeiten einer Unit-Datei erneut systemctl daemon-reload aus. Logs: journalctl -u <name>.

So funktioniert es

Geben Sie den Dienstnamen, den Befehl mit vollständigem Pfad und das Arbeitsverzeichnis ein.
Legen Sie Benutzer, Neustart-Richtlinie und eventuelle Umgebungsvariablen fest.
Fügen Sie optional eine grundlegende Härtung oder einen Zeitplan (OnCalendar) hinzu, um einen Timer zu erstellen.
Kopieren Sie die erzeugten Dateien oder fügen Sie die Installationsbefehle in eine Root-Shell auf dem Server ein.

Optionen erklärt

Type: simple passt für Programme, die im Vordergrund bleiben; oneshot passt für Skripte, die einmal laufen, etwa geplante Aufgaben.
Restart: Bei Fehler startet den Dienst neu, wenn er mit einem Fehler endet oder abstürzt; Immer startet ihn auch nach einem normalen Ende neu.
OnCalendar: Wann der Timer auslöst, z. B. daily oder *-*-* 03:00:00 für täglich 3 Uhr nachts. Testen Sie Ausdrücke mit systemd-analyze calendar.

Beispiel: ein nächtlicher Job als Timer

Um ein Skript jede Nacht um 3 Uhr auszuführen, setzen Sie „Befehl (ExecStart)“ auf /usr/local/bin/backup.sh, den Dienstnamen auf backup, Type auf oneshot und Restart auf Nie, und haken dann „Nach Zeitplan ausführen (.timer erstellen)“ und „Grundlegende Härtung“ an. Mit dem Standardbenutzer und dem Standard-Arbeitsverzeichnis erzeugt der Generator zwei Dateien. 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

und backup.timer:

[Unit]
Description=Run backup on a schedule

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

[Install]
WantedBy=timers.target

Zwei Dinge ändern sich, wenn ein Timer eingeschaltet ist. Die Service-Datei verliert ihren Abschnitt [Install], weil der Timer sie startet, und die Installationsbefehle aktivieren den Timer statt des Dienstes:

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

Type wird beim Anhaken der Timer-Option nicht für Sie geändert; wählen Sie bei Jobs, die enden, selbst oneshot. Ein oneshot-Dienst in Kombination mit Restart Immer ist ungültig, daher lässt der Generator Restart weg und zeigt eine Warnung.

Häufig gestellte Fragen

Wohin gehört die Datei?

Nach /etc/systemd/system/. Führen Sie dann systemctl daemon-reload und systemctl enable --now <name>.service aus – die erzeugten Befehle erledigen das alles.

Warum schlägt mein Dienst mit „Executable path is not absolute“ fehl?

Ältere systemd-Versionen brauchen in ExecStart den vollständigen Pfad zum Programm. Sie finden ihn mit which, z. B. which node.

Timer oder cron?

Timer schreiben ins Journal, können verpasste Läufe nachholen, während der Server aus war, und laufen nie doppelt gleichzeitig. cron ist für Einzeiler einfacher und funktioniert weiterhin gut.

Datenschutz

Dieses Tool läuft vollständig in Ihrem Browser. Ihre Dateien und Texte werden auf Ihrem Gerät verarbeitet und nie auf unsere Server hochgeladen.