Ubuntu Manpage: systemd.generator - Systemd Unit-Generatoren

BEZEICHNUNG

       systemd.generator - Systemd Unit-Generatoren

ÜBERSICHT

       /Pfad/zum/Generator normales-Verz frühes-Verz spätes-Verz

       /run/systemd/system-generators/*
       /etc/systemd/system-generators/*
       /usr/local/lib/systemd/system-generators/*
       /lib/systemd/system-generators/*

       /run/systemd/user-generators/*
       /etc/systemd/user-generators/*
       /usr/local/lib/systemd/user-generators/*
       /usr/lib/systemd/user-generators/*

BESCHREIBUNG

Generatoren sind kleine Programme, die sich in /lib/systemd/system-generators/ und anderen
oben aufgeführten Verzeichnissen befinden. systemd(1) führt diese Programme sehr früh beim
Systemstart und zum Zeitpunkt des Neuladens der Konfiguration aus, — bevor Unit-Dateien
geladen werden. Ihr Hauptzweck besteht in der Umwandlung von Konfigurations- und
Ausführungs-Kontextparametern, die für den Dienste-Verwalter nicht nativ sind, in
dynamisch erstellte Unit-Dateien, Symlinks oder Unit-Ergänzungsdateien, so dass sie die
Unit-Datei-Hierarchie des Diensteverwalters, auf dem er nachfolgend lädt und agiert,
erweitern können.

Jeder Generator wird mit drei Verzeichnispfaden, die für die Ausgabe der Generatoren
verwandt werden, aufgerufen. In diesen drei Verzeichnissen dürfen Generatoren Unit-Dateien
(reguläre, Instanzen sowie Vorlagen) und für .d-Verzeichnisse für Unit-Ergänzungsdateien
erstellen und symbolische Links auf Unit-Dateien erstellen, um zusätzliche Abhängigkeiten
zu erstellen, Aliase zu erstellen oder bestehende Vorlagen zu instantiieren.

Verzeichnispfade unterscheiden sich durch Priorität: …/generator.early hat höhere
Priorität als die Administratorkonfiguration in /etc/, während …/generator eine niedrigere
Priorität als /etc/, aber eine höhere als die der Lieferantenkonfiguration in /usr/ hat.
…/generator.late hat eine niederigere Priorität als alle anderen Konfigurationen. Siehe
den nächsten Abschnitt und die Diskussion von Unit-Ladepfaden und Unit-Außerkraftsetzungen
in systemd.unit(5).

Generatoren werden aus einer Gruppe von Pfaden, wie oben aufgeführt, die während der
Übersetzung bestimmt wird, geladen. System- und Benutzergeneratoren werden von
Verzeichnissen mit Namen, die auf system-generators/ bzw. user-generators/ enden, geladen.
Zuerst in den Verzeichnissen gefundene Generatoren setzen diejenigen, mit dem gleichen
Namen in Verzeichnissen weiter hinten in der Liste stehen, außer Kraft. Ein Symlink auf
/dev/null oder eine leere Datei kann zum Ausmaskieren eines Generators verwandt und damit
dessen Ausführung verhindert werden. Bitte beachten Sie, dass die Reihenfolge der zwei
Verzeichnisse mit der höchsten Priorität in Hinblick auf den Unit-Ladepfad invertiert ist
und dass Generatoren in /run/ solche in /etc/ außer Kraft setzen.

Nach der Installation neuer Generatoren oder der Aktualisierung der Konfiguration darf
systemctl daemon-reload ausgeführt werden. Dies löscht die vorherige, von den Generatoren
erstellte Konfiguration, führt alle Generatoren erneut aus und führt dazu, dass systemd
alle Units von Platte neu lädt. Siehe systemctl(1) für weitere Informationen.

AUSGABEVERZEICHNISSE

Generatoren werden mit drei Argumenten aufgerufen: Pfade zu Verzeichnissen, in denen
Generatoren ihre erstellten Unit-Dateien oder Symlinks ablegen können. Standardmäßig sind
diese Pfade Laufzeitverzeichnisse, die im Suchpfad von systemd enthalten sind, aber zu
Fehlersuchzwecken kann ein Generator mit anderen Pfaden aufgerufen werden.

1. normales-Verz

Bei normaler Verwendung ist dies /run/systemd/generator im Falle von Systemgeneratoren
und $XDG_RUNTIME_DIR/generator im Falle von Benutzergeneratoren. Unit-Dateien, die in
diesen Verzeichnissen abgelegt sind, haben vor der Lieferanten-Unit-Konfiguration
Vorrang, aber nicht vor der nativen Benutzer-/Administrator-Unit-Konfiguration.

2. frühes-Verz

Bei normaler Verwendung ist dies /run/systemd/generator.early im Falle von
Systemgeneratoren und $XDG_RUNTIME_DIR/generator.early im Falle von
Benutzergeneratoren. Unit-Dateien, die in diesen Verzeichnissen abgelegt sind, setzen
Unit-Dateien in /usr/, /run/ und /etc/ außer Kraft. Dies bedeutet, dass Unit-Dateien,
die in diesen Verzeichnissen abgelegt sind, Vorrang vor der gesamten normalen
Konfiguration haben, sowohl von Lieferanten als auch vom Benutzer/Administrator.

3. spätes-Verz

Bei normaler Verwendung ist dies /run/systemd/generator.late im Falle von
Systemgeneratoren und $XDG_RUNTIME_DIR/generator.late im Falle von
Benutzergeneratoren. Dieses Verzeichnis kann dazu verwandt werden, den Unit-Dateibaum
auszuweiten, ohne irgendeine andere Unit-Datei außer Kraft zu setzen. Jede vom
Lieferanten oder vom Benutzer/Administrator bereitgestellte native Konfigurationsdatei
hat Vorrang.

UMGEBUNGSVARIABLEN

Der Diensteverwalter setzt beim Aufruf von Generator-Programmen eine Reihe von
Umgebungsvariablen. Sie tragen Informationen über den Ausführungskontext des Generators,
um die Anpassung von Generatoren an bestimmte Umgebungen zu vereinfachen. Es werden die
folgenden Umgebungsvariablen gesetzt.

$SYSTEMD_SCOPE
Falls der Generator vom Systemdiensteverwalter aufgerufen wird, dann ist diese
Variable auf »system« gesetzt; falls er vom benutzerbezogenen Diensteverwalter
aufgerufen wurde, dann ist sie auf »user« gesetzt.

$SYSTEMD_IN_INITRD
Falls der Generator als Teil des anfänglichen RAM-Dateisystems (Initrd) ausgeführt
wird, ist sie auf »1« gesetzt. Falls sie vom regulären Rechner ausgeführt wird (d.h.
nach dem Übergang von der Initrd zum Rechner), dann ist sie auf »0« gesetzt. Diese
Umgebungsvariable wird nur für Systemgeneratoren gesetzt.

$SYSTEMD_FIRST_BOOT
Falls dieser Systemstartzyklus als »erster Systemstart« betrachtet wird, dann wird sie
auf »1« gesetzt. Falls es ein nachfolgender, regulärer Systemstart ist, ist sie auf
»0« gesetzt. Siehe die Dokumentation von ConditionFirstBoot= in systemd.unit(5) für
Details. Diese Umgebungsvariable wird nur für Systemgeneratoren gesetzt.

$SYSTEMD_VIRTUALIZATION
Falls der Diensteverwalter in einer virtualisierten Umgebung ausgeführt wird, dann
wird $SYSTEMD_VIRTUALIZATION auf ein Paar von Zeichenketten gesetzt, getrennt durch
einen Doppelpunkt. Die erste Zeichenkette ist entweder »vm« oder »container«; dies
kategorisiert die Art der Virtualisierung. Die zweite Zeichenkette identifiziert die
Implementierung der Virtualisierungstechnik. Falls keine Virtualisierung erkannt
wurde, wird diese Variable nicht gesetzt. Diese Daten sind identisch zu dem, was
systemd-detect-virt(1) erkennt und berichten und verwenden das gleiche Vokabular wie
Virtualisierungsimplementierungskennzeichner.

$SYSTEMD_ARCHITECTURE
Diese Variable ist auf einen kurzen Kennzeichner der berichteten Architektur des
Systems gesetzt. Siehe die Dokumentation von ConditionArchitecture= in systemd.unit(5)
für Details über definierte Werte.

HINWEISE ZUM SCHREIBEN VON GENERATOREN

• Alle Generatoren werden parallel ausgeführt. Das bedeutet, alle Programme werden genau
zur gleichen Zeit gestartet und müssen mit dieser Parallelisierung umgehen können.

• Generatoren laufen sehr früh beim Systemstart und können sich nicht auf irgendeinen
externen Dienst verlassen. Sie dürfen mit keinem anderen Prozess kommunizieren. Dies
betrifft einfache Dinge wie die Protokollierung nach syslog(3) oder systemd selbst
(dies heißt: kein systemctl(1))! Nicht grundlegende Dateisysteme wie /var/ und /home/
werden nach dem Lauf der Generatoren eingehängt. Allerdings können sich die
Generatoren darauf verlassen, dass die grundlegendsten Kernelfunktionalitäten
vorhanden sind, sowie eingehängte /sys/-, /proc/-, /dev/-, /usr/- und
/run/-Dateisysteme.

• Von Generatoren geschriebene Units werden entfernt, wenn die Konfiguration neu geladen
wird. Das heißt, die Lebensdauer der generierten Units hängt eng mit den Neuladezyklen
von systemd selbst zusammen.

• Generatoren sollten nur zur Generierung von Unit-Dateien, .d/*.conf-Ergänzungen für
sie und Symlinks darauf verwandt werden, nicht für andere Arten von Konfiguration ohne
Bezug zur Unit. Aufgrund der oben erwähnten Lebenszykluslogik sind Generatoren für die
dynamische Konfiguration von anderen Diensten unpassend. Falls Sie dynamische
Konfiguration für andere Dienste generieren müssen, erledigen Sie dies in normalen
Diensten, die Sie vor dem in Frage kommenden Dienst anweisen.

Beachten Sie, dass mittels der Einstellungen StandardInputData=/StandardInputText= von
Dienste-Unit-Dateien (siehe systemd.exec(5)) es möglich ist, beliebige Eingabedaten
(einschließlich Daemon-spezifischer Konfiguration) als Teil der Unit-Definition zu
formulieren, was oft ausreicht, um Daten oder Konfiguration für andere Programme auf
eine natürlich Weise in die Unit-Dateien einzubetten.

• Da syslog(3) nicht verfügbar ist (siehe oben), müssen Protokollmeldungen stattdessen
nach /dev/kmsg geschrieben werden.

• Der Generator sollte immer seinen eigenen Namen in einem Kommentar am Anfang der
erstellten Datei einbinden, so dass der Benutzer leicht herausfinden kann, welche
Komponente eine bestimmte Unit erstellte oder ergänzte.

Die Anweisung SourcePath= sollte in erstellten Dateien verwandt werden, um die
Quellkonfigurationsdatei, aus der die Unit erstellt wurde, anzugeben. Damit verstehen
die Benutzer die Dinge leichter und dies hat auch den Vorteil, dass Systemd den
Benutzer bezüglich Konfigurationsdateien, die sich auf Platte verändert haben, aber
noch nicht von Systemd gelesen wurden, warnen kann. Der Wert SourcePath= muss keine
Datei in einem physischen Dateisystem sein. Im häufigen Beispiel, dass der Generator
nach einer Kernelbefehlszeile sucht, sollte SourcePath=/proc/cmdline verwandt werden.

• Generatoren dürfen dynamische Unit-Dateien schreiben oder mit den normalen Symlinks
.wants/ oder .requires/ Unit-Dateien in andere Unit-Dateien einhängen. Oft ist es es
besser, einfach eine Instanz einer Vorlagen-Unit-Datei aus /usr/ mit einem Generator
zu erzeugen, statt komplett dynamische Unit-Dateien zu schreiben. Natürlich
funktioniert dies nur, falls ein einzelner Parameter verwandt werden soll.

• Falls Sie vorsichtig sind, können Sie Generatoren in Shell-Skripten implementieren.
Wir empfehlen allerdings C-Code, da Generatoren synchron ausgeführt werden und daher
den Systemstart verzögern können, falls sie langsam sind.

• Bezüglich der Semantik beim Außer-Kraft-Setzen: Es gibt zwei Regeln, denen wir zu
folgen versuchen, wenn wir über die Semantik beim Außer-Kraft-Setzen nachdenken:

1. Benutzerkonfiguration sollte die Lieferantenkonfiguration außer Kraft setzen. Das
bedeutet (hauptsächlich), dass Zeug aus /etc/ Zeug aus /usr/ außer Kraft setzen
sollte.

2. Native Konfiguration sollte nicht native Konfiguration außer Kraft setzen. Das
bedeutet (hauptsächlich), dass von Ihnen generiertes Zeug niemals native
Unit-Dateien für den gleichen Zweck außer Kraft setzen sollte.

Von diesen Regeln ist die erste die wichtigere und bricht manchmal die zweite. Daher
sollte die Vorgabewahl bei der Entscheidung, ob Sie argv[1], argv[2] oder argv[3]
verwenden, wahrscheinlich argv[1] sein.

• Statt jetzt loszulegen und alle möglichen Arten von Generatoren für veraltete
Konfigurationsdateiformate zu schreiben, denken Sie bitte zwei Mal nach! Es ist oft
besser, das alte Zeug als veraltet zu markieren, statt es künstlich am Leben zu
erhalten.

BEISPIELE

       Beispiel 1. systemd-fstab-generator

       systemd-fstab-generator(8) konvertiert /etc/fstab in native Einhänge-Units. Es verwendet
       argv[1] als Ablageort der generierten Unit-Dateien, um dem Benutzer zu erlauben,
       /etc/fstab mit seinen eigenen nativen Unit-Dateien außer Kraft zu setzen, aber um auch
       sicherzustellen, dass /etc/fstab jede Lieferantenvorgabe aus /usr/ außer Kraft setzt.

       Nach der Bearbeitung von /etc/fstab sollte der Benutzer systemctl daemon-reload aufrufen.
       Dies wird alle Generatoren erneut ausführen und systemd veranlassen, alle Units von Platte
       neu zu laden. Um tatsächlich neue Verzeichnisse zu Fstab hinzuzufügen, können systemctl
       start /Pfad/zum/Einhängepunkt oder systemctl start local-fs.target verwandt werden.

       Beispiel 2. systemd-system-update-generator

       systemd-system-update-generator(8) leitet default.target temporär auf system-update.target
       um, falls eine Systemaktualisierung angesetzt ist. Da dies die
       Vorgabebenutzerkonfiguration für default.target außer Kraft setzen muss, verwendet es
       argv[2]. Für Details zu dieser Logik lesen Sie bitte systemd.offline-updates(7).

       Beispiel 3. Fehlersuche in einem Generator

           dir=$(mktemp -d)
           SYSTEMD_LOG_LEVEL=debug /lib/systemd/system-generators/systemd-fstab-generator \
                   "$dir" "$dir" "$dir"
           find $dir

SIEHE AUCH

       systemd(1), systemd-cryptsetup-generator(8), systemd-debug-generator(8),
       systemd-fstab-generator(8), fstab(5), systemd-getty-generator(8),
       systemd-gpt-auto-generator(8), systemd-hibernate-resume-generator(8),
       systemd-rc-local-generator(8), systemd-system-update-generator(8),
       systemd-sysv-generator(8), systemd-xdg-autostart-generator(8), systemd.unit(5),
       systemctl(1), systemd.environment-generator(7)

ÜBERSETZUNG

       Die deutsche Übersetzung dieser Handbuchseite wurde von Helge Kreutzmann
       <debian@helgefjell.de> erstellt.

       Diese Übersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License
       Version 3 ⟨https://www.gnu.org/licenses/gpl-3.0.html⟩ oder neuer bezüglich der Copyright-
       Bedingungen. Es wird KEINE HAFTUNG übernommen.

       Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-
       Mail an die Mailingliste der Übersetzer ⟨debian-l10n-german@lists.debian.org⟩.