systemd-Services sind die Grundlage dafür, dass Programme unter Linux zuverlässig im Hintergrund laufen, beim Systemstart automatisch starten und sauber überwacht werden können. Wenn Sie einen eigenen Dienst betreiben wollen, etwa ein Skript, eine kleine Anwendung oder einen internen Helferprozess, landen Sie auf modernen Linux-Systemen fast immer bei systemd.

Wichtig ist dabei: Ein systemd-Service ist nicht einfach nur „ein Befehl, der gestartet wird“. systemd merkt sich, ob der Dienst läuft, ob er abgestürzt ist, ob er automatisch starten soll und welche Logs er geschrieben hat. Genau deshalb lohnt es sich, das einmal sauber zu verstehen. Diese Anleitung geht Schritt für Schritt vor und prüft nach jedem wichtigen Punkt, ob Ihr Service wirklich das tut, was er soll.

Voraussetzungen

Ein Linux-System mit systemd, zum Beispiel Debian, Ubuntu, RHEL, Rocky, Fedora oder openSUSE
Ein Benutzer mit sudo-Rechten oder direkter Root-Zugang
Grundlegender Umgang mit dem Terminal
Ein Testsystem oder eine unkritische Umgebung, damit Sie das Verhalten gefahrlos üben können. Die Hardware spielt kaum eine Rolle: Eine VM oder ein kleiner VPS mit 1 CPU-Kern, 512 MB RAM und wenigen MB freiem Speicher reicht, x86 oder ARM.

Wichtig vorab: Bauen Sie den ersten eigenen Service nicht direkt um eine produktive Anwendung herum. Für das Verständnis ist ein bewusst einfaches Demo-Beispiel besser, weil Sie damit Status, Logs und Startverhalten isoliert testen können.

Schritt 1: Eine kleine Demo-Anwendung anlegen

Damit Sie systemd nicht nur theoretisch betrachten, erzeugen Sie zuerst ein minimales Skript, das dauerhaft läuft und regelmäßig eine Zeile ausgibt. Genau so lässt sich später gut prüfen, ob der Dienst wirklich gestartet wurde und ob Logs im Journal ankommen.

sudo mkdir -p /opt/myapp/bin
sudo nano /opt/myapp/bin/myapp.sh

Tragen Sie in die Datei diesen Inhalt ein:

#!/bin/bash
while true; do
  echo "myapp läuft: $(date '+%F %T')"
  sleep 30
done

Danach machen Sie das Skript ausführbar:

sudo chmod 755 /opt/myapp/bin/myapp.sh

Verifizieren: Der Schritt ist erfolgreich, wenn die Datei existiert und ausführbar ist. Prüfen Sie das mit:

ls -l /opt/myapp/bin/myapp.sh

Erwartung: Die Ausgabe beginnt bei der Datei mit -rwxr-xr-x oder zeigt zumindest ein Execute-Bit für den Besitzer. Wenn dort kein x steht, kann systemd das Skript später nicht sauber starten.

Schritt 2: Verstehen, wie [Unit], [Service] und [Install] zusammenarbeiten

Bevor Sie die Unit-Datei schreiben, sollten Sie wissen, wofür die drei Bereiche da sind:

[Unit] beschreibt den Dienst und seine Beziehungen zu anderen Units
[Service] enthält die eigentliche Laufzeitkonfiguration
[Install] steuert, ob und wann der Dienst automatisch eingebunden wird

Die wichtigsten Direktiven für den Einstieg sind:

Direktive	Bedeutung
`Description=`	Freitext-Beschreibung des Dienstes
`After=`	Startreihenfolge, zum Beispiel nach dem Netzwerk
`Type=simple`	Standard für Prozesse, die direkt im Vordergrund laufen
`ExecStart=`	Der eigentliche Startbefehl mit absolutem Pfad
`Restart=on-failure`	Neustart bei Fehlern, aber nicht nach bewusstem Stop
`WorkingDirectory=`	Arbeitsverzeichnis des Dienstes
`User=` / `Group=`	Unter welchem Benutzer und welcher Gruppe der Dienst läuft
`WantedBy=multi-user.target`	Autostart beim normalen Systemstart

Für den ersten systemd-Service brauchen Sie nicht jede Spezialoption. Entscheidend ist, dass Sie den Ablauf verstehen: systemd liest die Unit-Datei, kennt dann Ihren Startbefehl, überwacht den Prozess und kann ihn auf Wunsch beim Boot automatisch starten.

Verifizieren: systemctl cat ssh.service (auf RHEL-Systemen sshd.service) zeigt eine vorhandene Unit Ihres Systems. Darin finden Sie die drei Abschnitte wieder: [Unit] erklärt den Rahmen, [Service] definiert das Laufverhalten, [Install] kümmert sich um den Autostart.

Schritt 3: Eigene Unit-Datei unter /etc/systemd/system/ erstellen

Jetzt legen Sie den eigentlichen Service an. Der Dateiname bestimmt auch den späteren Servicenamen.

