Eigene systemd-Services erstellen — Dienste dauerhaft laufen lassen

Warum systemd statt screen oder nohup

Wenn du einen Discord-Bot, eine kleine Node- oder Python-App oder einen Webserver auf deinem vServer betreibst, reicht node bot.js in einer SSH-Sitzung nicht aus: Sobald du dich abmeldest oder der Prozess abstürzt, ist der Dienst weg. Viele behelfen sich mit screen, tmux oder nohup — das funktioniert, überlebt aber keinen Reboot und startet nach einem Absturz nicht von selbst neu.

Genau dafür ist systemd da, der Init- und Dienst-Manager von Debian und Ubuntu. Du beschreibst deinen Dienst einmal in einer kleinen Textdatei (der unit-Datei), und systemd kümmert sich um Start beim Booten, automatischen Neustart nach Fehlern und sauberes Logging. Auf den Nytrix-vServern mit Debian 12 oder Ubuntu 24.04 ist systemd bereits vorhanden, du brauchst nichts zu installieren.

Die unit-Datei verstehen

Eine Service-unit liegt unter /etc/systemd/system/ und endet auf .service. Der Dateiname ist später auch der Name, mit dem du den Dienst ansprichst. Eine unit besteht aus drei Abschnitten:

• [Unit] — Beschreibung und Abhängigkeiten, etwa dass der Dienst erst nach dem Netzwerk starten soll.
• [Service] — das Herzstück: welches Programm läuft, unter welchem Benutzer, wie es bei Fehlern neu startet.
• [Install] — legt fest, wann der Dienst automatisch mitgestartet wird, sobald du ihn aktivierst.

Du brauchst Root-Rechte, um in /etc/systemd/system/ zu schreiben — die hast du auf dem vServer per SSH. Lege die Datei mit einem Editor deiner Wahl an, zum Beispiel nano /etc/systemd/system/meinbot.service.

ExecStart: das Kommando, das läuft

Das wichtigste Feld ist ExecStart. Es enthält den vollständigen Befehl, den systemd ausführt. Wichtig: Hier gehören absolute Pfade hin, denn systemd kennt deine PATH-Umgebung aus der Shell nicht. Statt node schreibst du also /usr/bin/node. Den genauen Pfad findest du mit which node oder which python3.

Ebenso solltest du mit WorkingDirectory festlegen, in welchem Verzeichnis der Dienst startet, damit relative Pfade zu Konfigurations- oder Datendateien stimmen. Mit User und Group legst du fest, unter welchem Konto der Prozess läuft — als Faustregel kein root, sondern ein eigener, eingeschränkter Benutzer. Das begrenzt den Schaden, falls die Anwendung kompromittiert wird.

Restart: nach einem Absturz automatisch hochfahren

Der große Vorteil gegenüber screen ist der Selbstheilungsmechanismus. Mit Restart=always startet systemd den Prozess neu, sobald er sich beendet — egal ob durch Crash oder weil die Anwendung sich selbst beendet hat. Damit ein dauerhaft abstürzender Dienst nicht in einer Endlosschleife rotiert, setzt du RestartSec=5: systemd wartet dann fünf Sekunden zwischen den Versuchen.

Wenn du möchtest, dass nur bei echten Fehlern (also einem Exit-Code ungleich null) neu gestartet wird, nutzt du stattdessen Restart=on-failure. Für die meisten Bots und kleinen Apps ist always die robustere Wahl.

Vollständiges Beispiel: ein Bot als Dienst

So könnte eine unit-Datei für einen Node-basierten Discord-Bot aussehen, der unter dem Benutzer bot im Verzeichnis /opt/meinbot liegt:

• [Unit]
• Description=Discord-Bot für meinen Server
• After=network-online.target
• Wants=network-online.target
• [Service]
• User=bot
• WorkingDirectory=/opt/meinbot
• ExecStart=/usr/bin/node /opt/meinbot/index.js
• Restart=always
• RestartSec=5
• [Install]
• WantedBy=multi-user.target

Das gleiche Schema funktioniert für eine Python-App (ExecStart=/usr/bin/python3 /opt/app/main.py), einen kleinen Webserver oder jedes andere Programm, das im Vordergrund läuft. Wichtig ist nur, dass dein Prozess nicht selbst in den Hintergrund forkt — systemd will ihn im Vordergrund halten und selbst überwachen.

enable und start: aktivieren und ausführen

Nachdem du die Datei gespeichert hast, muss systemd sie einlesen. Das machst du einmalig und nach jeder Änderung an der unit mit systemctl daemon-reload. Danach hast du zwei getrennte Befehle, die oft verwechselt werden:

• systemctl start meinbot startet den Dienst sofort für die laufende Sitzung.
• systemctl enable meinbot sorgt dafür, dass er bei jedem Boot automatisch mitstartet — er wird aber nicht sofort gestartet.

Praktisch ist systemctl enable --now meinbot: Das aktiviert den Autostart und startet den Dienst in einem Schritt. Ob alles läuft, prüfst du mit systemctl status meinbot. Dort siehst du, ob der Dienst active (running) ist, seit wann er läuft und die letzten Log-Zeilen. Mit systemctl restart meinbot startest du ihn neu, mit systemctl stop meinbot hältst du ihn an.

Logs lesen mit journalctl

Alles, was dein Dienst auf die Standardausgabe schreibt, sammelt systemd automatisch im Journal — du musst dich also nicht selbst um Logdateien kümmern. Die Logs eines bestimmten Dienstes liest du mit journalctl -u meinbot. Diese Optionen helfen im Alltag:

• journalctl -u meinbot -f — folgt dem Log live, wie ein tail -f.
• journalctl -u meinbot -n 50 — zeigt die letzten 50 Zeilen.
• journalctl -u meinbot --since "10 min ago" — nur die jüngsten Einträge.

Wenn dein Dienst nach dem Start sofort wieder stoppt, ist journalctl die erste Anlaufstelle: Oft steht dort ein falscher Pfad in ExecStart, ein fehlendes Modul oder ein Rechteproblem beim gewählten Benutzer. Bei der Live-Konsole deines vServers kannst du das parallel verfolgen.

Mit Nytrix umsetzen

Für eigene systemd-Dienste brauchst du Root-Zugriff — den bekommst du bei den Nytrix-vServern per SSH inklusive. Schon der No-IP-Tarif für 1,99 EUR/Monat bringt 4 vCore, 4 GB RAM und 40 GB Speicher mit und reicht für einen Bot oder eine kleine App locker aus; die geteilte Subdomain vmXXXX.noip.enjyn.de ist inklusive. Brauchst du eine eigene IPv4, starten die BASIC-Tarife bei 9,99 EUR/Monat (BASIC-4). Alle vServer laufen auf SSD/NVMe, bringen 5 TB Traffic im Monat mit und lassen sich per Hot-Plug bei CPU und RAM aufrüsten.

Neu installieren kannst du jederzeit mit Debian 12 oder Ubuntu 24.04 — beide bringen systemd direkt mit. Der DDoS-Schutz über die Voxility-Filterung ist bei allen Tarifen inklusive. Da Nytrix per Prepaid und ohne Mindestlaufzeit arbeitet, kannst du klein anfangen und bei Bedarf wachsen. Für den passenden Bot brauchst du womöglich gar keinen vollen Server: Reine Discord-Bots gibt es bei Nytrix bereits als fertigen Fix-Tarif ab 1,99 EUR/Monat. Wenn du dein eigenes Backup-Script laufen lassen willst, bietet sich der FTP Storage als Ziel an.