Systemd-Dienste in Fedora

Unit-Dateien für traditionelle Dienste folgen dem Namensschema foobar.service. Bei der Wahl des Basisnamens ist zu beachten, dass wir für Software über verschiedene Distributionen hinweg einheitliche Dienstnamen verwenden möchten. Außerdem sollen die .service-Dateien in den Upstream-Paketen enthalten sein. Aus diesen Anforderungen ergeben sich folgende Richtlinien für die Benennung von Unit-Dateien:

Aus Gründen der Abwärtskompatibilität empfiehlt es sich, einen symbolischen Link vom alten zum neuen Namen zu erstellen. Im obigen Beispiel hat Fedora beispielsweise immer httpd für den Dienst verwendet. Erstellen Sie beim Anlegen der neuen Datei apache-httpd.service auch einen symbolischen Link namens httpd.service, der auf apache-httpd.service verweist. So können Endbenutzer, die service httpd gewohnt sind, diesen weiterhin nutzen.

Die Zeile EnvironmentFiles= im Abschnitt [Service] von .service-Dateien dient zum Laden von Umgebungsvariablen, die in Unit-Dateien verwendet werden können. Wenn Ihr sysv-initscript beispielsweise eine Datei in /etc/sysconfig verwendet, um Befehlszeilenoptionen festzulegen, können Sie EnvironmentFiles= wie folgt verwenden:

Beispiel:

Anschließend können Sie in den Zeilen ExecStart= (und den zugehörigen Zeilen) mit ${FOOBAR} und $FOOBAR auf Variablen verweisen, die in der Datei /etc/sysconfig/httpd festgelegt sind. (${FOOBAR} erweitert die Variable zu einem Wort, $FOOBAR hingegen teilt den Variablenwert an Leerzeichen in mehrere Wörter auf.)

Das - in der Zeile EnvironmentFile= stellt sicher, dass keine Fehlermeldungen generiert werden, falls die Umgebungsvariablen-Datei nicht existiert. Da viele dieser Dateien in sysvinit optional waren, sollten Sie das - bei Verwendung dieser Direktive angeben.

Für die meisten Dienste möchten wir keine Abhängigkeiten im Abschnitt [Unit] verwenden, wie z. B. Requires= oder Wants=. Stattdessen verwenden wir ausschließlich Reihenfolgeabhängigkeiten: Before= und After=. Dies dient der losen Kopplung: Wenn zwei Dienste gleichzeitig gestartet werden sollen, sorgt systemd für die korrekte Startreihenfolge, ohne dass der Start eines Dienstes zwingend erforderlich ist, wenn der andere gestartet wird.

Wenn Sie eine Anforderungsabhängigkeit verwenden, nutzen Sie Wants= anstelle von Requires=, um die Stabilität zu erhöhen. In fast allen Fällen sollten Sie bei der Verwendung einer Anforderungsabhängigkeit auch eine Reihenfolgeabhängigkeit hinzufügen, da Reihenfolge- und Anforderungsabhängigkeiten in systemd orthogonal sind.

Hier ein Beispiel für diesen häufigen Fall:

Vermeiden Sie es, in allen Zeilen, die Unit-Namen verwenden (wie z.B. +WantedBy), auf +runlevel.target-Units zu verweisen. Dies sind veraltete Namen, die nur wegen der Kompatibilität zu SysV existieren.

Vermeiden Sie Names= (im Abschnitt [Unit]). Es ist in der Regel besser, einen zusätzlichen Namen im Dateisystem zu verlinken. Beachten Sie, dass ein in Names= aufgeführter Name nur dann sinnvoll ist, wenn bereits eine Dienstdatei geladen wurde. Systemd lädt jedoch nur die Dienstdateien, auf die in einem anderen geladenen Dienst verwiesen wird, und verwendet die Dateinamen bei der Suche. Daher ist ein Name in Names= als Suchschlüssel nicht geeignet, ein symbolischer Link im Dateisystem hingegen schon. Fügen Sie außerdem keine (redundante) Zeile Names=foobar.service in eine Datei namens foobar.service ein. Wir möchten unsere Dienstdateien kurz halten.

Unit-Dateien sollten die Verwendung von StandardOutput= oder StandardError= vermeiden. Die Standardeinstellung ist in fast allen Fällen die richtige Wahl, und die Verwendung der Standardeinstellung ermöglicht es Benutzern, globale Standardeinstellungen in /etc/systemd/system.conf zu ändern.

