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 solche 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 nicht nativer Konfiguration in dynamisch erstellte Unit-Dateien.

       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 Teildateien für .d-Verzeichnisse 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.

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, darunter ein eingehängtes /sys, /proc, /dev, /usr.

       •   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 und Symlinks darauf verwandt werden, nicht
           für andere Arten von Konfiguration. 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.

       •   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, festzulegen. 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.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 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
       <debian-l10n-german@lists.debian.org>.

systemd 243                                                                                 SYSTEMD.GENERATOR(7)