SYSTEMD.GENERATOR(7) systemd.generator SYSTEMD.GENERATOR(7) BEZEICHNUNG systemd.generator - Systemd Unit-Generatoren UBERSICHT /Pfad/zum/Generator normales-Verz [fruhes-Verz] [spates-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 aufgefuhrten Verzeichnissen befinden. systemd(1) fuhrt diese Programme sehr fruh beim Systemstart und zum Zeitpunkt des Neuladens der Konfiguration aus, -- bevor Unit-Dateien geladen werden. Ihr Hauptzweck besteht in der Umwandlung von Konfigurations- und Ausfuhrungs-Kontextparametern, die fur den Dienste-Verwalter nicht nativ sind, in dynamisch erstellte Unit-Dateien, Symlinks oder Unit-Erganzungsdateien, so dass sie die Unit-Datei-Hierarchie des Diensteverwalters, auf dem er nachfolgend ladt und agiert, erweitern konnen. systemd ruft jeden Generator wird mit drei Verzeichnispfaden, die fur die Ausgabe der Generatoren verwandt werden, auf. In diesen drei Verzeichnissen durfen Generatoren Unit-Dateien (regulare, Instanzen sowie Vorlagen) und fur .d-Verzeichnisse fur Unit-Erganzungsdateien erstellen und symbolische Links auf Unit-Dateien erstellen, um zusatzliche Abhangigkeiten 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 ausser Kraft zu setzen. Zu Testzwecken konnen 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 Prioritat: /generator.early hat hohere Prioritat als die Administratorkonfiguration in /etc/, wahrend /generator eine niedrigere Prioritat als /etc/, aber eine hohere als die der Lieferantenkonfiguration in /usr/ hat. /generator.late hat eine niederigere Prioritat als alle anderen Konfigurationen. Siehe den nachsten Abschnitt und die Diskussion von Unit-Ladepfaden und Unit-Ausserkraftsetzungen in systemd.unit(5). Generatoren werden aus einer Gruppe von Pfaden, wie oben aufgefuhrt, die wahrend der Ubersetzung 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, ausser Kraft. Ein Symlink auf /dev/null oder eine leere Datei kann zum Ausmaskieren eines Generators verwandt und damit dessen Ausfuhrung verhindert werden. Bitte beachten Sie, dass die Reihenfolge der zwei Verzeichnisse mit der hochsten Prioritat in Hinblick auf den Unit-Ladepfad invertiert ist und dass Generatoren in /run/ solche in /etc/ ausser Kraft setzen. Nach der Installation neuer Generatoren oder der Aktualisierung der Konfiguration darf systemctl daemon-reload ausgefuhrt werden. Dies loscht die vorherige, von den Generatoren erstellte Konfiguration, fuhrt alle Generatoren erneut aus und fuhrt dazu, dass systemd alle Units von Platte neu ladt. Siehe systemctl(1) fur weitere Informationen. AUSGABEVERZEICHNISSE Generatoren werden mit drei Argumenten aufgerufen: Pfade zu Verzeichnissen, in denen Generatoren ihre erstellten Unit-Dateien oder Symlinks ablegen konnen. Standardmassig 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 fur 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. fruhes-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/ ausser 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. spates-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 ausser Kraft zu setzen. Jede vom Lieferanten oder vom Benutzer/Administrator bereitgestellte native Konfigurationsdatei hat Vorrang. Hinweis: Generatoren durfen nicht an andere Orte schreiben oder andere Anderungen am Systemzustand vornehmen. Die Ausgabe von Generatoren sollte nur bis zum nachsten 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 uber den Ausfuhrungskontext 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. Hinzugefugt in Version 251. $SYSTEMD_IN_INITRD Falls der Generator als Teil der Initrd ausgefuhrt wird, ist sie auf >>1<< gesetzt. Falls sie vom regularen Rechner ausgefuhrt wird (d.h. nach dem Ubergang von der Initrd zum Rechner), dann ist sie auf >>0<< gesetzt. Diese Umgebungsvariable wird nur fur Systemgeneratoren gesetzt. Hinzugefugt in Version 251. $SYSTEMD_FIRST_BOOT Falls dieser Systemstartzyklus als >>erster Systemstart<< betrachtet wird, dann wird sie auf >>1<< gesetzt. Falls es ein nachfolgender, regularer Systemstart ist, ist sie auf >>0<< gesetzt. Siehe die Dokumentation von ConditionFirstBoot= in systemd.unit(5) fur Details. Diese Umgebungsvariable wird nur fur Systemgeneratoren gesetzt. Hinzugefugt in Version 251. $SYSTEMD_VIRTUALIZATION Falls der Diensteverwalter in einer virtualisierten Umgebung ausgefuhrt 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. Hinzugefugt 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) fur Details uber definierte Werte. Hinzugefugt 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 verschlusselter Form hereingereicht wurden, werden in $ENCRYPTED_CREDENTIALS_DIRECTORY abgelegt. Verwenden Sie den Befehl systemd-creds(1), um hereingereichte Zugangsberechtigungen bei Bedarf zu ver-/entschlusseln. Verwenden Sie insbesondere den Befehl systemd-creds --system cat. Hinzugefugt in Version 254. $SYSTEMD_CONFIDENTIAL_VIRTUALIZATION Falls der Diensteverwalter in einer vertraulichen virtualisierten Umgebung ausgefuhrt 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. Hinzugefugt in Version 254. HINWEISE ZUM SCHREIBEN VON GENERATOREN o Alle Generatoren werden parallel ausgefuhrt. Das bedeutet, alle Programme werden genau zur gleichen Zeit gestartet und mussen mit dieser Parallelisierung umgehen konnen. o Generatoren laufen sehr fruh beim Systemstart und konnen sich nicht auf irgendeinen externen Dienst verlassen. Sie durfen mit keinem anderen Prozess kommunizieren. Dies betrifft einfache Dinge wie die Protokollierung nach syslog(3) oder systemd selbst (dies heisst: kein systemctl(1))! Nicht grundlegende Dateisysteme wie /var/ und /home/ werden nach dem Lauf der Generatoren eingehangt. Allerdings konnen sich die Generatoren darauf verlassen, dass die grundlegendsten Kernelfunktionalitaten vorhanden sind, sowie eingehangte /sys/-, /proc/-, /dev/-, /usr/- und /run/-Dateisysteme. o Von Generatoren geschriebene Units werden entfernt, wenn die Konfiguration neu geladen wird. Das heisst, die Lebensdauer der generierten Units hangt eng mit den Neuladezyklen von systemd selbst zusammen. o Generatoren sollten nur zur Generierung von Unit-Dateien, .d/*.conf-Erganzungen fur sie und Symlinks darauf verwandt werden, nicht fur andere Arten von Konfiguration ohne Bezug zur Unit. Aufgrund der oben erwahnten Lebenszykluslogik sind Generatoren fur die dynamische Konfiguration von anderen Diensten unpassend. Falls Sie dynamische Konfiguration fur andere Dienste generieren mussen, 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 moglich ist, beliebige Eingabedaten (einschliesslich Daemon-spezifischer Konfiguration) als Teil der Unit-Definition zu formulieren, was oft ausreicht, um Daten oder Konfiguration fur andere Programme auf eine naturlich Weise in die Unit-Dateien einzubetten. o Da syslog(3) nicht verfugbar ist (siehe oben), mussen Protokollmeldungen stattdessen nach /dev/kmsg geschrieben werden. o 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 erganzte. 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 bezuglich Konfigurationsdateien, die sich auf Platte verandert haben, aber noch nicht von Systemd gelesen wurden, warnen kann. Der Wert SourcePath= muss keine Datei in einem physischen Dateisystem sein. Im haufigen Beispiel, dass der Generator nach einer Kernelbefehlszeile sucht, sollte SourcePath=/proc/cmdline verwandt werden. o Generatoren durfen dynamische Unit-Dateien schreiben oder mit den normalen Symlinks .wants/ oder .requires/ Unit-Dateien in andere Unit-Dateien einhangen. 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. Naturlich funktioniert dies nur, falls ein einzelner Parameter verwandt werden soll. o Falls Sie vorsichtig sind, konnen Sie Generatoren in Shell-Skripten implementieren. Wir empfehlen allerdings C-Code, da Generatoren synchron ausgefuhrt werden und daher den Systemstart verzogern konnen, falls sie langsam sind. o Bezuglich der Semantik beim Ausser-Kraft-Setzen: Es gibt zwei Regeln, denen wir zu folgen versuchen, wenn wir uber die Semantik beim Ausser-Kraft-Setzen nachdenken: 1. Benutzerkonfiguration sollte die Lieferantenkonfiguration ausser Kraft setzen. Das bedeutet (hauptsachlich), dass Zeug aus /etc/ Zeug aus /usr/ ausser Kraft setzen sollte. 2. Native Konfiguration sollte nicht native Konfiguration ausser Kraft setzen. Das bedeutet (hauptsachlich), dass von Ihnen generiertes Zeug niemals native Unit-Dateien fur den gleichen Zweck ausser 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. o Statt jetzt loszulegen und alle moglichen Arten von Generatoren fur veraltete Konfigurationsdateiformate zu schreiben, denken Sie bitte zwei Mal nach! Es ist oft besser, das alte Zeug als veraltet zu markieren, statt es kunstlich am Leben zu erhalten. BEISPIELE Beispiel 1. systemd-fstab-generator systemd-fstab-generator(8) konvertiert /etc/fstab in native Einhange-Units. Es verwendet argv[1] als Ablageort der generierten Unit-Dateien, um dem Benutzer zu erlauben, /etc/fstab mit seinen eigenen nativen Unit-Dateien ausser Kraft zu setzen, aber um auch sicherzustellen, dass /etc/fstab jede Lieferantenvorgabe aus /usr/ ausser Kraft setzt. Nach der Bearbeitung von /etc/fstab sollte der Benutzer systemctl daemon-reload aufrufen. Dies wird alle Generatoren erneut ausfuhren und systemd veranlassen, alle Units von Platte neu zu laden. Um tatsachlich neue Verzeichnisse zu Fstab hinzuzufugen, konnen systemctl start /Pfad/zum/Einhangepunkt oder systemctl start local-fs.target verwandt werden. Beispiel 2. systemd-system-update-generator systemd-system-update-generator(8) leitet default.target temporar auf system-update.target um, falls eine Systemaktualisierung angesetzt ist. Da dies die Vorgabebenutzerkonfiguration fur default.target ausser Kraft setzen muss, verwendet es argv[2]. Fur 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) UBERSETZUNG Die deutsche Ubersetzung dieser Handbuchseite wurde von Helge Kreutzmann erstellt. Diese Ubersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 3 oder neuer bezuglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG ubernommen. Wenn Sie Fehler in der Ubersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an die Mailingliste der Ubersetzer . systemd 255 SYSTEMD.GENERATOR(7)