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/*
       /usr/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 /usr/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.

systemd ruft jeden Generator wird mit drei Verzeichnispfaden, die für die Ausgabe der Generatoren
verwandt werden, auf. 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. Diese Units sind im Unit-Ladepfad enthalten, und erlauben damit der erstellten
Konfiguration, bestehende Definitionen zu erweitern oder außer Kraft zu setzen. Zu Testzwecken können die
Generatoren mit nur einem Argument aufgerufen wernden; in diesem Falle sollte der Generator annehmen,
dass alle drei Pfade identisch sind.

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. Falls nur ein Argument bereitgestellt wird, sollte der
Generator das gleiche Verzeichnis für alle drei Ausgabepfade verwenden.

1. normales-Verz

Bei normaler Verwendung ist dies /run/systemd/generator im Falle von Systemgeneratoren und
$XDG_RUNTIME_DIR/systemd/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/systemd/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/systemd/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.

Hinweis: Generatoren dürfen nicht an andere Orte schreiben oder andere Änderungen am Systemzustand
vornehmen. Die Ausgabe von Generatoren sollte nur bis zum nächsten daemon-reload oder daemon-reexec
wirken; falls der Generator ersetzt oder maskiert wird, sollte seine Auswirkung verschwinden.

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.

Hinzugefügt in Version 251.

$SYSTEMD_IN_INITRD
Falls der Generator als Teil der 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.

Hinzugefügt in Version 251.

$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.

Hinzugefügt in Version 251.

$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.

Hinzugefügt in Version 251.

$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.

Hinzugefügt in Version 251.

$CREDENTIALS_DIRECTORY, $ENCRYPTED_CREDENTIALS_DIRECTORY
Falls gesetzt bezieht es sich auf das Verzeichnissystem, in dem die Zugangsberechtigungen abgelegt
wurden. Zugangsberechtigungen, die in das System im Klartext hineingereicht wurden, werden in
$CREDENTIALS_DIRECTORY abgelegt und solche, die in verschlüsselter Form hereingereicht wurden, werden
in $ENCRYPTED_CREDENTIALS_DIRECTORY abgelegt. Verwenden Sie den Befehl systemd-creds(1), um
hereingereichte Zugangsberechtigungen bei Bedarf zu ver-/entschlüsseln. Verwenden Sie insbesondere
den Befehl systemd-creds --system cat.

Hinzugefügt in Version 254.

$SYSTEMD_CONFIDENTIAL_VIRTUALIZATION
Falls der Diensteverwalter in einer vertraulichen virtualisierten Umgebung ausgeführt wird, dann wird
$SYSTEMD_CONFIDENTIAL_VIRTUALIZATION auf eine Zeichenkette gesetzt, die die vertrauliche
Virtualisierungshardwaretechnik identifiziert. Falls keine vertrauliche 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 vertrauliche
Virtualisierungstechnikkennzeichner.

Hinzugefügt in Version 254.

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 /usr/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⟩.