Systemd meistern: Erstellen Ihrer ersten benutzerdefinierten Service-Unit-Datei

Systemd ist zum allgegenwärtigen Dienstemanager in modernen Linux-Distributionen geworden und verantwortlich für alles, von der Systemstartinitialisierung bis zur Verwaltung laufender User-Space-Dienste. Das Verständnis, wie benutzerdefinierte Unit-Dateien geschrieben werden, ist grundlegend für die Automatisierung der Anwendungsbereitstellung, die Sicherstellung des korrekten Neustarts von Diensten und die nahtlose Integration maßgeschneiderter Prozesse in den Lebenszyklus des Betriebssystems.

Diese umfassende Anleitung führt Sie durch die wesentliche Struktur einer Systemd Service Unit-Datei und behandelt die kritischen Abschnitte [Unit], [Service] und [Install]. Am Ende dieses Tutorials werden Sie in der Lage sein, Ihren eigenen benutzerdefinierten Dienst zu definieren, zu aktivieren und zu verwalten.

Voraussetzungen

Stellen Sie vor dem Eintauchen in die Konfiguration sicher, dass Sie über Administratorzugriff (sudo) und ein grundlegendes Verständnis des Linux-Dateisystems verfügen. Diese Anleitung geht davon aus, dass Sie auf einer modernen Distribution mit Systemd arbeiten (z. B. Debian, Ubuntu, Fedora, CentOS 7+/RHEL 7+).

Systemd Unit-Dateien verstehen

Eine Systemd Unit-Datei ist eine Konfigurationsdatei im INI-Stil, die eine von Systemd verwaltete Ressource beschreibt. Für Dienste befinden sich diese Dateien typischerweise in /etc/systemd/system/ für benutzerdefinierte oder administrierendefinierte Dienste oder in /lib/systemd/system/ für vom Anbieter gelieferte Dienste.

Service-Unit-Dateien müssen mit der Erweiterung .service enden (z. B. mydaemon.service). Die Struktur ist in obligatorische und optionale Abschnitte unterteilt, wobei die drei wichtigsten [Unit], [Service] und [Install] sind.

Schritt 1: Erstellen des Service-Skripts (die ausführbare Datei)

Bevor wir die Unit-Datei erstellen, benötigen wir ein einfaches Skript oder eine Anwendung, die der Dienst verwalten soll. In diesem Beispiel erstellen wir ein einfaches Skript, das alle 10 Sekunden eine Nachricht protokolliert.

Erstellen Sie das Skriptverzeichnis und die Datei:

bash sudo mkdir -p /opt/my-custom-service sudo nano /opt/my-custom-service/reporter.sh
Fügen Sie den folgenden Inhalt zu reporter.sh hinzu:

```bash

!/bin/bash

LOG_FILE="/var/log/reporter.log"
while true; do
echo "$(date +'%Y-%m-%d %H:%M:%S') - Custom service heartbeat active." >> $LOG_FILE
sleep 10
done
```
Machen Sie das Skript ausführbar:

bash sudo chmod +x /opt/my-custom-service/reporter.sh

Schritt 2: Definieren der benutzerdefinierten Service-Unit-Datei

Jetzt erstellen wir die Systemd Unit-Datei, die Systemd mitteilt, wie unser Skript ausgeführt werden soll.

Erstellen Sie die Service-Datei:

bash sudo nano /etc/systemd/system/my-reporter.service
Füllen Sie die Datei mit den Standardabschnitten:

Der Abschnitt [Unit]

Dieser Abschnitt enthält Metadaten über den Dienst und definiert seine Beziehungen zu anderen Einheiten (Diensten, Sockets, Mount-Punkten usw.).

Description: Ein menschenlesbarer Name für den Dienst.
After: Gibt an, dass dieser Dienst erst gestartet werden soll, nachdem die aufgeführten Einheiten erfolgreich gestartet wurden.

[Unit]
Description=My Custom Reporter Daemon
# Start only after basic networking and logging services are operational
After=network.target

Der Abschnitt [Service]

Dies ist der Kernabschnitt, der definiert, welcher Befehl ausgeführt und wie Systemd den Prozess verwalten soll.

Type: Definiert den Starttyp des Prozesses. simple ist Standard für Skripte, die kontinuierlich im Vordergrund laufen.
User/Group: Gibt an, unter welchem Benutzerkontext der Prozess ausgeführt werden soll (dringend empfohlen aus Sicherheitsgründen).
ExecStart: Der absolute Pfad zum Befehl oder Skript, das beim Starten des Dienstes ausgeführt werden soll.
Restart: Definiert die Richtlinie für automatische Neustarts (z. B. on-failure, always).