Dies ist eine Beispieldatei für die systemd-Unit .service für ABRT:

Die Hardwareaktivierung erfolgt bei der Installation eines Dienstes, der jedoch nur bei Installation bestimmter Hardware aktiv wird. Die Aktivierung des Dienstes erfolgt üblicherweise über eine udev-Regel. Derzeit liegen uns keine weiteren Hinweise zur Erstellung dieser udev-Regeln vor. Der Dienst selbst installiert seine .service-Dateien an den üblichen Speicherorten und wird wie gewohnt über die systemd-Scriptlets installiert. Diese Dienste sollten niemals über das Paket aktiviert werden, da dies automatisch durch udev erfolgt.

Die Socket-Aktivierung erfolgt, wenn ein Dienst systemd anweist, Verbindungen zu einem bestimmten Socket zu überwachen. Sobald systemd eine Verbindung über diesen Socket empfängt, startet es den Dienst. Dazu sind geringfügige Anpassungen im Quellcode erforderlich, um systemd das Überwachen von Verbindungen über den Socket zu ermöglichen. Außerdem muss sich im Verzeichnis %{_lib}/systemd/system/ eine Datei .socket befinden, die systemd anweist, den Socket zu überwachen und den zu startenden Dienst beim Empfang einer Verbindung festzulegen. Dies ähnelt der Funktionsweise von inetd, und einige, aber nicht alle Dienste, die für die Verwendung mit inetd entwickelt wurden, sind auch zur Socket-Aktivierung kompatibel.

Die Socket-Aktivierung ermöglicht auch den parallelen Start von Diensten. Unterstützt ein Dienst die Socket-Aktivierung von systemd (wie oben beschrieben) und wird er zusätzlich explizit beim Systemstart gestartet, startet systemd ihn und ermöglicht gleichzeitig den Start abhängiger Dienste. Sendet ein abhängiger Dienst eine Anfrage an den Socket-aktivierbaren Dienst, bevor dieser gestartet ist, sorgt systemd dafür, dass die Anfrage wartet, bis der Socket-aktivierbare Dienst gestartet ist und die Anfrage bearbeiten kann. Damit dies funktioniert, muss der Dienst wie oben beschrieben Socket-aktivierbar sein, die Datei .service des Dienstes muss eine Zeile Wants= für die Datei .socket enthalten, und der Dienst muss automatisch starten.

Beachten Sie, dass bestimmte Socket-basierte Dienste (insbesondere solche, die über das Netzwerk lauschen) die Genehmigung von FESCo benötigen – siehe Standarddienste für Details. Sobald Sie die Genehmigung haben, können Sie die Datei .socket paketieren und die systemd-Skripte verwenden, die den Dienst standardmäßig aktivieren. Überprüfen Sie außerdem die Datei .service, um sicherzustellen, dass sie einen Eintrag Wants= für die Datei .socket enthält. Dadurch wird sichergestellt, dass systemd beim Starten des Dienstes über den Socket informiert wird.

Alle Pakete mit zeitgesteuerter Ausführung, die bereits von systemd abhängen (zum Beispiel, weil sie systemd-Units enthalten), müssen Timer-Units anstelle von Cron-Jobs verwenden, ohne Abhängigkeiten oder Anforderungen an eine Crontab.

Pakete, die nicht bereits von systemd abhängen oder dieses benötigen, dürfen keine Timer-Units verwenden, sondern müssen von Crontabs abhängen und diese benötigen, um die Einführung unnötiger neuer Abhängigkeiten von systemd direkt zu vermeiden.

Um den parallelen Start eines D-Bus-Dienstes und seiner Nutzer zu ermöglichen, ist es unerlässlich, dass D-Bus-Dienste über den Bus aktiviert werden können und die Aktivierungsanforderung vom D-Bus-Systembus an systemd weitergeleitet wird. Dadurch wird sichergestellt, dass nur eine einzige Instanz des Dienstes existiert, selbst wenn dieser sowohl beim Systemstart als auch bei der Aktivierung ausgelöst wird. Falls Ihr D-Bus-Dienst bisher nicht über den Bus aktiviert, sondern über ein SysV-Init-Skript gestartet wurde, sollte er auf Busaktivierung umgestellt werden. Dies kann durch das Erstellen einer .service-Datei für D-Bus im Verzeichnis /usr/share/dbus-1/system-services/ und die Verwendung der Direktive SystemdService= in dieser Datei implementiert werden, um die Aktivierung an systemd umzuleiten.

