Einführung in die Grundlagen von systemd

Der erste Abschnitt in den meisten Unit-Dateien ist der Abschnitt [Unit]. In diesem Abschnitt definieren Sie die Metadaten der Unit-Datei und konfigurieren die Beziehung der Unit-Datei zu anderen Unit-Dateien. Dieser Abschnitt wird in der Regel an erster Stelle platziert, da er einen Überblick über die Unit-Datei gibt.

Abschnitte mit Direktiven speziell für den jeweiligen Typ. Eine Liste der verfügbaren Typen finden Sie unter Abschnitt 4, „Unit-Dateitypen“. Beachten Sie, dass die Typen device, target, snapshot und scope keinen typenspezifischen Abschnitt haben.

Dies ist oft der letzte Abschnitt in der Unit-Datei und ist optional. In diesem Abschnitt wird das Verhalten einer Unit-Datei definiert, wenn sie aktiviert oder deaktiviert wird. Wenn Sie eine Unit-Datei aktivieren, wird sie automatisch beim Booten gestartet. Je nach Unit besteht ggf. eine Abhängigkeit von anderen, zugehörigen Units, damit die Unit ordnungsgemäß arbeitet. Zum Beispiel benötigt chrony die Anweisungen After, Wants und Before, die alle Abhängigkeiten für chrony sind, damit es funktioniert.

Beschreibt, wie ein Dienst oder eine Anwendung verwaltet wird. Dazu gehört, wie Sie den Dienst starten oder stoppen, seine Konfigurationsdatei neu laden (falls zutreffend), unter welchen Bedingungen der Dienst automatisch startet sowie die Abhängigkeit oder die Hierarchieinformationen für zugehörige Unit-Dateien.

Diese Unit-Datei wird von systemd automatisch aus den von der D-Bus-Schnittstelle empfangenen Informationen erstellt und dient der Verwaltung von extern festgelegten Systemprozessen.

Definiert einen Pfad für die pfadbasierte Aktivierung. Standardmäßig wird eine .service-Unit-Datei mit demselben Basisnamen aktiviert. inotify ist eine Kernel-API und wird von Programmen verwendet, die über Änderungen an Dateien benachrichtigt werden sollen.

Das Kommando systemctl snapshot erstellt automatisch eine .snapshot-Unit-Datei. Dieses Kommando erstellt temporäre Snapshots mit dem aktuellen Systemstatus. Sie können den aktuellen Systemstatus bearbeiten, nachdem Sie Änderungen vorgenommen haben. Die Snapshots ermöglichen ein Rollback eines temporären Status.

Definiert einen Zeitgeber, der von systemd verwaltet wird. Dies ist mit einem Cron-Auftrag für die verzögerte oder geplante Aktivierung vergleichbar. Beim Erreichen des Zeitgebers wird eine Unit-Datei mit demselben Namen, jedoch mit der Dateinamenerweiterung .service gestartet.

Verknüpfte Linux-Steuerungsgruppenknoten, mit denen Ressourcen zu Prozessen zugewiesen (oder auf Prozesse beschränkt) werden, die mit dem Abschnitt verknüpft sind. Der Name weist auf die Hierarchie in der Steuerungsgruppen-Baumstruktur hin. Units werden standardmäßig nach ihrem Typ in Abschnitte platziert.

Führt die Synchronisierung für andere Units bei einem Bootvorgang oder einer Statusänderung durch oder versetzt das System in einen neuen Status. Andere Units geben ihre Beziehung zu Targets an, damit sie mit den Vorgängen des Targets synchronisiert werden.

Beschreibt ein Netzwerk, einen IPC-Socket oder einen FIFO-Puffer, mit dem systemd die socketbasierte Aktivierung durchführt. Es gibt eine verknüpfte .service-Datei, die gestartet wird, wenn eine Aktivität auf dem Socket festgestellt wird, der in dieser Unit definiert ist.

Definiert ein Gerät, das für die systemd-Verwaltung durch das udev- oder sysfs-Dateisystem bestimmt ist. Die .device-Datei ist nicht auf allen Geräten vorhanden. Diese Unit-Datei ist für das Sortieren und Einhängen eines Geräts sowie für den Zugriff auf das betreffende Gerät erforderlich.

Definiert den Swap-Speicher im System. Der Name der Unit-Datei muss den Geräte- oder Dateipfad des Raums wiedergeben.

Definiert einen Einhängepunkt im System, der von systemd verwaltet werden soll. Diese Datei ist nach dem Einhängepfad benannt, wobei die Schrägstriche in Bindestriche umgewandelt werden. Für Einträge in /etc/fstab können Units automatisch erstellt werden.

Definiert einen Einhängepunkt, der automatisch eingehängt wird. Benennen Sie die Datei nach dem Einhängepunkt, auf den sie sich bezieht. Eine passende .mount-Unit-Datei ist erforderlich, in der die Einzelheiten für das Einhängen definiert werden.

Wenn Unit A beispielsweise Wants=unit B enthält, wird beim Ausführen von Unit A auch Unit B ausgeführt. Doch ob Unit B erfolgreich startet oder nicht, wirkt sich nicht auf die erfolgreiche Ausführung von Unit A aus.

Enthält Unit A den Eintrag Requires=unit B, werden beide Units ausgeführt, doch wenn Unit B nicht erfolgreich ausgeführt wird, wird Unit A deaktiviert. Dabei spielt es keine Rolle, ob die Prozesse von Unit A erfolgreich ausgeführt worden wären.