[Service]
Type=simple
User=your_username # WICHTIG: Ersetzen Sie 'your_username' durch einen Nicht-Root-Benutzer, wenn möglich
Group=your_group # Optional, passt normalerweise zur Benutzergruppe

# Der Befehl, den Systemd ausführt
ExecStart=/opt/my-custom-service/reporter.sh

# Neustartrichtlinie
Restart=on-failure
RestartSec=5s # 5 Sekunden warten, bevor ein Neustart versucht wird
StandardOutput=journal # Ausgabe an das Systemd-Journal weiterleiten
StandardError=journal

Sicherheitshinweis: Führen Sie niemals benutzerdefinierte Dienste als root-Benutzer aus, es sei denn, dies ist absolut notwendig. Definieren Sie einen dedizierten Benutzer mit minimalen Rechten für Anwendungsprozesse.

Der Abschnitt [Install]

Dieser Abschnitt gibt an, wie der Dienst aktiviert werden soll – insbesondere, zu welchem Ziel er verknüpft werden soll, damit er beim Booten automatisch startet.

WantedBy: Gibt das Ziel an, das diesen Dienst einbeziehen soll. Für Standard-Systemdienste, die beim normalen Booten starten sollen, ist multi-user.target die Standardwahl.

[Install]
WantedBy=multi-user.target

Schritt 3: Neuladen, Aktivieren und Starten des Dienstes

Nachdem eine Unit-Datei erstellt oder geändert wurde, müssen Sie Systemd anweisen, seine Konfigurationsdaemons neu zu laden und dann den neuen Dienst zu verwalten.

Neuladen der Systemd-Manager-Konfiguration:
Dieser Schritt ist obligatorisch, wann immer eine Unit-Datei hinzugefügt oder geändert wird.

bash sudo systemctl daemon-reload
Aktivieren des Dienstes (Automatischer Start beim Booten):
Dies erstellt symbolische Links vom entsprechenden Zielverzeichnis (z. B. multi-user.target.wants/) zu Ihrer Service-Datei, um sicherzustellen, dass sie beim Systemstart automatisch gestartet wird.

bash sudo systemctl enable my-reporter.service
Die Ausgabe bestätigt die Erstellung des Symlinks.
Starten des Dienstes:
Dies startet sofort den in ExecStart definierten Prozess.

bash sudo systemctl start my-reporter.service

Schritt 4: Überprüfen des Dienststatus und der Protokolle

Es ist entscheidend zu überprüfen, ob Ihr Dienst korrekt gestartet wurde und wie beabsichtigt läuft.

Status prüfen:
Der Befehl status liefert den aktuellen Zustand, die letzten Protokollzeilen und Ausführungsdetails.

bash systemctl status my-reporter.service

Achten Sie in der Ausgabe auf Active: active (running).
Protokolle anzeigen (Journalctl):
Da wir die Ausgabe in der [Service]-Sektion an das Journal weitergeleitet haben, können wir journalctl verwenden, um Laufzeitmeldungen anzuzeigen.

bash journalctl -u my-reporter.service -f
Überprüfen der Dateiausgabe:
Überprüfen Sie die in unserem Skript angegebene Protokolldatei:

bash tail -f /var/log/reporter.log

Wesentliche Verwaltungsbefehle

Nach der Definition ist die Verwaltung Ihres Dienstes mit dem Befehl systemctl unkompliziert:

Aktion	Befehl
Dienst stoppen	`sudo systemctl stop my-reporter.service`
Dienst neu starten	`sudo systemctl restart my-reporter.service`
Automatisches Booten deaktivieren	`sudo systemctl disable my-reporter.service`
Status prüfen	`systemctl status my-reporter.service`

Zusammenfassung und nächste Schritte

Durch das Meistern der Abschnitte [Unit], [Service] und [Install] haben Sie erfolgreich einen robusten, verwalteten Dienst mit Systemd erstellt. Diese Grundlage ermöglicht es Ihnen, komplexe Anwendungslebenszyklen zu verwalten und eine zuverlässige Startreihenfolge, automatisierte Neustarts bei Fehlern und zentralisierte Protokollierung über das Systemd-Journal sicherzustellen.

Erkunden Sie für fortgeschrittenere Anwendungsfälle Optionen innerhalb des Abschnitts [Service], wie z. B. EnvironmentFile zum Laden von Konfigurationen oder das Ändern des Type auf forking für die traditionelle Daemon-Verwaltung.