Du willst ein eigenes Skript oder Programm als dauerhaften Hintergrunddienst laufen lassen – zuverlässig, mit Autostart und automatischem Neustart nach Absturz? Dafür ist systemd gemacht. In dieser Anleitung erstellst du Schritt für Schritt einen eigenen systemd-Service unter Linux, aktivierst den Autostart und wertest die Logs aus.
Ein selbst geschriebenes Programm oder Skript soll dauerhaft im Hintergrund laufen und nach einem Neustart automatisch wieder starten? Dann führt kein Weg an einem systemd-Service vorbei. systemd ist das zentrale Init-System moderner Linux-Distributionen und verwaltet Dienste zuverlässig: Es startet sie beim Booten, überwacht sie und startet sie bei einem Absturz neu. In dieser Anleitung erstellst du eine eigene Service-Unit, aktivierst sie und lernst, wie du Fehler über das Journal analysierst.
- Was ist ein systemd-Service?
- Schritt 1: Die Unit-Datei anlegen
- Die wichtigsten Optionen erklärt
- Schritt 2: Dienst aktivieren und starten
- Schritt 3: Status und Logs prüfen
- systemd-Timer statt Cron?
- Der Aufbau einer Unit-Datei
- Dienste sicher betreiben
- Fehler über das Journal finden
- Häufige Fragen
- Wohin gehört meine eigene Unit-Datei?
- Warum startet mein Dienst nach dem Reboot nicht?
- Was bedeutet daemon-reload?
- Fazit
Was ist ein systemd-Service?
systemd ist das Init- und Dienstverwaltungssystem der meisten modernen Linux-Distributionen. Ein Service (auch „Unit“) beschreibt einen Dienst, den systemd startet, überwacht und bei Bedarf neu startet. Der große Vorteil gegenüber einem einfachen Skript: Autostart beim Booten, definiertes Neustart-Verhalten und zentrales Logging.
Schritt 1: Die Unit-Datei anlegen
Eigene Services legst du unter /etc/systemd/system/ ab. Erstelle eine Datei mit der Endung .service:
sudo nano /etc/systemd/system/meindienst.serviceFülle sie mit den drei typischen Abschnitten [Unit], [Service] und [Install]:
[Unit]
Description=Mein eigener Dienst
After=network.target
[Service]
Type=simple
ExecStart=/usr/bin/python3 /opt/meinapp/app.py
WorkingDirectory=/opt/meinapp
User=meinuser
Restart=on-failure
RestartSec=5
[Install]
WantedBy=multi-user.targetDie wichtigsten Optionen erklärt
| Option | Bedeutung |
|---|---|
Description | Klartext-Beschreibung des Dienstes |
After=network.target | Erst starten, wenn das Netzwerk bereit ist |
ExecStart | Der auszuführende Befehl (immer mit absolutem Pfad!) |
User | Benutzer, unter dem der Dienst läuft |
Restart=on-failure | Neustart bei Absturz (Alternativen: always, no) |
RestartSec | Wartezeit in Sekunden vor dem Neustart |
WantedBy=multi-user.target | Ziel, an das der Autostart gekoppelt wird |
Achte wie bei Cronjobs unbedingt auf absolute Pfade – systemd läuft mit einer minimalen Umgebung.
Schritt 2: Dienst aktivieren und starten
Nach dem Anlegen oder Ändern einer Unit-Datei musst du systemd die Konfiguration neu einlesen lassen. Anschließend aktivierst und startest du den Dienst in einem Rutsch:
sudo systemctl daemon-reload
sudo systemctl enable --now meindienstDer Parameter enable sorgt für den Autostart beim Booten, --now startet den Dienst sofort mit.
Schritt 3: Status und Logs prüfen
Ob der Dienst läuft, zeigt dir der Status-Befehl:
sudo systemctl status meindienstsystemd sammelt die Ausgabe deines Dienstes automatisch im Journal. Die Logs rufst du mit journalctl ab – mit -f folgst du ihnen live:
journalctl -u meindienst -fsystemd-Timer statt Cron?
Für wiederkehrende Aufgaben bietet systemd mit Timern eine Alternative zu Cronjobs. Timer sind mächtiger (z. B. „5 Minuten nach dem Boot“), aber aufwändiger einzurichten. Für einfache Zeitpläne bleibt Cron die schnellere Lösung; für komplexe Abhängigkeiten oder wenn du ohnehin einen Service hast, sind Timer die sauberere Wahl.
Der Aufbau einer Unit-Datei
Eine Service-Unit gliedert sich in drei Abschnitte, die jeweils eine klare Aufgabe haben. Wenn du ihren Zweck verstehst, konfigurierst du jeden Dienst gezielt statt per Copy-and-paste.
| Abschnitt | Zweck |
|---|---|
[Unit] | Beschreibung und Abhängigkeiten (z. B. „nach dem Netzwerk starten“) |
[Service] | Was und wie gestartet wird (Befehl, Benutzer, Neustart-Verhalten) |
[Install] | Wann der Dienst aktiviert wird (Ziel beim Booten) |
Dienste sicher betreiben
Ein Dienst, der als root läuft, ist ein unnötiges Risiko. Lege für deine Anwendung einen eigenen, rechtebeschränkten Benutzer an und trage ihn mit User= in die Unit ein. systemd bringt darüber hinaus Härtungsoptionen mit, die den Zugriff des Dienstes aufs System einschränken.
User=undGroup=– Dienst läuft mit minimalen Rechten.Restart=on-failure– automatischer Neustart nach Abstürzen.ProtectSystem=strict– schützt Systemverzeichnisse vor Schreibzugriff.NoNewPrivileges=true– verhindert Rechteausweitung.
Fehler über das Journal finden
Startet dein Dienst nicht wie erwartet, liefert das systemd-Journal die Antwort. Mit journalctl -u mein-dienst -e siehst du die neuesten Log-Einträge, mit dem Zusatz -f verfolgst du sie live. Nach jeder Änderung an der Unit-Datei musst du sudo systemctl daemon-reload ausführen, sonst arbeitet systemd noch mit der alten Version.
Der Status-Befehl systemctl status mein-dienst zeigt dir auf einen Blick, ob der Dienst läuft, wann er zuletzt gestartet wurde und mit welchem Exit-Code er gegebenenfalls beendet wurde – der beste Startpunkt für die Fehlersuche. Ergänzend liefert systemctl list-units --type=service --state=failed eine Liste aller fehlgeschlagenen Dienste, falls du nicht sicher bist, wo das Problem liegt.
Für Skripte, die in festen Intervallen laufen sollen, kombinierst du deine Service-Unit mit einem systemd-Timer statt mit einem klassischen Cronjob. Der Vorteil: Timer nutzen dasselbe Logging über das Journal, unterstützen verpasste Ausführungen per Persistent=true und lassen sich sauber mit systemctl verwalten. So hältst du zeitgesteuerte und dauerhaft laufende Aufgaben in einem einheitlichen System, statt zwei getrennte Mechanismen pflegen zu müssen.
Häufige Fragen
Häufige Fragen zum Erstellen eigener systemd-Services.
Wohin gehört meine eigene Unit-Datei?
Selbst erstellte Units legst du unter /etc/systemd/system/ ab. Dieser Pfad ist für Anpassungen durch den Administrator vorgesehen und wird bei Updates nicht überschrieben.
Warum startet mein Dienst nach dem Reboot nicht?
Vermutlich hast du ihn nur gestartet, aber nicht aktiviert. Mit sudo systemctl enable mein-dienst sorgst du dafür, dass er beim Booten automatisch startet.
Was bedeutet daemon-reload?
Mit daemon-reload liest systemd geänderte Unit-Dateien neu ein. Ohne diesen Schritt bleiben Änderungen an der Datei wirkungslos.
Fazit
Mit einer kurzen Unit-Datei machst du aus jedem Skript einen robusten Dienst: Autostart, automatischer Neustart und zentrales Logging inklusive. Die wichtigsten Befehle sind daemon-reload, enable --now und journalctl -u. Damit hast du deine Hintergrunddienste sauber im Griff. Wie du solche Skripte selbst schreibst, zeigt Bash-Skript erstellen.
