Systemd-Service-Datei-Generator
Fülle Executable, Arbeitsverzeichnis, Restart-Richtlinie und Nutzer aus — erhalte eine installationsfertige .service-Unit (und optional eine begleitende .timer-Unit), mit jeder erzeugten Zeile erklärt.
Presets
Von einer üblichen Workload ausgehen
Lädt sinnvolle Standardwerte für die Felder unten. Alles bleibt danach editierbar.
[Unit]
Beschreibung & Reihenfolge
Der Abschnitt [Unit] ist Metadaten und Reihenfolge — er sagt systemd, was dieser Dienst ist und wonach er starten soll, startet selbst aber nichts.
Units, nach denen gestartet werden soll, durch Leerzeichen getrennt.
[Service] — Prozess
Was ausgeführt werden soll
Absoluter Pfad erforderlich.
Übernimmt User, wenn leer gelassen.
[Service] — Umgebung
Umgebungsvariablen
Jede Zeile wird zu einer eigenen Environment=-Zeile. Nutze EnvironmentFile stattdessen für Geheimnisse, die nicht direkt in der Unit-Datei stehen sollen.
Optional, absoluter Pfad.
[Install]
Wann es automatisch startet
Der Abschnitt [Install] spielt nur für systemctl enable eine Rolle — er legt fest, welche Boot-Sequenz diesen Dienst mit hineinziehen soll.
[Service] — Zuverlässigkeit
Restart-Richtlinie
Kein einfacher Ein-/Aus-Schalter — wähle die Variante, die dazu passt, wie dieser Prozess ausfallen soll.
Startet neu bei Absturz, Exit ungleich null oder Timeout — ein bewusstes „systemctl stop“ oder ein sauberer exit(0) bleibt aber unangetastet. Die übliche Wahl für eine langlebige App oder einen Game-Server: erholt sich von Abstürzen, ohne einen Admin zu bekämpfen, der absichtlich gestoppt hat.
Wartezeit in Sekunden vor dem Neustart.
Optional
Begrenzt, wie viel RAM und CPU dieser eine Dienst nutzen darf. Lass das aus, außer du brauchst wirklich eine harte Obergrenze.
Validierung
Häufige Fehler
Sieht sauber aus — keine Probleme gefunden.
Optionale Begleit-Unit
Führt diesen Dienst nach Zeitplan aus (statt oder zusätzlich zum Booten) — das systemd-Gegenstück zu einem Cronjob, gebunden an Type=oneshot-Workloads. Bevorzugst du klassisches Cron für etwas Einfaches? Ein eigener Cronjob-Generator deckt das ab — OnCalendar= hat eine andere Syntax als Cron und ist kein direkter Ersatz.
Ausgabe
Erzeugte Unit-Datei(en)
my-application.service
[Unit] Description=My application After=network.target Wants=network.target [Service] Type=simple ExecStart=/usr/bin/node /opt/wespner-app/server.js WorkingDirectory=/opt/wespner-app User=wespner-app Environment="NODE_ENV=production" Environment="PORT=3000" Restart=on-failure RestartSec=5 [Install] WantedBy=multi-user.target
Installationsbefehle
sudo cp my-application.service /etc/systemd/system/my-application.service sudo systemctl daemon-reload sudo systemctl enable --now my-application.service journalctl -u my-application.service -f # follow logs
Betreibst du einen eigenen Gameserver?
Wespner-Gameserver mit DDoS-Schutz, NVMe-Laufwerken und Aktivierung innerhalb von Minuten.