sudo nano /etc/systemd/system/myapp.service

Fügen Sie diesen Inhalt ein:

[Unit]
Description=Meine Demo-Anwendung mit systemd
After=network.target

[Service]
Type=simple
WorkingDirectory=/opt/myapp
ExecStart=/opt/myapp/bin/myapp.sh
Restart=on-failure
RestartSec=5s
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target

Warum genau diese Fassung?

Type=simple passt hier, weil das Skript direkt im Vordergrund läuft
ExecStart= nutzt einen absoluten Pfad, was bei systemd Pflicht ist
Restart=on-failure ist ein guter Standard, weil Abstürze abgefangen werden, ein bewusstes stop aber respektiert wird
StandardOutput=journal und StandardError=journal sorgen dafür, dass Sie die Ausgaben später sauber mit journalctl lesen können

Verifizieren: Prüfen Sie direkt, ob die Datei am richtigen Ort liegt:

ls -l /etc/systemd/system/myapp.service

Erwartung: Die Datei wird angezeigt. Wenn Sie sie versehentlich unter /etc/systemd/system/myapp ohne .service oder in einem falschen Pfad angelegt haben, findet systemd sie später nicht als Service.

Schritt 4: systemd neu laden und Syntax prüfen

systemd liest neue oder geänderte Unit-Dateien nicht automatisch sofort ein. Genau dafür gibt es daemon-reload.

sudo systemctl daemon-reload
systemd-analyze verify /etc/systemd/system/myapp.service

Wenn systemd-analyze verify keine Ausgabe zeigt, ist das ein gutes Zeichen. Bei Fehlern bekommen Sie normalerweise eine konkrete Zeile oder eine Direktive genannt.

Verifizieren: Dieser Schritt ist erfolgreich, wenn daemon-reload ohne Fehler durchläuft und systemd-analyze verify keine Fehlermeldung ausgibt. Wenn Sie hier schon Fehler sehen, gehen Sie noch nicht zum Starten über.

Schritt 5: Dienst starten und Status lesen

Jetzt starten Sie den Dienst zum ersten Mal bewusst manuell. Das ist wichtig, weil Sie so erst das Laufverhalten prüfen, bevor Sie den Autostart aktivieren.

sudo systemctl start myapp.service
sudo systemctl status myapp.service

Bei einem korrekt laufenden Dienst sollten Sie im Status etwas wie active (running) sehen. Dort finden Sie auch die PID, den Startzeitpunkt und die letzten Logzeilen.

Verifizieren: Der Schritt ist erfolgreich, wenn systemctl status myapp.service den Status active (running) zeigt. Wenn dort failed oder activating (auto-restart) steht, ist der Dienst noch nicht sauber gestartet. Gehen Sie dann zuerst zu den Logs in Schritt 8.

Schritt 6: Autostart aktivieren und prüfen

Erst wenn der Dienst manuell sauber läuft, aktivieren Sie den Autostart.

sudo systemctl enable myapp.service
sudo systemctl is-enabled myapp.service

Sie können Start und Aktivierung auch kombinieren:

sudo systemctl enable --now myapp.service

Wichtig ist die Unterscheidung:

start = läuft jetzt
enable = startet auch bei künftigen Boots

Verifizieren: Der Schritt ist erfolgreich, wenn systemctl is-enabled myapp.service mit enabled antwortet. Wenn der Dienst läuft, aber hier disabled steht, startet er beim nächsten Reboot nicht automatisch.

Schritt 7: Dienst im Alltag verwalten

Im Alltag arbeiten Sie meist mit diesen Befehlen:

sudo systemctl stop myapp.service
sudo systemctl start myapp.service
sudo systemctl restart myapp.service
sudo systemctl disable myapp.service
sudo systemctl reload myapp.service
sudo systemctl show myapp.service

reload funktioniert nur dann sinnvoll, wenn die Anwendung selbst ein Nachladen ihrer Konfiguration unterstützt. Wenn nicht, bleibt meist nur restart.

Verifizieren: Testen Sie bewusst einmal stop und danach status. Erwartung: Der Dienst steht dann nicht mehr auf active (running). Danach starten Sie ihn wieder und prüfen erneut auf active (running). So merken Sie sofort, ob Sie die Steuerbefehle richtig einsetzen.

Schritt 8: Logs mit journalctl auswerten

Die Logs sind bei systemd oft der schnellste Weg zur Ursache. Weil das Demo-Skript regelmäßig Text ausgibt, sollten Sie jetzt auch etwas im Journal sehen.

journalctl -u myapp.service -n 20
journalctl -u myapp.service -f

Die erste Variante zeigt die letzten 20 Zeilen, die zweite bleibt live dran. Eine Live-Ansicht beenden Sie mit Strg+C.

Verifizieren: Dieser Schritt ist erfolgreich, wenn Sie im Journal Zeilen wie myapp läuft: mit Zeitstempel sehen. Wenn der Dienst laut status läuft, aber im Journal gar nichts erscheint, fehlen oft sinnvolle Ausgaben der Anwendung oder die Ausgabe wird nicht im Journal erfasst.