Wenn Unit A beispielsweise Before=unit B enthält, wird beim Ausführen der beiden Units zunächst Unit A vollständig ausgeführt und dann erst Unit B.

Wenn Unit A den Eintrag After=unit B enthält, wird beim Ausführen der beiden Units zunächst Unit B vollständig ausgeführt und dann erst Unit A.

Bootet standardmäßig. Die Datei default.target ist ein symbolischer Link zur eigentlichen Target-Datei, z. B. graphical.target für eine Desktop-Arbeitsstation. Für einen Server ist dies in der Regel graphical.target.

Fährt das System herunter und schaltet es aus.

Ziel-Unit, die das Basissystem abruft und eine Rettungs-Shell-Sitzung startet.

Richtet ein nicht grafisches (Konsolen-)Mehrbenutzersystem ein.

Verwendet ein grafisches Mehrbenutzersystem mit Netzwerkdiensten.

Fährt das System herunter und bootet es neu.

Bevor Sie einen systemd-Dienst starten oder aktivieren, prüfen Sie die Syntax der Unit-Datei daraufhin, ob eventuell Fehler vorliegen. Beispiel:

> sudo systemd-analyze verify /etc/systemd/system/my-custom-service.service

Das Kommando analysiert die Unit-Datei und meldet etwaige Syntaxfehler, fehlende Dateien oder andere Probleme. Sie müssen alle gemeldeten Probleme beheben, bevor Sie den Dienst aktivieren und starten.

Falls Probleme mit einem systemd-Dienst auftreten, prüfen Sie das Protokoll dieses Dienstes. Beispiel:

> sudo  journalctl -u my-custom-service.service

Das Kommando zeigt Protokolle für den angegebenen Dienst, die alle Fehlermeldungen, Warnungen oder andere relevante Informationen enthalten. Anhand dieser Protokolle können Sie Probleme mit dem Dienst erkennen und beheben.

Wenn ein Dienst während des Boot-Prozesses Probleme verursacht, können Sie mit systemd-analyze plot command den Boot-Prozess visualisieren und Probleme identifizieren. Beispiel:

> sudo systemd-analyze plot > boot-plot.svg

Mit dem Kommando wird eine SVG-Datei namens boot-plot.svg erstellt, die eine grafische Darstellung des Boot-Prozesses und möglicher Probleme enthält. Dazu gehören auch die Start- und Endzeiten der einzelnen Dienste. Sie können diese Datei in einem SVG-kompatiblen Bildbetrachtungsprogramm oder Webbrowser öffnen und dann die Dienste analysieren, die Probleme beim Bootvorgang verursachen.

So finden Sie heraus, welche Dienste ausgefallen sind und können die Protokollausgabe einsehen:

> sudo systemctl --state=failed

So ermitteln Sie den aktuellen Laufzeitstatus eines Dienstes:

> sudo systemctl status SERVICE

Wenn das Herunterfahren oder Neubooten lange dauert, kann dies darauf hinweisen, dass ein Dienst nicht geschlossen wird. systemd wartet eine gewisse Zeit ab, bis jeder Dienst geschlossen wird, bevor versucht wird, den betreffenden Dienst zu beenden. Häufig liegt das Problem daran, dass ein Dienst angehalten oder sich beim Herunterfahren aufgehängt hat. So klären Sie diesen Punkt:

> sudo systemctl poweroff
  Failed to power off system via logind: There's already a shutdown or sleep operation in progress

> sudo systemctl list-jobs

Sie können die laufenden und wartenden Aufträge abbrechen und erneut herunterfahren oder neu starten:

> sudo systemctl cancel

> sudo systemctl stop systemd-suspend.service

So ermitteln Sie den aktuellen Laufzeitstatus eines Dienstes:

> sudo systemctl status SERVICE

Verwenden Sie einen absoluten Pfad für ausführbare Dateien und erforderliche Dateien, wie Konfigurationsdateien oder Skripte in Ihrer Unit-Datei systemd. systemd ermittelt den Speicherort der Dateien nicht anhand der Umgebungsvariablen des Benutzers wie $PATH.

Fügen Sie die Direktive ExecReload in den Abschnitt [SERVICE] ein, wenn Sie ein bestimmtes Kommando definieren möchten, das ausgeführt werden soll, sobald Sie einen Dienst mit dem Kommando systemctl reload neu laden. Diese Vorgehensweise eignet sich für Dienste, die ihre Konfiguration dynamisch ohne Neustart erneut laden können.

[Service]
ExecStart=PATH_TO_EXECUTABLE
ExecReload=PATH_TO_RELOAD_SCRIPT

Fügen Sie die Direktive RestartSec in den Abschnitt [SERVICE] ein, wenn Sie eine Verzögerung (in Sekunden) definieren möchten, bevor der Dienst nach einem Fehler neu gestartet wird. Diese Vorgehensweise eignet sich für Dienste, bei denen es eine gewisse Zeit dauert, bis Ressourcen freigegeben werden. Außerdem können damit schnelle Neustartschleifen verhindert werden, die eine hohe Systemauslastung verursachen können.

[Service]
ExecStart=PATH_TO_EXECUTABLE
Restart=on-failure
RestartSec=5

Sie können den Notfallmodus auf einem entfernten Computer deaktivieren, z. B. auf einer virtuellen Maschine, die in der Google-Cloud gehostet wird. Wenn dieser Modus aktiviert ist, kann sich der betreffende Computer nicht mit dem Netzwerk verbinden. Beispiel:

> sudo systemctl mask emergency.service

> sudo systemctl mask emergency.target