Hier ist ein Beispiel für einen D-Bus-Bus-aktivierbaren Dienst. Die ConsoleKit-Bus-Aktivierungsdatei /usr/share/dbus-1/system-services/org.freedesktop.ConsoleKit.service:

Und die zugehörige systemd-Unit-Datei /usr/lib/systemd/system/console-kit-daemon.service:

Wie Sie sehen können, wird SystemdService= in der D-Bus-Aktivierungsdatei verwendet, um den systemd-Dienst an den D-Bus-Dienst zu binden.

Traditionell konnten D-Bus-aktivierte Dienste nur durch vollständige Deinstallation deaktiviert werden. Mit systemd lassen sich Dienste deaktivieren, indem D-Bus einen systemd-Aliasdienstnamen (der zum Aktivieren/Deaktivieren erstellt oder entfernt werden kann) als Zwischeninstanz für den eigentlichen Dienst aufruft.

Sie können die Deaktivierung einfach implementieren, indem Sie den D-Bus-Dienst auf einen Aliasnamen der eigentlichen Dienstdatei verweisen (im Dateisystem erscheint dies als symbolischer Link in /etc/systemd/system). Dieser Alias wird dann über systemctl enable und systemctl disable gesteuert. Es empfiehlt sich (technisch nicht zwingend erforderlich), diesen Aliasnamen nach dem D-Bus-Busnamen des Dienstes zu benennen und dbus- voranzustellen. Beispiel für Avahi, einen Dienst, den der Administrator möglicherweise deaktivieren muss: Ersetzen Sie SystemdService=avahi-daemon.service in der D-Bus-Aktivierungsdatei durch SystemdService=dbus-org.freedesktop.Avahi.service und definieren Sie dbus-org.freedesktop.Avahi.service anschließend als optionalen Alias für avahi-daemon.service. Dieser Alias kann über die Direktive Alias= im Abschnitt [Install] der systemd-Dienstdatei gesteuert werden. systemctl enable und systemctl disable lesen diese Direktive, um einen symbolischen Link zu erstellen bzw. zu entfernen und den Dienst unter diesem zusätzlichen Namen verfügbar bzw. nicht verfügbar zu machen. Ein vollständiges Beispiel für Avahi:

Hier ist die D-Bus .service-Datei für Avahi (/usr/share/dbus-1/system-services/org.freedesktop.Avahi.service):

Hier ist die Avahi-Systemd-Unit-Datei .service (/usr/lib/systemd/system/avahi-daemon.service):

Die Zeile Alias= stellt sicher, dass die Existenz des Symlinks /etc/systemd/system/dbus-org.freedesktop.Avahi.service durch systemctl enable und systemctl disable gesteuert werden kann.

Beachten Sie, dass das Erstellen/Entfernen von Alias-Symlinks ausschließlich mit systemctl enable und systemctl disable erfolgen sollte. Sie sollten diese Symlinks nicht manuell erstellen.

Generell empfiehlt es sich, für alle bereits busaktivierbaren Dienste native systemd-Units bereitzustellen, damit diese Dienste wie jeder andere Dienst zentral mit Werkzeugen wie systemctl gesteuert und überwacht werden können. Eine ähnliche Logik wie oben beschrieben sollte gelten.

Weitere Informationen zur Busaktivierung finden Sie in der D-Bus-Dokumentation: https://dbus.freedesktop.org/doc/dbus-specification.html#message-bus-starting-services

Systemd-Unit-Dateien müssen entweder in %{_unitdir} oder %{_userunitdir} abgelegt werden, für Systemdienste bzw. Benutzersitzungsdienste. Unit-Drop-ins müssen in den entsprechenden Unterverzeichnissen dieser beiden Verzeichnisse abgelegt werden. Unit-Dateien und Drop-ins müssen für alle Benutzer lesbar sein (d.h. Modus 0644) und dürfen nicht als %config oder %config(noreplace) markiert sein.

Die Makros %{_unitdir} und %{_userunitdir} sind im Paket systemd-rpm-macros definiert, daher ist etwa Folgendes erforderlich, damit sie verfügbar sind:

Informationen zur korrekten Handhabung von Unit-Dateien in Spec-Datei-Scriptlets finden Sie hier.

tmpfiles.d ist ein von systemd bereitgestellter Dienst zur Verwaltung temporärer Dateien und Verzeichnisse für Daemons. Weitere Informationen zur Verwendung von Tmpfiles.d in Fedora-Paketen finden Sie unter: Tmpfiles.d.