Provided by: manpages-de_2.14-1_all bug

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.

       ·   Es ist eine gute Idee, die Anweisung SourcePath= in generierten Unit-Dateien zu
           verwenden, um die Quellkonfigurationsdatei, aus der Sie die Unit generieren,
           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.

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