Schritt 9: systemd-Timer als nächster Ausbauschritt

Nicht jede Aufgabe muss als dauerhaft laufender Dienst betrieben werden. Für periodische Aufgaben ist ein systemd-Timer oft die modernere Alternative zu Cron. Das Beispiel setzt ein vorhandenes Skript /usr/local/bin/backup.sh voraus, ersetzen Sie es durch Ihr eigenes. Das Prinzip ist einfach: Eine .service-Datei beschreibt, was ausgeführt wird, und eine .timer-Datei beschreibt, wann es passieren soll.

# /etc/systemd/system/backupjob.service
[Unit]
Description=Täglicher Backup-Job

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup.sh

# /etc/systemd/system/backupjob.timer
[Unit]
Description=Backupjob täglich um 02:00 Uhr

[Timer]
OnCalendar=*-*-* 02:00:00
Persistent=true

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now backupjob.timer
systemctl list-timers
systemctl status backupjob.timer

Verifizieren: Ein Timer ist sauber eingerichtet, wenn er in systemctl list-timers auftaucht und dort eine nächste Ausführung angezeigt wird. Für die eigentliche Logprüfung schauen Sie später in die zugehörige .service-Unit, nicht nur in den Timer selbst.

Troubleshooting

Service startet nicht, Meldung „Unit not found“: Dateiname und Servicename stimmen nicht zusammen oder die Datei liegt nicht unter /etc/systemd/system/.
daemon-reload vergessen: Nach jeder Änderung an der Unit-Datei müssen Sie sudo systemctl daemon-reload ausführen.
ExecStart schlägt fehl: Der Pfad ist nicht absolut oder das Skript ist nicht ausführbar.
status zeigt failed: Direkt mit journalctl -u dienstname.service -n 50 nachsehen, was die Anwendung wirklich gemeldet hat.
Der Dienst läuft als falscher Benutzer: Prüfen Sie User= und Group= in der Unit-Datei und gleichen Sie das mit den Dateirechten Ihrer Anwendung ab.
restart-Schleife: Wenn ein Dienst sofort wieder abstürzt und systemd ständig neu startet, ist meist die eigentliche Anwendung kaputt, nicht systemd selbst.
reload funktioniert nicht: Viele Anwendungen unterstützen kein Nachladen. Dann brauchen Sie statt reload einen echten restart.
Timer läuft nicht: Mit systemd-analyze calendar können Sie den Zeitplan prüfen, zum Beispiel systemd-analyze calendar '*-*-* 02:00:00'.

Häufige Fragen

Was ist der Unterschied zwischen start und enable?

start startet den Dienst sofort. enable sorgt dafür, dass er auch beim nächsten Systemstart automatisch startet. Beides ist nicht dasselbe.

Muss ich nach jeder Änderung daemon-reload ausführen?

Ja, nach jeder Änderung an einer Unit-Datei. Sonst arbeitet systemd weiter mit der alten Version.

Warum brauche ich einen absoluten Pfad bei ExecStart?

Weil systemd keine Shell ist, die erst Ihren aktuellen Pfadkontext errät. Der Startbefehl muss eindeutig und vollständig angegeben werden.

Wann nutze ich User= und Group=?

Immer dann, wenn der Dienst nicht als root laufen soll oder darf. Für echte Anwendungen ist ein eigener Dienstbenutzer oft die sauberere und sicherere Wahl.

Wo sehe ich die Fehler meines Dienstes?

Fast immer zuerst in systemctl status und danach im Detail mit journalctl -u dienstname.service.

Wann ist ein Timer besser als Cron?

Wenn Sie bessere Integration in systemd, saubere Logs im Journal und eine nachvollziehbare Verwaltung über dieselben Werkzeuge wollen. Für neue Linux-Setups ist das oft die modernere Wahl.

Fazit

Ein eigener systemd-Service ist viel weniger magisch, wenn Sie den Ablauf einmal sauber durchgehen: Skript oder Programm anlegen, Unit-Datei schreiben, daemon-reload, Dienst starten, Status prüfen, Logs lesen, erst danach den Autostart aktivieren. Genau diese Reihenfolge verhindert die meisten typischen Fehler und macht die Fehlersuche deutlich einfacher.

Als nächster passender Grundlagenbaustein eignet sich unsere Anleitung zu Linux-Benutzern, Gruppen und Rechten, weil viele Dienste nicht an systemd selbst, sondern an falschen Besitzern, Gruppen oder Dateirechten scheitern. Danach passt je nach Ziel entweder Cron oder die Anleitung zur SSH-Key-Authentifizierung.

Weiterführende Anleitungen und Quellen

Quellen: systemd.service(5) auf man7.org, systemctl(1) auf man7.org, journalctl(1) auf man7.org, systemd.timer(5) auf man7.org.