SYSTEMD.UNIT(5) systemd.unit SYSTEMD.UNIT(5) BEZEICHNUNG systemd.unit - Unit-Konfiguration UBERSICHT Dienst.service, Socket.socket, Gerat.device, Einhangung.mount, Selbsteinhangung.automount, Auslagerung.swap, Ziel.target, Pfad.path, Timer.timer, Scheibe.slice, Bereich.scope System-Unit-Suchpfad /etc/systemd/system.control/* /run/systemd/system.control/* /run/systemd/transient/* /run/systemd/generator.early/* /etc/systemd/system/* /etc/systemd/system.attached/* /run/systemd/system/* /run/systemd/system.attached/* /run/systemd/generator/* /usr/lib/systemd/system/* /run/systemd/generator.late/* Benutzer-Unit-Suchpfad ~/.config/systemd/user.control/* $XDG_RUNTIME_DIR/systemd/user.control/* $XDG_RUNTIME_DIR/systemd/transient/* $XDG_RUNTIME_DIR/systemd/generator.early/* ~/.config/systemd/user/* $XDG_CONFIG_DIRS/systemd/user/* /etc/systemd/user/* $XDG_RUNTIME_DIR/systemd/user/* /run/systemd/user/* $XDG_RUNTIME_DIR/systemd/generator/* $XDG_DATA_HOME/systemd/user/* $XDG_DATA_DIRS/systemd/user/* /usr/lib/systemd/user/* $XDG_RUNTIME_DIR/systemd/generator.late/* BESCHREIBUNG Eine Unit-Konfigurationsdatei ist eine reine Textdatei im Ini-Format, die Informationen uber einen Dienst, ein Socket, ein Gerat, einen Einhangepunkt, einen Selbsteinhangepunkt, eine Auslagerungsdatei oder -partition, ein Startziel, einen uberwachten Dateipfad, einen von systemd(1) gesteuerten und uberwachten Timer, eine Ressourcenverwaltungsscheibe oder eine Gruppe von extern erstellten Prozessen kodiert. Siehe systemd.syntax(7) fur eine allgemeine Beschreibung der Syntax. Diese Handbuchseite fuhrt die gemeinsamen Konfigurationsoptionen aller Unit-Typen auf. Diese Optionen mussen in den Abschnitten [Unit] oder [Install] der Unit-Dateien konfiguriert werden. Zusatzlich zu den hier beschriebenen generischen Abschnitten [Unit] und [Install] kann jede Unit einen typspezifischen Abschnitt haben, z.B. [Service] fur eine Dienste-Unit. Siehe die respektiven Handbuchseiten fur weitere Informationen: systemd.service(5), systemd.socket(5), systemd.device(5), systemd.mount(5), systemd.automount(5), systemd.swap(5), systemd.target(5), systemd.path(5), systemd.timer(5), systemd.slice(5), systemd.scope(5). Unit-Dateien werden von einer Reihe von Pfaden, die wahrend der Compilierung bestimmt werden, geladen. Dies wird im nachsten Abschnitt beschrieben. Gultige Unit-Namen bestehen aus einen >>Unit-Namensvorsatz<< und einer Endung, die den Unit-Typ festlegt und mit einem Punkt beginnt. Der >>Unit-Namenvorsatz<< muss aus einem oder mehreren gultigen Zeichen (ASCII-Buchstaben, Ziffern, >>:<<, >>-<<, >>_<<, >>.<< und >>\<< bestehen). Die Gesamtlange des Unit-Names einschliesslich der Endung darf 255 Zeichen nicht uberschreiten. Die Unit-Typ-Endung muss entweder >>.service<<, >>.socket<<, >>.device<<, >>.mount<<, >>.automount<<, >>.swap<<, >>.target<<, >>.path<<, >>.timer<<, >>.slice<< oder >>.scope<< sein. Unit-Namen konnen durch einen einzelnen Parameter, genannt >>Instanzenname<<, parametrisiert werden. Die Unit wird dann, basierend auf einer >>Vorlagendatei<<, die als Definition mehrerer Dienste oder anderer Units dient, konstruiert. Eine Vorlagendatei muss ein einzelnes >>@<< am Ende des Unit-Namenvorsatzes haben (direkt vor der Typendung). Der Name der kompletten Unit wird durch Einfugung des Instanzennamens zwischen dem @ und der Unit-Typendung gebildet. In der Unit-Datei selbst kann auf den Instanzenparameter mittels >>%i<< und anderen Kennzeichnern Bezug genommen werden, siehe unten. Unit-Dateien durfen zusatzliche zu den hier aufgefuhrten Optionen enthalten. Falls Systemd auf eine unbekannte Option stosst, wird es eine Warnprotokollnachricht schreiben, aber mit dem Laden der Unit fortfahren. Falls vor einer Option oder einem Abschnittnamen ein X- steht, wird diese(r) von Systemd komplett ignoriert. Optionen innerhalb eines ignorierten Abschnittes benotigen die vorangestellte Kennung nicht. Anwendungen konnen dies dazu verwenden, zusatzliche Informationen in den Unit-Dateien aufzunehmen. Um auf diese Optionen zuzugreifen, mussen Anwendungen die Unit-Dateien selbst auswerten. Aliase (alternative Namen) konnen fur Units angelegt werden, indem ein Symlink vom neuen Namen auf den alten Namen in einem der Unit-Suchpfade angelegt wird Beispielsweise hat systemd-networkd.service den Alias dbus-org.freedesktop.network1.service, der wahrend der Installation als ein Symlink erstellt wird, so dass systemd auf die Anfrage uber D-Bus, dbus-org.freedesktop.network1.service zu laden, systemd-networkd.service laden wird. Als weiteres Beispiel ist default.target -- das Standard-Systemziel, was beim Systemstart gestartet wird -- oft uber einen Alias mit entweder multi-user.target oder graphical.target verbunden, um auszuwahlen, was standardmassig gestartet wird. Aliasnamen konnen in Befehlen wie disable, start, stop, status und ahnlichen und in allen Unit-Abhangigkeitsanweisungen einschliesslich Wants=, Requires=, Before=, After= verwandt werden. Aliase konnen nicht mit dem Befehl preset verwandt werden. Alias unterliegen den folgenden Beschrankungen: Eine Unit eines bestimmten Typs (>>.service<<, >>.socket<<, ) kann nur ein Alias auf einen Namen mit der gleichen Typendung werden. Eine einfache Unit (keine Vorlage oder Instanz) darf nur ein Alias auf einen einfachen Namen werden. Eine Vorlageninstanz darf nur durch eine andere Vorlageninstanz einen Alias erhalten und der Instanzanteil muss identisch sein. Eine Vorlage darf durch eine andere Vorlage einen Alias erhalten (dann gilt der Alias fur alle Instanzen der Vorlage). Eine Vorlageninstanz (z.B. >>alias@inst.service<<) darf als Spezialfall ein Symlink auf eine andere Vorlage sein (z.B. >>template@inst.service<<). In diesem Fall wird nur fur diese spezielle Instanz ein Alias angelegt, wahrend andere Instanzen dieser Vorlage (z.B. >>alias@foo.service<<, >>alias@bar.service<<) keinen Alias erhalten. Diese Regeln erhalten die Anforderung, dass die Instanz (falls vorhanden) immer eindeutig fur eine gegebene Unit und alle ihre Aliase definiert ist. Das Ziel des Alias-Symlinks muss auf einen gultigen Unit-Dateiort zeigen, d.h. der Symlink-Zieldateiname muss wie beschrieben auf den Symlink-Quellnamen passen und der Zielpfad muss in einem der Unit-Suchpfade sein, siehe nachfolgenden UNIT-DATEI-LADEPFAD fur weitere Details. Beachten Sie, dass die Zieldatei nicht existieren konnte, d.h. der Symlink hangen konnte. Zusatzlich konnen Unit-Dateien Aliase mittels der Anweisung Alias= im Abschnitt [Install] festlegen. Wenn die Unit aktiviert ist, werden Symlinks fur diese Namen erstellt und wieder entfernt, wenn die Unit deaktiviert wird. Beispielsweise legt reboot.target Alias=ctrl-alt-del.target so fest, dass der Symlink /etc/systemd/system/ctrl-alt-del.service auf die Datei reboot.target bei der Aktivierung erstellt wird und wenn Strg-Alt-Entf gedruckt wird, systemd nach ctrl-alt-del.service suchen und reboot.service ausfuhren wird. systemd schaut wahrend des normalen Betriebs uberhaupt nicht in den Abschnitt [Install], daher haben samtliche Direktiven in diesem Abschnitt nur durch wahrend der Aktivierung erstellte Symlinks eine Wirkung. Das Verzeichnis foo.service.wants/ kann zusammen mit der Unit-Datei foo.service existieren. Alle Unit-Dateien, die von so einem Verzeichnis mittels Symlink verknupft sind, werden implizit als Abhangigkeiten vom Typ Wants= fur die Unit hinzugefugt. Eine ahnliche Funktionalitat existiert auch fur Abhangigkeiten vom Typ Requires=, die Verzeichnisendung ist in diesem Fall .requires/. Diese Funktionalitat ist nutzlich, um Units in den Start von anderen Units einzuhangen, ohne ihre Unit-Dateien zu verandern. Fur Details uber die Semantik von Wants= und Requires= siehe unten. Die bevorzugte Art, Symlinks in den Verzeichnissen .wants/ oder .requires/ erfolgt durch die Angabe der Abhangigkeit in dem Abschnitt [Install] der Ziel-Unit und Erstellung des Symlinks im Dateisystem mittels des Befehls enable oder preset von systemctl(1). Das Ziel kann eine normale Unit sein (entweder einfach oder durch eine bestimmte Instanz einer Vorlagen-Unit). Falls die Quell-Unit eine Vorlage ist, kann die Ziel-Unit auch eine Vorlage sein, dann wird die Instanz zu der Ziel-Unit >>weitergeleitet<<, um eine gultige Unit-Instanz zu bilden. Das Ziel von Symlinks in .wants/ oder .requires/ muss daher auf einen gultigen Unit-Dateiort zeigen, d.h. der Symlink-Zielname muss die beschriebenen Anforderungen erfullen und der Zielpfad muss in einem der Unit-Suchpfade liegen, siehe nachfolgenden UNIT-DATEI-LADEPFAD fur weitere Details. Beachten Sie, dass die Zieldatei nicht existieren konnte, d.h. der Symlink hangen konnte. Zusammen mit einer Unit-Datei foo.service kann ein >>Erganzungs<<-Verzeichnis foo.service.d/ existieren. Alle Dateien mit der Endung >>.conf<< aus diesem Verzeichnis in alphanumerischer Reihenfolge zusammengefuhrt und ausgewertet, nachdem die Unit-Datei selbst ausgewertet wurde. Dies ist nutzlich, um die Konfigurationseinstellungen fur eine Unit zu verandern oder zu erganzen, ohne die Unit-Dateien selbst verandern zu mussen. Jede Erganzungsdatei muss geeignete Abschnittskopfzeilen enthalten. Fur instanziierte Units wird diese Logik zuerst nach dem Instanzen-Unterverzeichnis >>.d/<< (z.B. >>foo@bar.service.d/<<) schauen und dessen >>.conf<<-Dateien lesen, gefolgt von dem Vorlagenunterverzeichnis >>.d/<< (z.B. >>foo@.service.d/<<) und den >>.conf<<-Dateien dort. Fur Unit-Namen, die desweiteren Bindestriche (>>-<<) enthalten, wird die Menge der Verzeichnisse, die durch wiederholtes Abschneiden des Unit-Namens nach allen Bindestrichen entsteht, auch durchsucht. Insbesondere wird fur einen Unit-Namen foo-bar-baz.service.d/ sowohl foo-bar-.service.d/ als auch foo-.service.d/ durchsucht. Dies ist nutzlich, um gemeinsame Erganzungen fur eine Gruppe von zusammengehorigen Units zu definieren, deren Namen mit einem gemeinsamen Anfang beginnen. Dieses Schema ist insbesondere fur Einhange-, Automount- und Scheiben-Units, deren systematische Benennungsstruktur rund um Bindestriche als Komponententrenner aufgebaut ist, nutzlich. Beachten Sie, dass gleichbenannte Erganzungsdateien weiter unten in der Anfangshierarchie solche weiter oben ausser Kraft setzen, d.h. foo-bar-.service.d/10-override.conf setzt foo-.service.d/10-override.conf ausser Kraft. Im Falle von (den oben beschriebenen) Unit-Aliasen, werden die Erganzungen fur die Aliasnamen und alle Aliasse geladen. Falls beispielsweise default.target ein Alias fur graphical.target ist, wurden default.target.d/, default.target.wants/, default.target.requires/, graphical.target.d/, graphical.target.wants/, graphical.target.requires/ alle gelesen. Fur Vorlagen werden die Erganzungen fur die Vorlage, alle Vorlagen-Aliasse, die Vorlageninstanz und alle Alias-Instanzen gelesen. Wird nur fur eine bestimmte Vorlageninstanz ein Alias angelegt, dann werden die Erganzungen fur die Zielvorlage, die Zielvorlageninstanz und die Alias-Vorlageninstanz gelesen. Zusatzlich zu /etc/systemd/system konnen Erganzungs->>.d/<<-Verzeichnisse in die Verzeichnisse /usr/lib/systemd/system oder /run/systemd/system abgelegt werden. Erganzungsdateien in /etc/ haben Vorrang vor denen in /run/, die wiederum Vorrang vor denen in /usr/lib/ haben. Erganzungsdateien unter all diesen Verzeichnissen haben Vorrang vor der Haupt-Netdev-Datei, wo auch immer sich diese befindet. Mehrere Erganzungsdateien mit verschiedenen Namen werden in lexikographischer Reihenfolge angewandt, unabhangig von dem Verzeichnis, in dem sie sich befinden. Units unterstutzen auch ein Erganzungs-Typ.d/-Verzeichnis auf oberster Ebene, wobei Typ z.B. >>service<< oder >>socket<< sein darf. Dies erlaubt es, die Einstellungen aller entsprechenden Unit-Dateien auf dem System zu verandern oder zu erganzen. Die Formatierung und die Vorrangregeln bei der Anwendung von Erganzungskonfigurationen folgen dem oben definiertem. Dateien in Typ.d/ haben niedrigeren Vorrang im Vergleich zu Dateien in namensspezifischen Ausserkraftsetzungsverzeichnissen. Es gelten die normalen Regeln: mehrere Erganzungsdateien mit verschiedenen Namen werden in lexikographischer Reihenfolge angewandt, unabhangig davon, in welchem Verzeichnis sie sich befinden, daher gilt eine Datei in Typ.d/ fur eine Unit nur, falls es keine Erganzung oder Maskierung mit diesem Namen in Verzeichnissen mit hoherem Vorrang gibt. Siehe Beispiele. Beachten Sie, dass Systemd zwar ein flexibles Abhangigkeitssystem zwischen Units bereitstellt, es aber empfohlen wird, diese Funktionalitat nur sparsam zu verwenden und stattdessen auf Techniken wie Bus-basierte oder Socket-basierte Aktivierung zu setzen, wodurch Abhangigkeiten implizit werden und damit sowohl ein einfacheres als auch flexibleres System entsteht. Wie oben erwahnt konnen Units von Vorlagendateien instanziiert werden. Dies erlaubt die Erstellung mehrere Units aus einer einzelnen Konfigurationsdatei. Falls Systemd nach einer Unit-Konfigurationsdatei schaut, wird es zuerst nach dem wortlichen Dateinamen in dem Dateisystem suchen. Falls das zu keinem Erfolg fuhrt und der Unit-Name das Zeichen >>@<< enthalt, wird Systemd nach einer Unit-Vorlage suchen, die auch den gleichen Namen hat, aber mit einer entfernten Instanzzeichenkette (d.h. der Teil zwischen dem >>@<<-Zeichen und der Endung entfernt). Beispiel: Falls ein Dienst getty@tty3.service angefragt wird und keine Datei mit diesem Namen gefunden wird, dann wird Systemd nach getty@.service suchen und einen Dienst aus dieser Konfigurationsdatei instanziieren, falls sie gefunden wurde. Um sich innerhalb der Konfigurationsdatei auf die Instanziierungszeichenkette zu beziehen, konnen Sie den speziellen Kennzeichner >>%i<< in vielen Konfigurationsoptionen verwenden. Siehe unten fur Details. Falls eine Unit-Datei leer ist (d.h. die Grosse 0 hat) oder ein Symlink ist, der auf /dev/null zeigt, wird seine Konfiguration nicht geladen und sie erscheint mit einem Ladezustand >>masked<< und kann nicht aktiviert werden. Verwenden Sie dies als wirksame Methode, um eine Unit komplett zu deaktivieren und es somit unmoglich zu machen, sie sogar manuell zu starten. Das Unit-Dateiformat wird durch die Schnittstellenportabilitats- und -stabilitatszusage[1] abgedeckt. ZEICHENKETTENMASKIERUNG FUR DIE AUFNAHME IN UNIT-NAMEN Manchmal ist es nutzlich, eine beliebige Zeichenkette in Unit-Namen umzuwandeln. Um dies zu unterstutzen, wird eine Zeichenkettenmaskierungsmethode verwandt, um Zeichenketten, die beliebige Byte-Werte (ausser NUL) enthalten, in gultige Namen und ihren begrenzten Zeichensatz umzuwandeln. Ein haufiger Spezialfall sind Unit-Namen, die Pfade zu Objekten in der Dateisystemhierarchie widerspiegeln. Beispiel: eine Gerate-Unit dev-sda.device bezieht sich auf ein Gerat mit dem Gerateknoten /dev/sda in dem Dateisystem. Der Maskieralgorithmus funktioniert wie folgt: in einer gegebenen Zeichenkette wird jedes >>/<<-Zeichen durch >>-<< und alle anderen Zeichen ausser den alphanumerischen ASCII-Zeichen, >>:<<, >>_<< oder >>.<< werden durch ihr C-artige >>\x2d<<-Maskierung ersetzt. Wenn >>.<< als erstes Zeichen in der maskierten Zeichenkette auftauchen wurde, wird es zusatzlich mit seiner C-artigen Maskierung ersetzt. Wenn die Eingabe als absoluter Systempfad geeignet ist, wird dieser Algorithmus leicht erweitert: der Pfad zum Wurzelverzeichnis >>/<< wird als einzelner Bindestrich >>-<< kodiert. Zusatzlich werden alle fuhrenden, abschliessenden oder doppelten >>/<< Zeichen vor der Umwandlung aus der Zeichenkette entfernt. Beispiel: /foo//bar/baz/ wird >>foo-bar-baz<<. Diese Maskierung ist komplett umkehrbar, solange bekannt ist, ob die maskierte Zeichenkette ein Pfad war (die demaskierten Ergebnisse unterscheiden sich fur Pfad- und Nichtpfadzeichenketten). Verwenden Sie systemd-escape --path, um Pfade zu maskieren und andernfalls systemd-escape ohne --path. AUTOMATISCHE ABHANGIGKEITEN Implizite Abhangigkeiten Eine Reihe von Unit-Abhangigkeiten werden implizit aufgebaut, abhangig vom Unit-Typ und der Unit-Konfiguration. Diese impliziten Abhangigkeiten konnen die Unit-Konfiguration erleichtern. Bitte lesen Sie den Abschnitt >>Implizite Abhangigkeiten<< in der Handbuchseite des jeweiligen Unit-Typs. Beispielsweise erlangen Dienste-Units mit Type=dbus automatisch Abhangigkeiten vom Typ Requires= und After= von dbus.socket. Siehe systemd.service(5) fur Details. Standardabhangigkeiten Standardabhangigkeiten sind ahnlich impliziten Abhangigkeiten, konnen aber durch Setzen von DefaultDependencies= auf yes (die Vorgabe) und no an- und abgeschaltet werden, wahrend implizite Abhangigkeiten immer wirksam sind. Siehe Abschnitt >>Standard-Abhangigkeiten<< in den jeweiligen Handbuchseiten fur den Effekt der Aktivierung von DefaultDependencies= in jedem Unit-Typ. Beispielsweise werden Ziel-Units alle konfigurierten Abhangigkeiten des Typs Wants= oder Requires= mit Abhangigkeiten vom Typ After= erganzen. Siehe systemd.target(5) fur Details. Beachten Sie, dass dieses Verhalten durch Setzen von DefaultDependencies=no in den festgelegten Units abgewahlt werden kann. Es kann auch gezielt uber eine explizite Abhangigkeit Before= ausser Kraft gesetzt werden. UNIT-DATEI-LADEPFAD Unit-Dateien werden von einer Reihe von Pfaden geladen, die wahrend der Kompilierung bestimmt werden, wie dies in den zwei Tabellen unten beschrieben ist. Unit-Dateien, die in fruher aufgefuhrten Verzeichnissen gefunden werden, setzen Dateien mit dem gleichen Namen in Verzeichnissen, die weiter unten in der Liste aufgefuhrt sind, ausser Kraft. Wenn die Variable $SYSTEMD_UNIT_PATH gesetzt ist, setzt der Inhalt dieser Variable den Unit-Ladepfad ausser Kraft. Falls $SYSTEMD_UNIT_PATH mit einer leeren Komponente (>>:<<) endet, wird der normale Unit-Ladepfad an den Inhalt der Variablen angehangt. Tabelle 1. Ladepfad beim Betrieb im Systemmodus (--system). +------------------------------+----------------------------+ |Pfad | Beschreibung | +------------------------------+----------------------------+ |/etc/systemd/system.control | Mittels Dbus-API erstellte | | | dauerhafte und fluchtige | | | Konfiguration | +------------------------------+ | |/run/systemd/system.control | | +------------------------------+----------------------------+ |/run/systemd/transient | Dynamische Konfiguration | | | fur fluchtige Units | +------------------------------+----------------------------+ |/run/systemd/generator.early | Erstellte Units mit hoher | | | Prioritat (siehe early-dir | | | in systemd.generator(7)) | +------------------------------+----------------------------+ |/etc/systemd/system | System-Units, die vom | | | Administrator erstellt | | | wurden | +------------------------------+----------------------------+ |/run/systemd/system | Laufzeit-Units | +------------------------------+----------------------------+ |/run/systemd/generator | Erstellte Units mit | | | mittlerer Prioritat (siehe | | | normal-dir in | | | systemd.generator(7)) | +------------------------------+----------------------------+ |/usr/local/lib/systemd/system | System-Units, die vom | | | Administrator installiert | | | wurden | +------------------------------+----------------------------+ |/usr/lib/systemd/system | System-Units, die durch | | | den Paketverwalter der | | | Distribution installiert | | | wurden | +------------------------------+----------------------------+ |/run/systemd/generator.late | Erstellte Units mit | | | niedriger Prioritat (siehe | | | late-dir in | | | systemd.generator(7)) | +------------------------------+----------------------------+ Tabelle 2. Ladepfad bei der Ausfuhrung im Benutzermodus (--user). +-----------------------------------------+------------------------------------+ |Pfad | Beschreibung | +-----------------------------------------+------------------------------------+ |$XDG_CONFIG_HOME/systemd/user.control | Dauerhafte und fluchtige | |oder ~/.config/systemd/user.control | Konfiguration, die mittels des | | | DBus-APIs erstellt wird | | | (($XDG_CONFIG_HOME wird verwandt, | | | falls gesetzt, andernfalls | | | ~/.config) | +-----------------------------------------+ | |$XDG_RUNTIME_DIR/systemd/user.control | | +-----------------------------------------+------------------------------------+ |$XDG_RUNTIME_DIR/systemd/transient | Dynamische Konfiguration fur | | | fluchtige Units | +-----------------------------------------+------------------------------------+ |$XDG_RUNTIME_DIR/systemd/generator.early | Erstellte Units mit hoher | | | Prioritat (siehe early-dir in | | | systemd.generator(7)) | +-----------------------------------------+------------------------------------+ |$XDG_CONFIG_HOME/systemd/user oder | Benutzerkonfiguration | |$HOME/.config/systemd/user | ($XDG_CONFIG_HOME wird verwandt, | | | falls gesetzt, andernfalls | | | ~/.config) | +-----------------------------------------+------------------------------------+ |$XDG_CONFIG_DIRS/systemd/user oder | Zusatzliche | |/etc/xdg/systemd/user | Konfigurationsverzeichnisse, wie | | | diese durch die | | | XDG-Basisverzeichnis-Spezifikation | | | festgelegt werden | | | ($XDG_CONFIG_DIRS wird verwandt, | | | falls gesetzt, andernfalls | | | /etc/xdg) | +-----------------------------------------+------------------------------------+ |/etc/systemd/user | Benutzer-Units, die vom | | | Administrator erstellt wurden | +-----------------------------------------+------------------------------------+ |$XDG_RUNTIME_DIR/systemd/user | Laufzeit-Units (nur verwandt, | | | falls $XDG_RUNTIME_DIR gesetzt | | | ist) | +-----------------------------------------+------------------------------------+ |/run/systemd/user | Laufzeit-Units | +-----------------------------------------+------------------------------------+ |$XDG_RUNTIME_DIR/systemd/generator | Erstellte Units mit mittlerer | | | Prioritat (siehe normal-dir in | | | systemd.generator(7)) | +-----------------------------------------+------------------------------------+ |$XDG_DATA_HOME/systemd/user oder | Units von Paketen, die im | |$HOME/.local/share/systemd/user | Home-Verzeichnis installiert | | | wurden ($XDG_DATA_HOME wird | | | verwandt, falls gesetzt, | | | andernfalls ~/.local/share) | +-----------------------------------------+------------------------------------+ |$XDG_DATA_DIRS/systemd/user oder | Zusatzliche Datenverzeichnisse, | |/usr/local/share/systemd/user und | wie diese durch die | |/usr/share/systemd/user | XDG-Basisverzeichnis-Spezifikation | | | festgelegt werden ($XDG_DATA_DIRS | | | wird verwandt, falls gesetzt, | | | andernfalls /usr/local/share und | | | /usr/share) | +-----------------------------------------+------------------------------------+ |$dir/systemd/user fur jedes $dir in | Zusatzliche Orte fur installierte | |$XDG_DATA_DIRS | Benutzer-Units, einen fur jeden | | | Eintrag in $XDG_DATA_DIRS | +-----------------------------------------+------------------------------------+ |/usr/local/lib/systemd/user | Benutzer-Units, die durch den | | | Administrator installiert wurden | +-----------------------------------------+------------------------------------+ |/usr/lib/systemd/user | Benutzer-Units, die durch den | | | Paketverwalter der Distribution | | | installiert wurden | +-----------------------------------------+------------------------------------+ |$XDG_RUNTIME_DIR/systemd/generator.late | Erstellte Units mit niedriger | | | Prioritat (siehe late-dir in | | | systemd.generator(7)) | +-----------------------------------------+------------------------------------+ Die Gruppe der Ladepfade fur die Benutzerverwalterinstanzen kann mittels verschiedener Umgebungsvariablen erganzt oder geandert werden. Und Umgebungsvariablen konnen wiederum mittels Umgebungsgeneratoren gesetzt werden, siehe systemd.environment-generator(7). Insbesondere $XDG_DATA_HOME und $XDG_DATA_DIRS konnen leicht mittels systemd-environment-d-generator(8) gesetzt werden. Daher sind die hier aufgefuhrten Verzeichnisse nur die Vorgaben. Um die tatsachlich verwandte Liste, basierend auf den Compiler-Optionen und der aktuellen Umgebung, zu sehen, verwenden Sie systemd-analyze --user unit-paths Desweiteren konnen zusatzliche Units aus Verzeichnissen, die nicht im Unit-Ladepfad sind, in Systemd hereingeladen werden, indem ein Symlink erstellt wird, der auf eine Unit-Datei im Verzeichnis zeigt. Sie konnen systemctl link fur diese Aktion verwenden; siehe systemctl(1). Das Dateisystem, in dem sich die verlinkten Dateien befinden, muss beim Start von Systemd zugreifbar sein (d.h. alles unterhalb von /home/ oder /var/ ist nicht erlaubt, ausser diese Verzeichnisse befinden sich auf dem Wurzeldateisystem). Es ist wichtig, >>verlinkte Unit-Dateien<< von >>Unit-Dateien mit Alias<< zu unterscheiden: Jeder Symlink, dessen Symlink-Ziel sich innerhalb des Unit-Ladepfades befindet, wird ein Alias: der Quellname und der Zielname mussen den bestimmten, oben bei der Besprechung von Aliasen aufgefuhrten Einschrankungen genugen, aber das Symlink-Ziel muss nicht existieren. Tatsachlich wird der Pfad zum Symlink-Ziel nicht verwandt, ausser zu prufen, ob das Ziel sich innerhalb des Unit-Ladepfades befindet. Im Gegensatz dazu bedeutet ein Symlink, der ausserhalb des Unit-Ladepfades fuhrt, eine verlinkete Unit-Datei. Beim Laden der Datei wird dem Symlink gefolgt, aber der Zielname wird ansonsten nicht verwandt (und braucht noch nicht mal ein gultiger Unit-Dateiname zu sein). Beispielsweise sind /etc/systemd/system/alias1.service -> Dienst1.service, /etc/systemd/system/alias2.service -> /usr/lib/systemd/Dienst1.service, /etc/systemd/system/alias3.service -> /etc/systemd/system/Dienst1.service alle gultige Aliase und Dienst1.service wird vier Namen haben, selbst falls sich die Unit-Datei unter /run/systemd/system/Dienst1.service befindet. Im Gegensatz dazu bedeutet ein Symlink /etc/systemd/system/link1.service -> ../link1_Dienstedatei, dass link1.service eine >>verlinkte Unit<< ist und der Inhalt von /etc/systemd/link1_Dienstedatei seine Konfiguration bereitstellt. UNIT-MULLABFUHR Der System- und Diensteverwalter ladt die Konfiguration einer Unit automatisch, wenn die Unit das erste Mal referenziert wird. Er wird die Unit-Konfiguration und den Zustand wieder entladen, wenn die Unit nicht mehr benotigt wird (>>Mullabfuhr<<). Eine Unit kann uber eine Reihe von Mechanismen referenziert werden: 1. Eine andere geladene Unit referenziert sie mit einer Abhangigkeit wie After=, Wants=, 2. Die Unit startet, lauft, startet sich neu oder stoppt derzeit. 3. Die Unit ist derzeit im Zustand failed. (Siehe aber unten.) 4. Ein Auftrag fur die Unit ist anhangig. 5. Die Unit ist durch ein aktives IPC-Client-Programm verankert. 6. Die Unit ist eine besondere >>ewige<< Unit, die immer aktiv und geladen ist. Beispiele fur ewige Units sind die Wurzeleinhange-Unit -.mount und die Bereichs-Unit init.scope, in der der Diensteverwalter selbst lebt. 7. Die Unit hat ihr zugeordnete laufende Prozesse. Die Mullabfuhrlogik kann mit der Option CollectMode= verandert werden. Diese Option erlaubt die Konfiguration, ob automatisches Entladen von Units, die im Zustand failed sind, erlaubt ist, siehe unten. Beachten Sie, dass beim Entladen der Konfiguration und des Zustandes einer Unit alle Ausfuhrungsergebnisse, wie Exit-Codes, Exit-Signale und Resourcenverbrauch- und andere Statistiken, verloren gehen, ausser fur den Anteil, der im Protokolluntersystem gespeichert ist. Verwenden Sie systemctl daemon-reload oder einen aquivalenten Befehl, um die Unit-Konfiguration neu zu laden, wahrend die Unit bereits geladen ist. In diesem Fall werden alle Konfigurationseinstellungen rausgeschoben und durch die neue Konfiguration ersetzt (die allerdings nicht sofort in Kraft sein muss), allerdings wird samtlicher Laufzeitzustand gespeichert/wiederhergestellt. [UNIT]-ABSCHNITT-OPTIONEN Die Unit-Datei kann einen Abschnitt [Unit] enthalten, der generische Informationen uber die Unit transportiert, der nicht vom Unit-Typ abhangt: Description= Ein kurzer menschenlesbarer Titel fur die Unit. Dieser kann von systemd (und anderen Benutzeroberflachen) als eine fur den Benutzer sichtbare Bezeichnung fur die Unit verwandt werden, daher sollte diese Zeichenkette die Unit identifizieren, statt sie zu beschreiben, trotz des Namens. Diese Zeichenkette sollte auch nicht nur einfach den Unit-Namen wiederholen. >>Apache2 Webserver<< ist ein gutes Beispiel. Schlechte Beispiele sind >>leichtgewichtiger Hochleistungs-HTTP-Server<< (zu generisch) oder >>Apache2<< (fur Leute, die Apache nicht kennen, bedeutungslos, wiederholt den Namen der Unit). systemd kann dies als Substantiv in Statusnachrichten (>>Starting description...<<, >>Started description.<<, >>Reached target description.<<, >>Failed to start description.<<) verwenden, daher sollte er gross geschrieben werden und kein vollstandiger Satz oder eine Phrase mit einem kontinuierlichen Verb sein. Schlechte Beispiele sind auch >>exiting the container<< oder >>updating the database once per day.<<. Hinzugefugt in Version 201. Documentation= Eine Leerraum-getrennte Liste von URIs, die Dokumentation fur diese Unit oder ihre Konfiguration referenzieren. Es werden nur URIs von den Typen >>http://<<, >>https://<<, >>file:<<, >>info:<<, >>man:<< akzeptiert. Fur weitere Informationen uber die Syntax dieser URIs siehe uri(7). Die URIs sollten in der Reihenfolge der Bedeutung aufgefuhrt werden, beginnend mit der relevantesten. Es ist eine gute Idee, zuerst Dokumentation zu referenzieren, die erklart, was der Zweck der Unit ist, gefolgt von solcher uber seine Konfiguration, gefolgt von anderer relevanter Dokumentation. Diese Option kann mehr als einmal angegeben werden, in diesem Fall werden die festgelegten Listen von URIs zusammengefuhrt. Falls dieser Option die leere Zeichenkette zugewiesen wird, wird die Liste zuruckgesetzt und alle vorherigen Zuweisungen werden keinen Effekt haben. Hinzugefugt in Version 201. Wants= Konfiguriert (schwache) Anforderungsabhangigkeiten auf andere Units. Diese Option darf mehr als einmal angegeben werden oder mehrere, durch Leerraum getrennte Units konnen in einer Option angegeben werden, in diesem Fall werden Abhangigkeiten fur alle aufgefuhrten Namen erstellt. Abhangigkeiten dieses Typs konnen auch ausserhalb von Unit-Konfigurationsdateien hinzugefugt werden, indem ein Symlink auf ein die Unit-Datei begleitendes .wants/-Verzeichnis hinzugefugt wird. Siehe oben fur Details. In dieser Option aufgefuhrte Units werden gestartet, wenn die konfigurierende Unit es wird. Falls allerdings die aufgefuhrte Unit nicht startet oder der Transaktion nicht hinzugefugt werden kann, hat dies keine Auswirkungen auf die Gultigkeit der Transaktion als Ganzes und diese Unit wird dennoch gestartet. Dies ist die empfohlene Art, das Starten einer Unit in den Start einer anderen Unit einzuhangen. Beachten Sie, dass Anforderungsabhangigkeiten nicht die Reihenfolge beeinflussen, in der Dienste gestartet oder gestoppt werden. Dies muss unabhangig davon mit den Optionen After= oder Before= konfiguriert werden. Falls die Unit foo.service die Unit bar.service wie mit Wants= konfiguriert hereinzieht und mit After= oder Before= keine Ordnung konfiguriert ist, dann werden beide Units gleichzeitig und ohne Verzogerung untereinander gestartet, wenn foo.service aktiviert wird. Hinzugefugt in Version 201. Requires= Ahnlich Wants=, erklart aber eine starkerere Anforderungsabhangigkeit. Abhangigkeiten dieser Art konnen auch ausserhalb der Unit-Konfigurationsdatei konfiguriert werden, indem ein Symlink auf ein die Unit-Datei begleitendes .requires/-Verzeichnis hinzugefugt wird. Falls diese Unit aktiviert wird, werden die aufgefuhrten Units ebenfalls aktiviert. Falls die Aktivierung einer der anderen Units fehlschlagt und eine Ordnungsabhangigkeit After= auf die fehlgeschlagene Unit gesetzt ist, dann wird diese Unit nicht gestartet. Daruberhinaus wird diese Unit gestoppt (oder neu gestartet), falls eine der anderen Units explizit gestoppt (oder neu gestartet) wird, unahangig davon, ob After= gesetzt ist oder nicht. Oft ist es eine bessere Wahl, Wants= statt Requires= zu verwenden, um ein System zu erreichen, das im Umgang mit fehlschlagenden Diensten robuster ist. Beachten Sie, dass dieser Abhangigkeitstyp nicht impliziert, dass andere Units immer im aktiven Zustand sein mussen, wenn diese Unit lauft. Insbesondere: Fehlschlagende Bedingungsuberprufungen (wie ConditionPathExists=, ConditionPathIsSymbolicLink=, -- siehe unten) fuhren nicht dazu, dass der Start einer Unit mit einer Requires=-Abhangigkeit darauf fehlschlagt. Auch konnen sich einige Unit-Typen von selbst deaktivieren (beispielsweise kann sich ein Diensteprozess entscheiden, sich sauber zu beenden, oder ein Gerat konnte von einem Benutzer ausgesteckt werden), was nicht an die Units mit einer Requires=-Abhangigkeit ubertragen wird. Verwenden Sie den Abhangigkeitstyp BindsTo= zusammen mit After=, um sicherzustellen, dass sich eine Unit niemals im aktiven Zustand befindet, ohne dass eine andere Unit sich auch in einem aktiven Zustand befindet (siehe unten). Hinzugefugt in Version 201. Requisite= Ahnlich zu Requires=. Falls die hier aufgefuhrten Units noch nicht gestartet wurden, werden sie nicht gestartet und der Start dieser Unit wird sofort fehlschlagen. Requisite= impliziert keine Ordnungsabhangigkeit, selbst falls beide Units in der gleichen Transaktion gestartet werden. Daher sollte diese Einstellung normalerweise mit After= kombiniert werden, um sicherzustellen, dass diese Unit nicht vor der anderen Unit gestartet wird. Wenn Requisite=b.service auf a.service benutzt wird, wird diese Abhangigkeit als RequisiteOf=a.service in der Eigenschaftsliste von b.service angezeigt. RequisiteOf=-Abhangigkeiten konnen nicht direkt festgelegt werden. Hinzugefugt in Version 201. BindsTo= Konfiguriert Anforderungsabhangigkeiten, im Stil sehr ahnlich zu Requires=. Allerdings ist dieser Abhangigkeitstyp starker: Zusatzlich zu dem Effekt von Requires= deklariert er, dass beim Stoppen der gebundenen Unit auch diese Unit gestoppt wird. Das bedeutet, dass eine Unit, die an eine andere Unit gebunden ist, die plotzlich in einen inaktiven Zustand eintritt, auch gestoppt wird. Units konnen plotzlich und unerwartet aus verschiedenen Grunden in inaktive Zustande eintreten: Der Hauptprozess einer Dienste-Unit konnte sich aus eigenem Antrieb beenden, das zugrundeliegende Gerat einer Gerate-Unit konnte ausgesteckt werden oder der Einhangepunkt einer Einhange-Unit konnte ohne Beteiligung des System- und Diensteverwalters ausgehangt werden. Bei der Verwendung in Verbindung mit After= auf die gleiche Unit ist das Verhalten von BindsTo= sogar noch starker. In diesem Falle muss die angebundene Unit sogar in einem aktiven Zustand sein, damit diese Unit auch in einem aktiven Zustand ist. Dies bedeutet nicht nur, dass eine Unit, die an eine andere Unit angebunden ist, die plotzlich in einen inaktiven Zustand eintritt, sondern auch, die an eine andere Unit angebunden ist, die aufgrund einer nicht erfullten Bedingungsprufung (wie ConditionPathExists=, ConditionPathIsSymbolicLink=, \n siehe unten) ubersprungen wird, gestoppt wird, sollte sie laufen. Daher ist es in vielen Fallen am besten, BindsTo= mit After= zu kombinieren. Wenn BindsTo=b.service auf a.service benutzt wird, wird diese Abhangigkeit als BoundBy=a.service in der Eigenschaftsliste von b.service angezeigt. BoundBy=-Abhangigkeiten konnen nicht direkt festgelegt werden. Hinzugefugt in Version 201. PartOf= Konfiguriert Abhangigkeiten ahnlich zu Requires=, aber begrenzt auf das Stoppen und Neustarten von Units. Wenn Systemd die hier aufgefuhrten Units stoppt oder neustartet, wird die Aktion zu dieser Unit weitergeleitet. Beachten Sie, dass dies eine Einwegeabhangigkeit ist -- Anderungen an dieser Unit betreffen nicht die aufgefuhrten Units. Wenn PartOf=b.service auf a.service benutzt wird, wird diese Abhangigkeit als ConsistsOf=a.service in der Eigenschaftsliste von b.service angezeigt. ConsistsOf=-Abhangigkeiten konnen nicht direkt festgelegt werden. Hinzugefugt in Version 201. Upholds= Konfiguriert Abhangigkeiten ahnlich wie Wants=, aber alle in Upholds= aufgefuhrten Units starten immer, wenn sie als inaktiv oder fehlgeschlagen erkannt werden und fur sie kein Auftrag in der Warteschlange ist so lange diese Unit aktiv ist. Wahrend eine Abhangigkeit Wants= auf eine andere Unit eine einmalige Auswirkung hat, wenn diese Unit gestartet wird, hat eine Abhangigkeit Upholds= eine dauerhafte Auswirkung, fortwahrend die Unit neustartend, falls notwendig. Dies ist eine Alternative zu der Einstellung Restart= von Dienste-Units, um sicherzustellen, dass sie am Laufen gehalten werden, was auch immer passiert. Der Neustart passiert ohne Verzogerung und die gewohnlichen Unit-abhangigen Ratenbegrenzungen gelten. Wenn Upholds=b.service auf a.service benutzt wird, wird diese Abhangigkeit als UpheldBy=a.service in der Eigenschaftsliste von b.service angezeigt. Hinzugefugt in Version 249. Conflicts= Eine Leerraum-getrennte Liste von Unit-Namen. Konfiguriert negative Anforderungsabhangigkeiten. Falls eine Unit eine Einstellung Conflicts= auf eine andere Unit hat, wird das Starten ersterer die letzere stoppen und umgekehrt. Beachten Sie, dass diese Einstellung keine Ordnungsabhangigkeit impliziert, ahnlich der vorher beschriebenen Abhangigkeiten Wants= und Requires=. Das bedeutet, dass eine Abhangigkeit After= oder Before= erklart werden muss, um sicherzustellen, dass die in Konflikt stehende Unit gestoppt wird, bevor die andere Unit gestartet wird. Es spielt keine Rolle, welche der Ordnungsabhangigkeiten verwandt wird, da Stopp-Auftrage immer vor Start-Auftragen sortiert werden, siehe die nachfolgende Diskussion von Before=/After=. Falls Unit A, die in Konflikt zu Unit B steht, zum gleichzeitigen Start mit B eingeplant ist, wird die Transaktion entweder fehlschlagen (falls beide benotigte Teile der Transaktion sind) oder so verandert, dass dies behoben wird (falls eine oder beide Auftrage ein nicht benotigter Teil der Transaktion sind). In letzterem Fall wird der Auftrag, der nicht benotigt ist, entfernt, oder falls beide nicht benotigt werden, wird die den Konflikt auslosende Unit gestartet und die in Konflikt stehende gestoppt. Hinzugefugt in Version 201. Before=, After= Diese beiden Einstellungen erwarten eine Leerraum-getrennte Liste von Unit-Namen. Sie konnen mehrfach angegeben werden, wodurch Abhangigkeiten fur alle aufgefuhrten Namen erstellt werden. Diese zwei Einstellungen konfigurieren Ordnungsabhangigkeiten zwischen Units. Falls Unit foo.service die Einstellung Before=bar.service enthalt und beide Units gestartet werden, wird das Starten von bar.service verzogert, bis der Start von foo.service abgeschlossen ist.After= ist das Inverse von Before=, d.h. wahrend Before= sicherstellt, dass die konfigurierte Unit gestartet wird, bevor die aufgefuhrten Unit mit dem Starten beginnt, stellt After= das Gegenteil sicher, dass die aufgefuhrte Unit vollstandig gestartet ist, bevor die konfigurierte Unit gestartet wird. Beim Herunterfahren von zwei Units, zwischen denen eine Ordnungsabhangigkeit besteht, das Inverse der Start-Reihenfolge angewandt wird. Dies bedeutet, falls eine Unit mit After= auf eine andere Unit konfiguriert ist, wird die erstere vor letzterer gestoppt, falls beide heruntergefahren werden. Existiert zwischen zwei Units eine Ordnungsabhangigkeit und wird eine Unit gestoppt und die andere gestartet, dann wird das Herunterfahren vor dem Hochfahren einsortiert. Dabei spielt es in diesem Fall keine Rolle, ob die Ordnungsabhangigkeit After= oder Before= ist. Es spielt auch keine Rolle, welcher der beiden heruntergefahren wird, solange eine heruntergefahren und die andere gestartet wird. Das Herunterfahren wird in allen Fallen vor dem Starten eingeordnet. Falls zwischen zwei Units keine Ordnungsabhangigkeit besteht, dann werden sie gleichzeitig heruntergefahren und gestartet und es findet keine Ordnung statt. Es hangt vom Unit-Typ ab, wann genau der Start einer Unit abgeschlossen ist. Am wichtigsten ist, dass fur Dienste-Units das Starten fur die Zwecke von Before=/After= als abgeschlossen betrachtet wird, wenn alle ihre konfigurierten Startbefehle aufgerufen wurden und entweder fehlschlugen oder Erfolg meldeten. Beachten Sie, dass dies ExecStartPost einschliesst (oder ExecStopPost fur den Herunterfahr-Fall). Beachten Sie, dass diese Einstellungen unabhangig von und orthogonal zu den mit Requires=, Wants=, Requisite= oder BindsTo= konfigurierten Anforderungsabhangigkeit sind. Es ist ein haufiges Muster, einen Unit-Namen sowohl in die Optionen After= als auch in WantWants= aufzunehmen; in diesem Fall wird die aufgefuhrte Unit vor der Unit, die mit diesen Optionen konfiguriert ist, gestartet. Beachten Sie, dass Before=-Abhangigkeiten fur Gerate-Units nicht wirksam sind und nicht unterstutzt werden. Gerate werden im Allgemeinen aufgrund externer Einsteck-Ereignisse verfugbar und Systemd erstellt die entsprechende Gerate-Unit unverzuglich. Hinzugefugt in Version 201. OnFailure= Eine Leerraum-getrennte Liste einer oder mehrerer Units, die aktiviert werden, wenn diese Unit den Zustand >>failed<< einnimmt. Hinzugefugt in Version 201. OnSuccess= Eine Leerraum-getrennte Liste einer oder mehrerer Units, die aktiviert werden, wenn diese Unit den Zustand >>inactive<< einnimmt. Hinzugefugt in Version 249. PropagatesReloadTo=, ReloadPropagatedFrom= Eine Leerraum-getrennte Liste einer oder mehrerer Units, an die Neuladeanforderungen ausgebreitet werden sollen bzw. Units, von denen Neuladeanforderungen an diese Unit ausgebereitet werden sollen. Erteilen einer Neuladeanforderung an eine Unit, wird auch eine Neuladeanforderungen an alle Units, die mittels dieser zwei Einstellungen damit verlinkt sind, in die Warteschlange einstellen. Hinzugefugt in Version 201. PropagatesStopTo=, StopPropagatedFrom= Eine Leerraum-getrennte Liste einer oder mehrerer Units, an die Stop-Aufforderungen ausgebreitet werden sollen bzw. Units, von denen Stop-Aufforderungen an diese Unit ausgebereitet werden sollen. Erteilen einer Stop-Aufforderungen an eine Unit, wird auch eine Stop-Aufforderungen an alle Units, die mittels dieser zwei Einstellungen damit verlinkt sind, in die Warteschlange einstellen. Hinzugefugt in Version 249. JoinsNamespaceOf= Fur Units, die Prozesse starten (wie Dienste-Units) werden hier eine oder mehrere andere Units aufgefuhrt, dessen Netzwerk- oder temporarem Namensraum beigetreten werden soll. Falls dies fur eine Unit festgelegt ist (beispielsweise enthalt a.service JoinsNamespaceOf=b.service), dann wird die inverse Abhangigkeit (JoinsNamespaceOf=a.service fur b.service) impliziert. Dies gilt nur fur Unit-Typen, die die Anweisungen PrivateNetwork=, NetworkNamespacePath=PrivateIPC=, IPCNamespacePath= und PrivateTmp= unterstutzen (siehe systemd.exec(5) fur Details). Falls eine Unit, die diese Einstellung hat, gestartet wird, werden deren Prozesse die gleichen /tmp/-, /var/tmp/-, IPC- und Netzwerk-Namensraume wie die aufgefuhrte gestartete Unit haben. Falls mehrere aufgefuhrte Units bereits gestartet sind und sie sich keinen Namensraum teilen, ist nicht definiert, welchem Namensraum beigetreten wird. Beachten Sie, dass diese Einstellung nur Wirkung zeigt, falls PrivateNetwork=/NetworkNamespacePath=, PrivateIPC=/IPCNamespacePath= und/oder PrivateTmp= fur sowohl die Unit, die dem Namensraum beitritt, als auch die Unit, deren Namensraum beigetreten wird, aktiviert ist. Hinzugefugt in Version 209. RequiresMountsFor= Akzeptiert eine Leerraum-getrennte Liste absoluter Pfade. Fugt automatisch Abhangigkeiten vom Typ Requires= und After= fur alle fur den Zugriff auf den angegebenen Pfad benotigten Einhange-Units hinzu. Mit noauto markierte Einhangepunkte werden nicht durch local-fs.target automatisch eingehangt, werden fur den Zweck dieser Option aber weiterhin berucksichtigt, d.h. sie werden von dieser Unit hereingezogen. Hinzugefugt in Version 201. OnSuccessJobMode=, OnFailureJobMode= Akzeptiert einen Wert aus >>fail<<, >>replace<<, >>replace-irreversibly<<, >>isolate<<, >>flush<<, >>ignore-dependencies<<, >>ignore-requirements<<. Standardmassig >>replace<<. Gibt an, wie die in OnSuccess=/OnFailure= aufgefuhrten Units in die Warteschlange eingestellt werden. Siehe die Option --job-mode= von systemctl(1) fur Details uber die moglichen Werte. Falls dies auf >>isolate<< gesetzt ist, darf in OnSuccess=/OnFailure= nur eine einzelne Unit aufgefuhrt werden. Hinzugefugt in Version 209. IgnoreOnIsolate= Akzeptiert ein logisches Argument. Falls true, wird die Unit nicht gestoppt, wenn eine andere Unit isoliert wird. Standardmassig false fur Dienste-, Ziel-, Socket-, Timer- und Pfad-Units und true fur Scheiben-, Bereichs-, Gerate-, Swap-, Einhange- und Automount-Units. Hinzugefugt in Version 201. StopWhenUnneeded= Akzeptiert ein logisches Argument. Falls true, wird diese Unit gestoppt, wenn sie nicht mehr benutzt wird. Beachten Sie, dass Systemd standardmassig Units nicht stoppt, ausser sie stehen in Konflikt zu anderen Units oder der Benutzer bittet explizit um ihr Herunterfahren, um die auszufuhrende Arbeit zu minimieren. Falls diese Option gesetzt ist, wird eine Unit automatisch bereinigt, falls keine andere aktive Unit sie benotigt. Standardmassig false. Hinzugefugt in Version 201. RefuseManualStart=, RefuseManualStop= Akzeptiert ein logisches Argument. Falls true, kann diese Unit nur indirekt aktiviert oder deaktiviert werden. In diesem Fall werden direkte Start- oder Beendigungs-Anfragen des Benutzers zuruckgewiesen, erfolgt das Starten oder Beenden allerdings als Abhangigkeit von einer anderen Unit, dann wird das Starten oder Beenden erfolgreich sein. Dies ist primar eine Sicherheitsfunktionalitat, um sicherzustellen, dass der Benutzer nicht versehentlich Units aktiviert, die nicht fur direkte Aktivierung gedacht sind und nicht versehentlich Units deaktiviert, die nicht zur Beendigung gedacht sind. Diese Option ist standardmassig false. Hinzugefugt in Version 201. AllowIsolate= Akzeptiert ein logisches Argument. Falls true, darf diese Unit mit dem Befehl systemctl isolate verwandt werden. Andernfalls wird dies zuruckgewiesen. Es ist wahrscheinlich eine gute Idee, dies ausser fur Ziel-Units, die ahnlich wie Runlevel in SysV-Init-Systemen verwandt werden sollen, deaktiviert zu lassen, nur als Vorsichtsmassnahme, um unbenutzbare Systemzustande zu vermeiden. Diese Option ist standardmassig false. Hinzugefugt in Version 201. DefaultDependencies= Akzeptiert ein logisches Argument. Falls yes (die Vorgabe), werden einige Standard-Abhangigkeiten implizit fur die Unit erstellt. Die tatsachlich erstellten Abhangigkeiten hangen vom Unit-Typ ab. Fur Dienste-Units stellen diese Abhangigkeiten beispielsweise sicher, dass der Dienst erst gestartet wird, nachdem die grundlegende System-Initialisierung abgeschlossen ist und dass er korrekt beim System-Herunterfahren beendet wird. Siehe die jeweilige Handbuchseite fur Details. Im Allgemeinen sollten nur Dienste, die im fruhen Systemstart oder beim spaten Herunterfahren beteiligt sind, diese Option auf no setzen. Es wird nachdrucklich empfohlen, diese Option fur den Grossteil der haufigen Units aktiviert zu lassen. Falls auf no gesetzt, deaktiviert diese Option nicht alle impliziten Abhangigkeiten, sondern nur nicht essenzielle. Hinzugefugt in Version 201. SurviveFinalKillSignal= Akzeptiert ein logisches Argument. Standardmassig no. Falls yes, werden Prozessen, die zu dieser Unit gehoren, nicht die abschliessende Signale >>SIGTERM<< und >>SIGKILL<< wahrend der abschliessenden Herunterfahrphase des Systems gesandt. Diese Funktionalitat ersetzt den alteren Mechanismus, der es einem Programm erlaubte, wie in Systemd- und Speicher-Daemons fur das Wurzeldateisystem[2] beschrieben >>argv[0][0] = '@'<< zu setzen. Letzerer Mechanismus wird allerdings weiterhin unterstutzt. Hinzugefugt in Version 255. CollectMode= Optimiert den Algorithmus der >>Mullabfuhr<< fur diese Unit. Akzeptiert entweder inactive oder inactive-or-failed. Falls auf inactive gesetzt, wird die Unit entladen, falls sie im Zustand inactive ist und von keinen Clients, Auftragen oder anderen Units referenziert wird; allerdings wird sie nicht entladen, wenn sie im Modus failed ist. Im Modus failed werden fehlgeschlagene Units nicht entladen, bis der Benutzer systemctl reset-failed oder einen aquivalenten Befehl auf ihnen aufruft, um den Zustand failed zuruckzusetzen. Dieses Verhalten wird geandert, falls die Option auf inactive-or-failed gesetzt wird: in diesem Fall wird die Unit entladen, selbst falls die Unit im Zustand failed ist und daher ist ein explizites Zurucksetzen des Zustands failed nicht notwendig. Beachten Sie, dass Unit-Ergebnisse (wie Exit-Codes, Exit-Signale, verbrauchte Ressourcen, ) sofort nach Abschluss der Units entsorgt werden, ausser dem Anteil, der im Protokollieruntersystem gespeichert ist, falls dieser Modus verwandt wird. Standardmassig inactive. Hinzugefugt in Version 236. FailureAction=, SuccessAction= Konfiguriert die durchzufuhrende Aktion, wenn die Unit stoppt und in einen Fehlzustand oder inaktiven Zustand eintritt. Akzeptiert entweder none, reboot, reboot-force, reboot-immediate, poweroff, poweroff-force, poweroff-immediate, exit, exit-force, soft-reboot, soft-reboot-force, kexec, kexec-force, halt, halt-force und halt-immediate. Im Systemmodus sind alle Optionen erlaubt. Im Benutzermodus sind nur none, exit, exit-force, soft-reboot und soft-reboot-force erlaubt. Beide Optionen sind standardmassig none. Falls none gesetzt ist, wird keine Aktion ausgelost. reboot verursacht einen Neustart nach der normalen Herunterfahrprozedur (d.h. aquivalent zu systemctl reboot). reboot-force fuhrt zu einem erzwungenen Neustart, der alle Prozesse zwangsweise beenden wird, aber beim Neustart kein unsauberes Dateisystem erzeugen sollte (d.h. aquivalent zu systemctl reboot -f) und reboot-immediate fuhrt zu einer sofortigen Ausfuhrung des Systemaufrufs reboot(2), was zu Datenverlust fuhren kann (d.h. aquivalent zu systemctl reboot -ff). Ahnlich haben poweroff, poweroff-force, poweroff-immediate, kexec, kexec-force, halt, halt-force und halt-immediate die Wirkung des Herunterfahrens des Systems bzw. der Ausfuhrung von Kexec und Anhalten des Systems mit ahnlichen Semantiken. exit fuhrt dazu, dass sich der Verwalter beendet, wobei er der normalen Herunterfahrprozedur folgt, und exit-force fuhrt dazu, dass er sich ohne Herunterfahren der Dienste beendet. Wenn exit oder exit-force verwandt werden, wird standardmassig der Exit-Status des Hauptprozesses der Unit (falls dies zutrifft) vom Diensteverwalter zuruckgeliefert. Dies kann allerdings mit FailureActionExitStatus=/SuccessActionExitStatus= ausser Kraft gesetzt werden, siehe unten. soft-reboot wird eine Neustartkaktion im Anwendungsraum auslosen. soft-reboot-force macht dies auch, aber durchlauft vorher die Herunterfahrtransaktion nicht. Hinzugefugt in Version 236. FailureActionExitStatus=, SuccessActionExitStatus= Steuert den Exit-Status, der an den Container-Verwalter zuruckgeleitet werden soll (im Falle von Systemdiensten) oder dem Diensteverwalter (im Falle eines Benutzerverwalters), wenn die FailureAction=/SuccessAction= auf exit oder exit-force gesetzt sind und die Aktion ausgelost wird. Standardmassig wird der Exit-Status des Hauptprozesses der auslosenden Unit (falls dies zutrifft) weitergeleitet. Akzeptiert einen Wert im Bereich 0255 oder die leere Zeichenkette, um das Standardverhalten zu erbitten. Hinzugefugt in Version 240. JobTimeoutSec=, JobRunningTimeoutSec= JobTimeoutSec= legt eine Zeituberschreitung fur den gesamten Auftrag fest, dessen Ausfuhrung beginnt, wenn der Auftrag in die Warteschlange eingereiht wird. JobRunningTimeoutSec= legt eine Zeituberschreitung fest, dessen Ausfuhrung beginnt, wenn der Auftrag in der Warteschlange tatsachlich gestartet wird. Falls eine der beiden Begrenzungen erreicht wird, wird der Auftrag abgebrochen, die Unit wird allerdings ihren Zustand weder andern noch in den Modus >>failed<< eintreten. Beide Einstellungen akzeptieren eine Zeitdauer mit der Vorgabeeinheit Sekunden, aber andere Einheiten konnen angegeben werden, siehe systemd.time(5). Die Vorgabe ist >>infinity<< (Auftragszeituberschreitungen sind deaktiviert), ausser fur Gerate-Units, bei denen standardmassig JobRunningTimeoutSec= auf DefaultDeviceTimeoutSec= gesetzt ist. Hinweis: Diese Zeituberschreitungen sind unabhangig von allen Unit-spezifischen Zeituberschreitungen (beispielsweise den mit TimeoutStartSec= in Dienste-Units gesetzten Zeituberschreitungen). Die Auftragszeituberschreitung hat keine Wirkung fur die Unit selbst. Oder mit anderen Worten: Unit-spezifische Zeituberschreitungen sind nutzlich, um Zustandsanderungen von Units abzubrechen und sie zuruckzunehmen. Die mit dieser Option gesetzten Auftrags-Zeituberschreitungen sind allerdings nur nutzlich, um den Auftrag abzubrechen, der darauf wartet, dass die Unit den Zustand andert. Hinzugefugt in Version 201. JobTimeoutAction=, JobTimeoutRebootArgument= JobTimeoutAction= konfiguriert optional eine zusatzliche Aktion, die beim Erreichen der Zeituberschreitung unternommen werden soll, siehe die Beschreibung von JobTimeoutSec= und JobRunningTimeoutSec= oben. Es akzeptiert die gleichen Werte wie StartLimitAction=. Standardmassig none. JobTimeoutRebootArgument= konfiguriert eine optionale Neustartzeichenkette, die an den Systemaufruf reboot(2) ubergeben wird. Hinzugefugt in Version 240. StartLimitIntervalSec=Intervall, StartLimitBurst=Haufung Konfiguriert die Unit-Startraten-Begrenzung. Units, die haufiger als Haufung innherhalb der Zeitdauer Intervall gestartet werden, wird kein weiterer Start erlaubt. Verwenden Sie StartLimitIntervalSec=, um das Uberprufungsintervall zu konfigurieren und StartLimitBurst=, um zu konfigurieren, wie viele Starts pro Intervall erlaubt sind. Intervall ist eine Zeitdauer in der Standardeinheit Sekunden, aber andere Einheiten konnen angegeben werden, siehe systemd.time(5). Der besondere Wert >>infinity<< kann zur Begrenzung der Gesamtanzahl an Startversuchen verwandt werden, selbst wenn diese in grossen Zeitintervallen passieren. Standardmassig DefaultStartLimitIntervalSec= in der Verwalterkonfigurationsdatei und kann auf 0 gesetzt werden, um jegliche Art von Ratenbegrenzung zu deaktivieren. Haufung ist eine Zahl, die in der Verwalterkonfigurationsdatei standardmassig DefaultStartLimitBurst= ist. Diese Konfigurationsoptionen sind insbesondere im Zusammenspiel mit der Diensteeinstellung Restart= nutzlich (siehe systemd.service(5)); allerdings gelten sie fur alle Arten von Starts (einschliesslich manueller), nicht nur denen, die von der Restart=-Logik ausgelost werden. Beachten Sie, dass nicht versucht wird, Units, die fur Restart= konfiguriert ist und die die Startbegrenzung erreichen, weiterhin zu starten; allerdings konnen sie zu einem spateren Zeitpunkt noch manuell oder von einem Timer oder Socket gestartet werden, nachdem das Intervall abgelaufen ist. Von diesem Zeitpunkt an ist die Neustartlogik wieder aktiviert. systemctl reset-failed fuhrt dazu, dass der Neustartratenzahler fur einen Dienst geloscht wird, was nutzlich ist, wenn der Administrator eine Unit manuell starten mochte und die Startbegrenzung damit in die Quere kommt. Ratenbegrenzung wird durchgesetzt, nachdem alle Unit-Bedingungsprufungen ausgefuhrt wurden. Daher zahlen fur die Ratenbegrenzung Unit-Aktivierungen mit fehlgeschlagenen Bedingungen nicht mit. Wenn eine Unit aufgrund der Mullabfuhrlogik entladen wird (siehe oben) werden auch ihre Ratenbegrenzungszahler entleert. Das bedeutet, dass die Konfiguration einer Startratenbegrenzung fur eine Unit, die nicht kontinuierlich referenziert wird, keine Wirkung hat. Diese Einstellung gilt nicht fur Scheiben-, Ziel-, Gerate- und Bereichs-Units, da dies Unit-Typen sind, deren Aktivierung entweder nie fehlschlagen oder nur ein einziges Mal erfolgreich sein darf. Hinzugefugt in Version 229. StartLimitAction= Konfiguriert eine zusatzliche Aktion, die ergriffen werden soll, falls die mit StartLimitIntervalSec= und StartLimitBurst= konfigurierte Ratenbegrenzung erreicht wird. Akzeptiert die gleichen Werte wie die Einstellungen FailureAction=/SuccessAction=. Falls none gesetzt ist, wird das Erreichen der Ratenbegrenzung keine Aktion auslosen, ausser das der Start nicht erlaubt wird. Standardmassig none. Hinzugefugt in Version 229. RebootArgument= Konfiguriert das globale Argument fur den Systemaufruf reboot(2), falls StartLimitAction= oder FailureAction= eine Neustartaktion ist. Dies funktioniert genauso wie das optionale Argument fur den Befehl systemctl reboot. Hinzugefugt in Version 229. SourcePath= Ein Pfad zu der Konfigurationsdatei, aus der die Unit erstellt wurde. Dies ist hauptsachlich fur Implementierungen von Generatorwerkzeugen nutzlich, die Konfigurationen aus externen Konfigurationsdateiformaten in native Unit-Dateien umwandeln. Diese Funktionalitat sollte in normalen Unit-Dateien nicht verwandt werden. Hinzugefugt in Version 201. Bedingungen und Zusicherungen Unit-Dateien konnen auch eine Reihe von Bedingung=- und Zusicherung=-Einstellungen enthalten. Bevor die Unit gestartet wird, wird Systemd nachweisen, dass die festgelegten Bedingungen und Zusicherungen wahr sind. Falls nicht, wird das Starten der Unit (fast ohne Ausgabe) ubersprungen (im Falle von Bedingungen) oder mit einer Fehlermeldung abgebrochen (im Falle von Zusicherungen). Fehlschlagende Bedingungen oder Zusicherungen fuhren nicht dazu, dass die Unit in den Zustand >>failed<< uberfuhrt wird. Die Bedingungen und Zusicherungen werden zum Zeitpunkt uberpruft, zu dem der Start-Auftrag in der Warteschlange ausgefuhrt wird. Die Ordnungsabhangigkeiten werden weiterhin berucksichtigt, so dass andere Units weiterhin hereingezogen und einsortiert werden, als ob die Unit erfolgreich aktiviert worden ware und die Bedingungen und Zusicherungen werden zu dem genauen Moment ausgefuhrt, zu dem die Unit normalerweise starten wurde und kann daher den Systemzustand nach den einsortierten Units und vor Abschluss der Initialisierung validieren. Verwenden Sie Bedingungsausdrucke, um Units zu uberspringen, die auf dem lokalen System nicht zutreffen, beispielsweise da der Kernel oder die Laufzeitumgebung ihre Funktionalitat nicht benotigt. Falls mehrere Bedingungen festgelegt sind, wird die Unit ausgefuhrt, falls alle von ihnen zutreffen (d.h. es wird ein logisches UND angewandt). Den Bedingungsprufungen kann ein Pipe-Symbol (|) nach dem Gleichheitszeichen verwendet (>>Bedingung=!<<) werden, was dazu fuhrt, dass die Bedingung eine auslosende Bedingung wird. Falls fur eine Unit mindestens eine auslosende Bedingung definiert ist, dann wird die Unit gestartet, falls mindestens eine der auslosenden Bedingungen und alle der regularen (d.h. nicht auslosenden) Bedingungen zutreffen. Falls Sie einem Argument das Pipe-Symbol und ein Ausrufezeichen voranstellen, muss das Pipe-Symbol zuerst und das Ausrufezeichen als zweites ubergeben werden. Falls einer der Optionen die leere Zeichenkette zugewiesen wird, wird die Liste der Bedingungen komplett zuruckgesetzt und alle vorhergehenden Bedingungseinstellungen (jeder Art) werden keine Wirkung haben. Die Optionen AssertArchitecture=, AssertVirtualization=, sind zu Bedingungen ahnlich, fuhren aber dazu, dass Auftrage fehlschlagen (statt ubersprungen zu werden). Die fehlgeschlagene Prufung wird protokolliert. Units mit nicht zutreffenden Bedingungen werden als in einem sauberen Zustand betrachtet und der Speicher wird aufgeraumt, falls sie nicht referenziert werden. Dies bedeutet, dass bei Abfragen die Fehlerbedingung im Zustand der Unit angezeigt werden konnte oder auch nicht. Beachten Sie, dass weder eine Zusicherung noch ein Bedingungsausdruck zu Unit-Zustandsanderungen fuhrt. Beachten Sie auch, dass beide zum Zeitpunkt gepruft werden, zu dem der Auftrag ausgefuhrt werden soll, d.h. lange nachdem abhangige Auftrage und er selbst in die Warteschlange eingereiht wurden. Daher sind weder die Bedingungs- noch die Zusicherungsausdrucke dazu geeignet, Unit-Abhangigkeitsbedingungen auszudrucken. Der Unterbefehl condition aus systemd-analyze(1) kann zum Testen von Bedingungen und Zusicherungsausdrucken verwandt werden. Ausser fur ConditionPathIsSymbolicLink= folgen alle Pfadprufungen Symlinks. ConditionArchitecture= Pruft, ob das System auf einer bestimmten Architektur lauft. Akzeptiert einen aus >>x86<<, >>x86-64<<, >>ppc<<, >>ppc-le<<, >>ppc64<<, >>ppc64-le<<, >>ia64<<, >>parisc<<, >>parisc64<<, >>s390<<, >>s390x<<, >>sparc<<, >>sparc64<<, >>mips<<, >>mips-le<<, >>mips64<<, >>mips64-le<<, >>alpha<<, >>arm<<, >>arm-be<<, >>arm64<<, >>arm64-be<<, >>sh<<, >>sh64<<, >>m68k<<, >>tilegx<<, >>cris<<, >>arc<<, >>arc-be<< oder >>native<<. Die Architektur wird aus der durch uname(2) zuruckgelieferten Information bestimmt und unterliegt daher personality(2). Beachten Sie, dass eine Einstellung Personality= in der gleichen Unit-Datei keine Auswirkung auf diese Bedingung hat. Ein besonderer Architekturname >>native<< wird auf die Architektur, fur die der Systemverwalter selbst kompiliert wurde, abgebildet. Der Test kann durch Voranstellung eines Ausrufezeichens negiert werden. Hinzugefugt in Version 201. ConditionFirmware= Pruft, ob die Firmware des Systems von einem bestimmten Typ ist. Die folgenden Werte sind moglich: o >>uefi<< passt auf Systeme mit EFI. o >>device-tree<< passt auf Systeme mit einem Devicetree. o >>device-tree-compatible(Wert)<< passt auf Systeme mit einem Devicetree, die kompatibel mit >>Wert<< sind. o >>smbios-field(Feld Operator Wert)<< passt auf Systeme mit einem SMBIOS-Feld, das einen bestimmten Wert enthalt. Feld ist der Name eines SMBIOS-Feldes, das als >>sysfs<<-Attributsdatei unterhalb von /sys/class/dmi/id/ offengelegt wird. Operator ist einer aus >><<<, >><=<<, >>>=<<, >>><<, >>==<<, >><><< zum Versionsvergleich, >>=<< und >>!=<< fur wortlichen Zeichenkettenvergleich oder >>$=<<, >>!$=<< fur Shell-artigen Glob-Vergleich. Wert ist der erwartete Wert des SMBIOS-Feldes (moglicherweise enthalt er Shell-artige Globs, falls >>$="/"!$=<< verwandt wird. Hinzugefugt in Version 249. ConditionVirtualization= Pruft, ob das System in einer virtualisierten Umgebung ausgefuhrt wird und testet optional, ob es eine bestimmte Implementierung ist. Akzeptiert entweder einen logischen Wert, um zu prufen, ob es in einer virtualisierten Umgebung ausgefuhrt wird oder entweder >>vm<< oder >>container<<, um gegen eine generische Art von Virtualisierungslosung zu prufen oder einen aus >>qemu<<, >>kvm<<, >>amazon<<, >>zvm<<, >>vmware<<, >>microsoft<<, >>oracle<<, >>powervm<<, >>xen<<, >>bochs<<, >>uml<<, >>bhyve<<, >>qnx<<, >>apple<<, >>sre<<, >>openvz<<, >>lxc<<, >>lxc-libvirt<<, >>systemd-nspawn<<, >>docker<<, >>podman<<, >>rkt<<, >>wsl<<, >>proot<<, >>pouch<<, >>acrn<<, um gegen eine bestimmte Implementierung zu prufen oder >>private-users<<, um zu prufen, ob das System in einem Benutzernamensraum lauft. Siehe systemd-detect-virt(1) fur eine vollstandige Liste der bekannten Virtualisierungstechniken und ihrer Kennungen. Falls mehrere Virtualisierungstechniken verschachtelt sind, wird nur die innerste betrachtet. Der Test kann durch Voranstellung eines Ausrufezeichens negiert werden. Hinzugefugt in Version 244. ConditionHost= ConditionHost= kann dazu verwandt werden, den Rechnernamen oder die Maschinenkennung des Rechners zu vergleichen. Dies akzeptiert entweder eine Rechnernamenzeichenkette (optional mit Shell-artigen Globs), die gegen den lokal gesetzten Rechnernamen, wie er von gethostname(2) zuruckgeliefert wird, gepruft wird oder eine als Zeichenkette formatierte Maschinenkennung (siehe machine-id(5)). Der Test kann durch Voranstellung eines Ausrufezeichens negiert werden. Hinzugefugt in Version 244. ConditionKernelCommandLine= ConditionKernelCommandLine= kann zur Prufung, ob eine bestimmte Kernelbefehlszeilenoption gesetzt ist (oder falls ein Ausrufezeichen vorangestellt ist, nicht gesetzt ist) verwandt werden. Das Argument muss entweder ein einzelnes Wort oder eine Zuweisung (d.h. zwei Worte, getrennt durch >>=<<) sein. Im ersten Fall wird die Kernelbefehlszeile nach Auftauchen des Wortes wie es ist oder als linke Seite einer Zuweisung durchsucht. Im zweitem Fall wird nach der genauen Zuweisung geschaut, wobei die rechte und die linke Seite passen mussen. Dies agiert auf der Kernelbefehlszeile, die an die Anwendungsebene mittels /proc/cmdline kommuniziert wird, ausser wenn der Diensteverwalter als Nutzlast eines Container-Verwalters gestartet wird - dann wird stattdessen die Befehlszeile von PID 1 verwandt (d.h. /proc/1/cmdline). Hinzugefugt in Version 244. ConditionKernelVersion= ConditionKernelVersion= kann zur Prufung, ob die Kernelversion (wie sie durch uname -r gemeldet wird) auf einen bestimmten Ausdruck passt, oder falls ein Ausrufezeichen vorangestellt ist, nicht darauf passt. Das Argument muss eine List von (moglicherweise in Anfuhrungszeichen gesetzten) Ausdrucken sein. Jeder Ausdruck beginnt mit einem aus >>=<< oder >>!=<< fur Zeichenkettenvergleiche, >><<<, >><=<<, >>==<<, >><><<, >>>=<<, >>><< fur Versionsvergleiche oder >>$=<<, >>!$=<< fur Shell-artige Glob-Abgleiche. Falls kein Operator festgelegt ist, wird >>$=<< impliziert. Beachten Sie, dass die Verwendung der Kernelversionszeichenkette eine unzuverlassige Art ist, um zu bestimmen, welche Funktionalitaten vom Kernel unterstutzt werden, da haufig Funktionalitaten eines Kernels und Korrekturen von neueren Kerneln der Originalautoren in altere, von Distributionen bereitgestellte Versionen zuruckportiert werden. Daher ist die Prufung inharent unportierbar und sollte nicht fur Units verwandt werden, die auf verschiedenen Distributionen verwandt werden konnten. Hinzugefugt in Version 244. ConditionCredential= ConditionCredential= kann zum Prufen, ob eine Zugangsberechtigung mit dem festgelegten Namen in den Diensteverwalter ubergeben wurde. Siehe System- und Dienste-Zugangsberechtigungen[3] fur Details uber Zugangsberechtigungen. Falls dies in Diensten fur den Systemdiensteverwalter verwandt wird, kann dies dazu verwendet werden, Dienste abhangig von den hereingegebenen Zugangsberechtigungen zu machen. Falls dies in Diensten fur den benutzerbezogenen Diensteverwalter verwandt wird, kann dies dazu verwendet werden, Dienste abhangig von den in unit@.service-Diensten, die zu dem Benutzer gehoren, gegebenen Zugangsberechtigungen zu machen. Das Argument muss ein gultiger Zugangsberechtigungsname sein. Hinzugefugt in Version 252. ConditionEnvironment= ConditionEnvironment= kann zur Uberprufung, ob eine bestimmte Umgebungsvariable im Umgebungsblock des Diensteverwalters gesetzt (bzw. nicht gesetzt, falls ein Ausfuhrungszeichen vorangestellt wird) ist. Das Argument kann ein einzelnes Wort sein, um zu prufen, ob die Variable mit diesem Namen im Umgebungsblock definiert ist, oder eine Zuweisung (>>Name=Wert<<), um zu prufen, ob die Variable mit genau diesem Wert definiert ist. Beachten Sie, dass der Umgebungsblock des Diensteverwalters selbst gepruft wird, d.h. keine mit (wie oben beschrieben) Environment= oder EnvironmentFile= definierte Variablen. Dies ist besonders nutzlich, wenn der Diensteverwalter innerhalb einer Container-Umgebung oder als benutzerbezogener Diensteverwalter lauft, um auf Variablen zu prufen, die durch den einschliessenden Container-Verwalter oder PAM ubergeben wurden. Hinzugefugt in Version 246. ConditionSecurity= ConditionSecurity= kann zur Prufung, ob die ubergebene Sicherheitstechnik auf dem System aktiviert ist, verwandt werden. Derzeit werden die folgenden Werte erkannten: Tabelle 3. Erkannte Sicherheitstechniken +----------------+----------------------------------+ |Wert | Beschreibung | +----------------+----------------------------------+ |selinux | SELinux MAC | +----------------+----------------------------------+ |apparmor | AppArmor MAC | +----------------+----------------------------------+ |tomoyo | Tomoyo MAC | +----------------+----------------------------------+ |smack | SMACK MAC | +----------------+----------------------------------+ |ima | Integritatsmessungsarchitektur | | | (IMA) | +----------------+----------------------------------+ |audit | Linux-Audit-Rahmenwerk | +----------------+----------------------------------+ |uefi-secureboot | Sicherer UEFI-Systemstart | +----------------+----------------------------------+ |tpm2 | Trusted Platform Module 2.0 | | | (TPM2) | +----------------+----------------------------------+ |cvm | Vertrauenswurdige virtuelle | | | Maschine (SEV/TDX) | +----------------+----------------------------------+ |measured-uki | Vereinigtes Kernelabbild mit | | | PCR-11-Messung, gemass | | | systemd-stub(7). Hinzugefugt in | | | Version 255. | +----------------+----------------------------------+ Der Test kann durch Voranstellung eines Ausrufezeichens negiert werden. Hinzugefugt in Version 244. ConditionCapability= Pruft, ob die ubergebene Capability in der Capability-Begrenzungsmenge des Diensteverwalters existiert (d.h. dies pruft nicht, ob die Capability tatsachlich in der erlaubten oder effektiven Menge verfugbar ist, siehe capabilities(7) fur Details), verwandt werden. Ubergeben Sie einen Capability-Namen wie >>CAP_MKNOD<<, moglicherweise mit vorangestelltem Ausrufezeichen, um die Prufung zu negieren. Hinzugefugt in Version 244. ConditionACPower= Pruft, ob das System zum Zeitpunkt der Aktivierung der Unit am Netz hangt oder ausschliesslich uber Akku lauft. Dies akzeptiert ein logisches Argument. Falls auf >>true<< gesetzt, wird die Bedingung nur gelten, wenn mindestens ein Netzstecker an einer Wechselstromquelle hangt oder falls keine Wechselstromstecker bekannt sind. Umgekehrt, wenn auf >>false<< gesetzt, wird die Bedingung nur gelten, falls mindestens ein Wechselstromstecker bekannt ist und alle Wechselstromstecker von einer Stromquelle abgetrennt sind. Hinzugefugt in Version 244. ConditionNeedsUpdate= Akzeptiert entweder /var/ oder /etc/ als Argument, moglicherweise mit vorangestelltem >>!<< (zur Invertierung der Bedingung). Diese Bedingung kann eingesetzt werden, um Units davon abhangig zu machen, ob das angegebene Verzeichnis einer Aktualisierung bedarf, da die Anderungszeit von /usr/ neuer als die Stempeldatei .updated in dem angegebenen Verzeichnis ist. Dies ist nutzlich, um Offline-Aktualisierungen der Betriebssystemressourcen des Lieferanten in /usr/ zu implementieren, die Aktualisierungen von /etc/ oder /var/ beim nachfolgenden Systemstart benotigen. Units, die von dieser Bedingung Gebrauch machen, sollten sich vor systemd-update-done.service(8) einordnen, um sicherzustellen, dass sie ausgefuhrt werden, bevor die Anderungszeit der Stempeldatei zuruckgesetzt wird, wodurch eine abgeschlossene Aktualisierung angezeigt wird. Falls die Option systemd.condition-needs-update= auf der Kernelbefehlszeile angegeben ist (sie akzeptiert einen logischen Wert), wird sie das Ergebnis dieser Zustandsuberprufung ausser Kraft setzen und Vorrang vor allen Dateianderungsprufungen haben. Falls die Kernelbefehlszeilenoption verwandt wird, wird systemd-update-done.service keine direkte Auswirkung auf die nachfolgenden ConditionNeedsUpdate=-Uberprufungen haben, bis das System neu gestartet und dabei die Kernelbefehlszeilenoption nicht mehr angegeben wird. Beachten Sie, dass der Zeitstempel von /usr/ ausdrucklich aktualisiert werden sollte, nachdem die Inhalte verandert wurden, damit dieses Schema wirksam wird. Der Kernel wird den Veranderungszeitstempel eines Verzeichnisses nur automatisch aktualisieren, wenn direkt darunter liegende Eintrage eines Verzeichnisses verandert werden; eine Veranderung von verschachtelten Dateien wird nicht automatisch dazu fuhren, dass die mtime von /usr/ aktualisiert wird. Beachten Sie auch, dass die Aktualisierungsmethode nicht den Zeitstempel von /usr/ verandern sollte, wenn sie einen Aufruf enthalt, nach der Aktualisierung selbst geeignete Schritte auszufuhren. In einem typischen Paketierungsschema einer Distribution werden Pakete alle benotigten Aktualisierungsschritte als Teil der Installation oder des Upgrades durchfuhren, um die Paketinhalte sofort nutzbar zu machen. ConditionNeedsUpdate= sollte mit anderen Aktualisierungsmechanismen verwandt werden, bei denen eine solche direkte Aktualisierung nicht passiert. Hinzugefugt in Version 244. ConditionFirstBoot= Akzeptiert ein logisches Argument. Diese Bedingung kann eingesetzt werden, um Units davon abhangig zu machen, ob das System erstmalig startet. Dies bedeutet grob, dass /etc/ nicht bestuckt war, als das System den Systemstart begann (fur Details, siehe >>SEMANTIK BEIM ERSTEN SYSTEMSTART<< in machine-id(5)). Der erste Systemstart gilt als abgeschlassen (diese Bedingung wird als falsch ausgewertet), nachdem der Verwalter die Startphase abgeschlossen hat. Diese Bedingung kann zum Befullen von /etc/ beim ersten Systemstart nach Rucksetzen auf Werkseinstellungen oder wenn eine neue Systeminstanz das erste Mal einen Systemstart durchfuhrt, verwandt werden. Zur Robustheit sollten sich Units mit ConditionFirstBoot=yes vor first-boot-complete.target anordnen und dieses passive Ziel mit Wants= hereinziehen. Dies stellt sicher, dass bei einem abgebrochenen ersten Systemstart die Units erneut beim nachsten Systemstart ausgefuhrt werden. Falls die Option systemd.condition-first-boot= auf der Kernelbefehlszeile angegeben ist (sie akzeptiert einen logischen Wert), wird sie das Ergebnis dieser Zustandsuberprufung ausser Kraft setzen und Vorrang vor /etc/machine-id-Existenzprufungen haben. Hinzugefugt in Version 244. ConditionPathExists= Pruft auf die Existenz einer Datei. Falls der angegebene absolute Pfadname nicht existiert, wird die Bedingung fehlschlagen. Falls dem an ConditionPathExists= ubergebenen absoluten Pfadnamen ein Ausrufezeichen (>>!<<) vorangestellt wird, wird der Test negiert und die Unit nur gestartet, falls der Pfadname nicht existiert. Hinzugefugt in Version 244. ConditionPathExistsGlob= ConditionPathExistsGlob= ist zu ConditionPathExists= ahnlich, pruft aber auf die Existenz von mindestens einer Datei oder einem Verzeichnis, das auf das angegebene Globbing-Muster passt. Hinzugefugt in Version 244. ConditionPathIsDirectory= ConditionPathIsDirectory= ist zu ConditionPathExists= ahnlich, uberpruft aber, dass ein bestimmter Pfad existiert und ein Verzeichnis ist. Hinzugefugt in Version 244. ConditionPathIsSymbolicLink= ConditionPathIsSymbolicLink= ist zu ConditionPathExists= ahnlich, uberpruft aber, dass ein bestimmter Pfad existiert und ein symbolischer Link ist. Hinzugefugt in Version 244. ConditionPathIsMountPoint= ConditionPathIsMountPoint= ist zu ConditionPathExists= ahnlich, uberpruft aber, dass ein bestimmter Pfad existiert und ein Einhangepunkt ist. Hinzugefugt in Version 244. ConditionPathIsReadWrite= ConditionPathIsReadWrite= ist zu ConditionPathExists= ahnlich, uberpruft aber, dass das zugrundeliegende Dateisystem les- und schreibbar ist (d.h. nicht rein-lesbar eingehangt ist). Hinzugefugt in Version 244. ConditionPathIsEncrypted= ConditionPathIsEncrypted= ist ahnlich zu ConditionPathExists=, uberpruft aber, dass das dem Dateisystem zugrundeliegende Blockgerat mittels dm-crypt/LUKS verschlusselt ist. Beachten Sie, dass diese Prufung keine verzeichnisbezogene Verschlusselung bei Ext4 berucksichtigt und nur Verschlusselung auf Blockebene erkennt. Desweiteren wird nur die Verschlusselung oberhalb des Loopback-Gerates erkannt, falls der angegebene Pfad sich auf einem Dateisystem oberhalb eines per Looback eingehangten Gerates befindet. Es wird nicht erkannt, ob das dem Loopback zugrundeliegende Blockgerat verschlusselt ist. Hinzugefugt in Version 246. ConditionDirectoryNotEmpty= ConditionDirectoryNotEmpty= ist zu ConditionPathExists= ahnlich, uberpruft aber, dass ein bestimmter Pfad existiert und ein nicht leeres Verzeichnis ist. Hinzugefugt in Version 244. ConditionFileNotEmpty= ConditionFileNotEmpty= ist zu ConditionPathExists= ahnlich, uberpruft aber, dass ein bestimmter Pfad existiert und sich auf eine normale Datei mit einer von Null verschiedenen Grosse bezieht. Hinzugefugt in Version 244. ConditionFileIsExecutable= ConditionFileIsExecutable= ist zu ConditionPathExists= ahnlich, uberpruft aber, dass ein bestimmter Pfad existiert und sich auf eine normale, als ausfuhrbar gekennzeichnete Datei bezieht. Hinzugefugt in Version 244. ConditionUser= ConditionUser= akzeptiert eine numerische >>UID<<, einen UNIX-Benutzernamen oder den besonderen Wert >>@system<<. Diese Bedingung kann zur Prufung, ob der Diensteverwalter als der angegebene Benutzer lauft, verwandt werden. Der besondere Wert >>@system<< kann dazu verwandt werden, zu prufen, ob die Benutzerkennung innerhalb des Systembenutzerbereichs ist. Diese Option ergibt fur Systemdienste keinen Sinn, da der Systemverwalter ausschliesslich als Benutzer root lauft und daher das Testergebnis konstant ist. Hinzugefugt in Version 244. ConditionGroup= ConditionGroup= ist zu ConditionUser= ahnlich, uberpruft aber, ob die reale oder effektive Gruppe des Diensteverwalters oder jeder seiner Hilfsgruppen auf die angegebene Gruppe oder GID passt. Diese Einstellung unterstutzt den besonderen Wert >>@system<< nicht. Hinzugefugt in Version 244. ConditionControlGroupController= Pruft, ob ubergebene Cgroup-Controller (z.B. >>cpu<<) fur die Verwendung auf dem System verfugbar sind oder ob die veraltete V1-Cgroup- oder die moderne V2-Cgroup-Hierarchie verwandt wird. Durch Leerzeichen getrennt konnen mehrere Controller ubergeben werden; in diesem Fall wird die Bedingung nur zutreffen, falls alle aufgefuhrten Controller zur Verwendung verfugbar sind. Dem System unbekannte Controller werden ignoriert. Gultige Controller sind >>cpu<<, >>io<<, >>memory<< und >>pids<<. Selbst falls er im Kernel verfugbar ist, kann ein bestimmter Controller nicht verfugbar sein, falls er auf der Kernel-Befehlszeile wie folgt deaktiviert wurde: Alternativ konnen die zwei besonderen Zeichenketten >>v1<< und >>v2<< (ohne irgendwelche Controller-Namen) angegeben werden. >>v2<< wird zutreffen, falls die vereinigte v2-Cgroup-Hierarchie verwandt wird und >>v1<< wird zutreffen, falls die veraltete v1-Hierarchie oder die hybride Hierarchie verwandt wird. Beachten Sie, dass die veraltete und hybride Hierarchie als veraltet markiert wurden. Siehe systemd(1) fur weitere Informationen. Hinzugefugt in Version 244. ConditionMemory= Uberpruft, ob die angegebene Menge an Systemspeicher fur das aktuelle System verfugbar ist. Akzeptiert eine Speichergrosse in Byte als Argument, optional kann ein Vergleichsoperator >><<<, >><=<<, >>=<< (oder >>==<<), >>!=<< (oder >><><<), >>>=<<, >>><< vorangestellt werden. Auf Systemen, die direkt auf der Hardware laufen, vergleicht es die Menge an physischen Speicher im System mit der angegebenen Grosse unter Berucksichtigung des angegebenen Vergleichsoperators. In Containern wird stattdessen die Menge des zugewiesenen Speichers verglichen. Hinzugefugt in Version 244. ConditionCPUs= Uberpruft, dass die angegebene Anzahl an CPUs fur das aktuelle System verfugbar ist. Akzeptiert eine Anzahl an CPUs als Argument, optional kann ein Vergleichsoperator >><<<, >><=<<, >>=<< (oder >>==<<), >>!=<<, >>>=<< (oder >><><<), >>><< vorangestellt werden. Vergleicht die Anzahl der CPUs in der CPU-Affinitatsmaske, die im Diensteverwalter selbst konfiguriert ist, mit der angegebenen Zahl unter Berucksichtigung des angegebenen Vergleichsoperators. Auf physischen Systemen passt die Anzahl der CPUs in der Affinitatsmaske des Diensteverwalters normalerweise zu der Anzahl der physischen CPUs, aber in besonderen und virtuellen Umgebungen kann sich das unterscheiden. Insbesondere in Containern passt die Affinitatsmaske normalerweise zu der dem Container zugewiesenen Anzahl an CPUs und nicht zu der Anzahl der physisch verfugbaren. Hinzugefugt in Version 244. ConditionCPUFeature= Pruft nach, ob die angegebene CPU-Funktionalitat mittels der >>CPUID<<-Anweisung verfugbar ist. Diese Bedingung macht nur auf i386- und x86-64-Prozessoren etwas. Auf anderen Prozessoren wird angenommen, dass die CPU die angegebene Funktionalitat nicht unterstutzt. Es pruft die Erlaubnisse >>1<<, >>7<<, >>0x80000001<< und >>0x80000007<<. Gultige Werte sind: >>fpu<<, >>vme<<, >>de<<, >>pse<<, >>tsc<<, >>msr<<, >>pae<<, >>mce<<, >>cx8<<, >>apic<<, >>sep<<, >>mtrr<<, >>pge<<, >>mca<<, >>cmov<<, >>pat<<, >>pse36<<, >>clflush<<, >>mmx<<, >>fxsr<<, >>sse<<, >>sse2<<, >>ht<<, >>pni<<, >>pclmul<<, >>monitor<<, >>ssse3<<, >>fma3<<, >>cx16<<, >>sse4_1<<, >>sse4_2<<, >>movbe<<, >>popcnt<<, >>aes<<, >>xsave<<, >>osxsave<<, >>avx<<, >>f16c<<, >>rdrand<<, >>bmi1<<, >>avx2<<, >>bmi2<<, >>rdseed<<, >>adx<<, >>sha_ni<<, >>syscall<<, >>rdtscp<<, >>lm<<, >>lahf_lm<<, >>abm<<, >>constant_tsc<<. Hinzugefugt in Version 248. ConditionOSRelease= Bestatigt, dass ein bestimmtes >>Schlussel-Wert<<-Paar in der os-release(5) des Rechners gesetzt ist. Neben der genauen Zeichenkettenubereinstimmung (mit >>=<< und >>!=<<) werden relative Vergleiche fur versionierte Parameter unterstutzt (z.B. >>VERSION_ID<<; mit >><<<, >><=<<, >>==<<, >><><<, >>>=<<, >>><<) und Shell-artige Joker-Vergleiche (>>*<<, >>?<<, >>[]<<) werden mit >>$=<< (Treffer) und >>!$=<< (nicht Treffer) unterstutzt. Hinzugefugt in Version 249. ConditionMemoryPressure=, ConditionCPUPressure=, ConditionIOPressure= Verifiziert, dass der gesamte Systemdruck (Speicher, CPU oder E/A) unterhalb von oder identisch zu einem Schwellwert ist. Diese Einstellung akzeptiert einen Schwellwert als Argument. Sie kann als einfacher Prozentwert, dem >>%<< angehangt wird, festgelegt werden; in diesem Fall wird der Druck als Durchschnitt uber die letzten funf Minuten gemessen, bevor der Versuch, die Unit zu starten, durchgefuhrt wird. Alternativ kann eine durchschnittliche Zeitdauer auch mit >>/<< als Trenner festgelegt werden, beispielsweise >>10%/1min<<. Die unterstutzten Zeitdauern passen auf das Angebot des Kernels und sind auf >>10sec<<, >>1min<< und >>5min<< beschrankt. Zuerst wird der vollstandige PSI gepruft, und falls dieser nicht gefunden wird, werden >>einige<< gepruft. Fur weitere Details lesen Sie die Dokumentation unter PSI (Pressure Stall Information)[4]. Optional kann dem Schwellwert die Scheiben-Unit, unter der der Druck uberpruft wird, vorangestellt werden, gefolgt von >>:<<. Falls die Scheiben-Unit nicht festgelegt ist, wird der Gesamtsystemdruck statt dem einer bestimmten Cgroup gemessen. Hinzugefugt in Version 250. AssertArchitecture=, AssertVirtualization=, AssertHost=, AssertKernelCommandLine=, AssertKernelVersion=, AssertCredential=, AssertEnvironment=, AssertSecurity=, AssertCapability=, AssertACPower=, AssertNeedsUpdate=, AssertFirstBoot=, AssertPathExists=, AssertPathExistsGlob=, AssertPathIsDirectory=, AssertPathIsSymbolicLink=, AssertPathIsMountPoint=, AssertPathIsReadWrite=, AssertPathIsEncrypted=, AssertDirectoryNotEmpty=, AssertFileNotEmpty=, AssertFileIsExecutable=, AssertUser=, AssertGroup=, AssertControlGroupController=, AssertMemory=, AssertCPUs=, AssertCPUFeature=, AssertOSRelease=, AssertMemoryPressure=, AssertCPUPressure=, AssertIOPressure= Ahnlich zu den oben beschriebenen Bedingungseinstellungen ConditionArchitecture=, ConditionVirtualization=, fugen diese Einstellungen Zusicherungsprufungen zum Hochfahren der Unit hinzu. Anders als bei den Bedingungseinstellungen fuhrt jede Zusicherungseinstellung, die nicht erfullt wird, zu einem Fehlschlag des Startauftrags (das bedeutet, dass es laut protokolliert wird). Beachten Sie, dass das Erreichen einer konfigurierten Zusicherung nicht dazu fuhrt, dass die Unit in den Zustand >>failed<< eintritt (oder tatsachlich zu irgendeiner Zustandsanderung der Unit fuhrt). Verwenden Sie Zusicherungsausdrucke fur Units, die nicht agieren konnen, falls bestimmte Anforderungen nicht erfullt sind und wenn dies etwas ist, was sich der Administrator oder Benutzer anschauen sollte. Hinzugefugt in Version 218. ABBILDUNG VON UNIT-EIGENSCHAFTEN AUF IHR INVERSES Unit-Einstellungen, die eine Beziehung zu einer zweiten Unit erstellen, zeigen sich normalerweise als Eigenschaften in beiden Units, beispielsweise in der Ausgabe von systemctl show. In einigen Fallen (aber nicht immer) ist der Name der Eigenschaft identisch mit dem Namen der Konfigurationseinstellung. Diese Tabelle listet die Eigenschaften auf, die in zwei Units angezeigt werden, die durch eine Abhangigkeit verbunden sind. Sie zeigt, welche Eigenschaft aus der >>Quell<<-Unit welcher Eigenschaft aus der >>Ziel<<-Unit entspricht. Tabelle 4. Vorwarts- und Ruckwarts-Unit-Eigenschaften +---------------------------+-------------------------------+----------------------------------------+ |>>Vorwarts<<-Eigenschaft | >>Ruckwarts<<-Eigenschaft | Wo benutzt | +---------------------------+-------------------------------+----------------------------------------+ |Before= | After= | [Unit]-Abschnitt | +---------------------------+-------------------------------+ | | |After= | Before= | | | +---------------------------+-------------------------------+------------------+---------------------+ |Requires= | RequiredBy= | [Unit]-Abschnitt | [Install]-Abschnitt | +---------------------------+-------------------------------+------------------+---------------------+ |Wants= | WantedBy= | [Unit]-Abschnitt | [Install]-Abschnitt | +---------------------------+-------------------------------+------------------+---------------------+ |Upholds= | UpheldBy= | [Unit]-Abschnitt | [Install]-Abschnitt | +---------------------------+-------------------------------+------------------+---------------------+ |PartOf= | ConsistsOf= | [Unit]-Abschnitt | eine automatische | | | | | Eigenschaft | +---------------------------+-------------------------------+------------------+---------------------+ |BindsTo= | BoundBy= | [Unit]-Abschnitt | eine automatische | | | | | Eigenschaft | +---------------------------+-------------------------------+------------------+---------------------+ |Requisite= | RequisiteOf= | [Unit]-Abschnitt | eine automatische | | | | | Eigenschaft | +---------------------------+-------------------------------+------------------+---------------------+ |Conflicts= | ConflictedBy= | [Unit]-Abschnitt | eine automatische | | | | | Eigenschaft | +---------------------------+-------------------------------+------------------+---------------------+ |Triggers= | TriggeredBy= | automatische Eigenschaften, siehe | | | | Hinweise unten | +---------------------------+-------------------------------+----------------------------------------+ |PropagatesReloadTo= | ReloadPropagatedFrom= | [Unit]-Abschnitt | +---------------------------+-------------------------------+ | | |ReloadPropagatedFrom= | PropagatesReloadTo= | | | +---------------------------+-------------------------------+------------------+---------------------+ |PropagatesStopTo= | StopPropagatedFrom= | [Unit]-Abschnitt | +---------------------------+-------------------------------+ | | |StopPropagatedFrom= | PropagatesStopTo= | | | +---------------------------+-------------------------------+------------------+---------------------+ |Following= | n.Z. | eine | | | | | automatische | | | | | Eigenschaft | | +---------------------------+-------------------------------+------------------+---------------------+ Beachten Sie: WantedBy=, RequiredBy= und UpheldBy= werden im Abschnitt [Install] verwandt, um Symlinks in .wants/-, .requires/- und upholds/-Verzeichnissen zu erstellen. Sie konnen nicht in Unit-Konfigurationseinstellungen direkt verwandt werden. Beachten Sie: ConsistsOf=, BoundBy=, RequisiteOf=, ConflictedBy= werden zusammen mit ihren Inversen implizit erstellt und konnen nicht direkt festgelegt werden. Beachten Sie: Triggers= wird implizit zwischen einem Socket, einer Pfad-Unit oder einer Automount-Unit und der sie aktivierenden Unit erstellt. Standardmassig wird eine Unit mit dem gleichen Namen ausgelost, dies kann aber mit den Einstellungen Sockets=, Service= und Unit= ausser Kraft gesetzt werden. Siehe systemd.service(5), systemd.socket(5), systemd.path(5) und systemd.automount(5) fur ihre Details. TriggeredBy= wird implizit von der ausgelosten Unit erstellt. Beachten Sie: Following= wird zur Gruppierung von Gerate-Aliassen und -Punkten zu der >>primaren<<-Gerate-Unit, die Systemd zur Nachverfolgung des Geratezustandes verwendet, verwandt, normalerweise entspricht dies einem Sysfs-Pfad. Dies taucht nicht in der >>Ziel<<-Unit auf. [INSTALL]-ABSCHNITT-OPTIONEN Unit-Dateien konnen einen Abschnitt >>[Install]<< enthalten, der Installationsinformationen fur die Unit transportiert. Dieser Abschnitt wird von systemd(1) wahrend der Laufzeit nicht interpretiert; er wird von den Befehlen enable und disable des Werkzeugs systemctl(1) wahrend der Installation einer Unit verwandt. Alias= Eine Lerraum-getrennte Liste von zusatzlichen Namen, unter der diese Unit installiert werden soll. Die hier aufgefuhrten Namen mussen die gleiche Endung (d.h. Typ) wie der Unit-Dateiname haben. Diese Option kann mehr als einmal angegeben werden, dann werden alle aufgefuhrten Namen verwandt. Bei der Installation wird systemctl enable die Symlinks von diesen Namen auf den Unit-Dateinamen erstellen. Beachten Sie, dass nicht alle Unit-Typen solche Aliase unterstutzen und diese Einstellung fur sie nicht unterstutzt wird. Insbesondere unterstutzen Einhange-, Scheiben, Auslagerungs- und Automount-Units keinen Alias. Hinzugefugt in Version 201. WantedBy=, RequiredBy=, UpheldBy= Diese Option kann mehr als einmal verwendet werden oder eine durch Leerzeichen getrennte Liste von Unit-Namen kann ubergeben werden. Im .wants/-, .requires/- oder .upholds/-Verzeichnis jeder der aufgefuhrten Units wird bei der Installation mit systemctl enable ein symbolischer Link erstellt. Dadurch wird eine Abhangigkeit vom Typ Wants=, Requires= oder Upholds= von der aufgefuhrten Unit zu der aktuellen Unit hinzugefugt. Siehe die Beschreibung der erwahnten Abhangigkeitstypen in dem Abschnitt [Unit] fur Details. Falls Vorlagen-Units nicht-Vorlagen-Units auffuhren, muss in der auffuhrenden Unit DefaultInstance= gesetzt sein oder systemctl enable muss mit einem Instanzennamen aufgerufen werden. Die Instanz (entweder die Vorgabe oder die angegebene) wird zu der Liste der .wants/, .requires/ oder .upholds/ der aufgefuhrten Unit hinzugefugt. Zum Beispiel fuhrt WantedBy=getty.target in einem Dienst getty@.service dazuz, dass systemctl enable getty@tty2.service einen Link getty.target.wants/getty@tty2.service auf getty@.service erstellt. Dies gilt auch fur das Auffuhren bestimmter Instanzen aus einer Vorlagen-Unit: diese bestimmte Instanz wird die Abhangigkeit erhalten. Eine Vorlagen-Unit kann auch eine Vorlagen-Unit auffuhren. Dann wird eine generische Abhangigkeit hinzugefugt, bei der jede Instanz der auffuhrenden Unit eine Abhangigkeit auf eine Instanz der aufgefuhrten Vorlagen-Unit mit dem gleichen Instanzwert haben wird. Beispielsweise wird WantedBy=container@.target dazu fuhren, dass systemctl enable monitor@.service einen Dienste-Link container@.target.wants/monitor@.service auf monitor@.service erstellt, der fur alle Instanzen von container@.target gilt. Hinzugefugt in Version 201. Also= Zusatzliche Units, die installiert/deinstalliert werden sollen, wenn diese Unit installiert/deinstalliert wird. Falls der Benutzer die Installation/Deinstallation einer Unit mit dieser konfigurierten Option erbeten hat, wird systemctl enable und systemctl disable automatisch auch die in dieser Option aufgefuhrten Units installieren/deinstallieren. Diese Option kann mehr als einmal verwandt werden oder eine Lerraum-getrennte Liste von Unit-Namen kann ubergeben werden. Hinzugefugt in Version 201. DefaultInstance= In Vorlagen-Unit-Dateien kennzeichnet dies, welche Instanz der Unit freigegeben werden soll, falls die Vorlage ohne explizit gesetzte Instanz freigegeben wird. Diese Option zeigt nur bei Vorlagen-Unit-Dateien Wirkung. Die gekennzeichnete Zeichenkette zur Identifizierung einer Instanz geeignet sein. Hinzugefugt in Version 215. Die folgenden Kennzeicher werden in dem Abschnitt Install interpretiert: %a, %b, %B, %g, %G, %H, %i, %j, %l, %m, %n, %N, %o, %p, %u, %U, %v, %w, %W, %% . Ihre Bedeutung ist im nachsten Abschnitt beschrieben. KENNZEICHNER Viele Einstellungen klaren Kennzeichner, die zum Schreiben generischer Unit-Dateien verwandt werden konnen, die sich auf Laufzeit- oder Unit-Parameter beziehen, die ersetzt werden, wenn die Unit-Dateien geladen werden. Kennzeichner mussen bekannt und auflosbar sein, damit die Einstellungen gultig sind. Die folgenden Kennzeichner werden verstanden: Tabelle 5. In Unit-Dateien verfugbare Kennzeichner +-------------+--------------------------------+-------------------------------------------+ |Kennzeichner | Bedeutung | Details | +-------------+--------------------------------+-------------------------------------------+ |"%a" | Architektur | Eine kurze Zeichenkette, die die | | | | Architektur des lokalen Systems | | | | identifiziert. Eine Zeichenkette wie x86, | | | | x86-64 oder arm64. Siehe die fur | | | | ConditionArchitecture= weiter oben | | | | definierten Architekturen fur die | | | | vollstandige Liste. | +-------------+--------------------------------+-------------------------------------------+ |"%A" | Betriebssystemabbildversion | Die | | | | Betriebssystemabbildversionskennzeichnung | | | | des laufenden Systems, wie aus dem Feld | | | | IMAGE_VERSION= in /etc/os-release | | | | ausgelesen. Falls nicht gesetzt, wird es | | | | die leere Zeichenkette. Siehe | | | | os-release(5) fur weitere Informationen. | +-------------+--------------------------------+-------------------------------------------+ |"%b" | Boot-Kennung | Die Boot-Kennung des laufenden Systems, | | | | formatiert als Zeichenkette. Siehe | | | | random(4) fur weitere Informationen. | +-------------+--------------------------------+-------------------------------------------+ |"%B" | Betriebssystembaukennung | Die Betriebssystembaukennung des | | | | laufenden Systems, wie aus dem Feld | | | | BUILD_ID= in /etc/os-release ausgelesen. | | | | Falls nicht gesetzt, wird es zur leeren | | | | Zeichenkette aufgelost. Siehe | | | | os-release(5) fur weitere Informationen. | +-------------+--------------------------------+-------------------------------------------+ |"%C" | Wurzelverzeichnis des | Dies ist entweder /var/cache (fur den | | | Zwischenspeichers | Systemverwalter) oder worauf der Pfad | | | | >>$XDG_CACHE_HOME<< zeigt (fur | | | | Benutzerverwalter). | +-------------+--------------------------------+-------------------------------------------+ |"%d" | Zugangsdaten-Verzeichnis | Dies ist der Wert der Umgebungsvariablen | | | | >>$CREDENTIALS_DIRECTORY<<, falls | | | | verfugbar. Siehe den Abschnitt | | | | >>Zugangsdaten<< in systemd.exec(5) fur | | | | weitere Informationen. | +-------------+--------------------------------+-------------------------------------------+ |"%E" | Wurzelverzeichnis der | Dies ist entweder /etc/ (fur den | | | Konfiguration | Systemverwalter) oder worauf der Pfad | | | | >>$XDG_CONFIG_HOME<< zeigt (fur | | | | Benutzerverwalter). | +-------------+--------------------------------+-------------------------------------------+ |"%f" | Demaskierter Dateiname | Dies ist entweder der demaskierte | | | | Instanzenname (falls zutreffend), dem / | | | | vorangestellt wurde (falls zutreffend), | | | | oder der desmaskierte Prafixname, dem / | | | | vorangestellt wurde. Hiermit wird das | | | | Demaskieren entsprechend den oben | | | | beschriebenen Regeln des Maskierens | | | | absoluter Dateisystempfade implementiert. | +-------------+--------------------------------+-------------------------------------------+ |"%g" | Benutzergruppe | Dies ist der Name der Gruppe, die die | | | | Diensteverwalterinstanz ausfuhrt. Im | | | | Falle des Systemverwalters lost sich dies | | | | auf >>root<< auf. | +-------------+--------------------------------+-------------------------------------------+ |"%G" | Benutzer-GID | Dies ist die numerische GID des | | | | Benutzers, der die | | | | Diensteverwalterinstanz ausfuhrt. Im | | | | Falle des Systemverwalters lost sich dies | | | | auf >>0<< auf. | +-------------+--------------------------------+-------------------------------------------+ |"%h" | Benutzer-Home-Verzeichnis | Dies ist das Home-Verzeichnis des | | | | Benutzers, der die | | | | Diensteverwalterinstanz ausfuhrt. Im | | | | Falle des Systemverwalters lost sich dies | | | | auf >>/root<< auf. Beachten Sie, dass | | | | diese Einstellung nicht von der im | | | | Abschnitt [Service] der Dienste-Unit | | | | konfigurierbaren Einstellung User= | | | | beeinflusst wird. | +-------------+--------------------------------+-------------------------------------------+ |"%H" | Rechnername | Der Rechnername des laufenden Systems zum | | | | Zeitpunkt des Ladens der | | | | Unit-Konfiguration. | +-------------+--------------------------------+-------------------------------------------+ |"%i" | Instanzenname | Fur instanziierte Units ist dies die | | | | Zeichenkette zwischen dem ersten | | | | >>@<<-Zeichen und der Typendung. Leer fur | | | | nichtinstanziierte Units. | +-------------+--------------------------------+-------------------------------------------+ |"%I" | Demaskierter Instanzenname | Identisch zu >>%i<<, aber mit | | | | zuruckgenommener Maskierung. | +-------------+--------------------------------+-------------------------------------------+ |"%j" | Abschliessende Komponente des | Dies ist die Zeichenkette zwischen dem | | | Prafixes | letzten >>-<< und dem Ende des | | | | Prafixnamens. Falls es kein >>-<< gibt, | | | | ist dies zu >>%p<< identisch. | +-------------+--------------------------------+-------------------------------------------+ |"%J" | Nicht maskierte abschliessende | Identisch zu >>%j<<, aber mit | | | Komponente des Prafixes | zuruckgenommener Maskierung. | +-------------+--------------------------------+-------------------------------------------+ |"%l" | Kurzer Rechnername | Der Rechnername des laufenden Systems zum | | | | Zeitpunkt des Ladens der | | | | Unit-Konfiguration, abgeschnitten am | | | | ersten Punkt, um alle Domain-Komponenten | | | | zu entfernen. | +-------------+--------------------------------+-------------------------------------------+ |"%L" | Wurzel des | Dies ist entweder /var/log (fur den | | | Protokollierverzeichnisses | Systemverwalter) oder worauf der Pfad | | | | $XDG_CONFIG_HOME zeigt, mit angehangtem | | | | /log (fur Benutzerverwalter). | +-------------+--------------------------------+-------------------------------------------+ |"%m" | Maschinenkennung | Die Maschinenkennung des laufenden | | | | Systems, formatiert als Zeichenkette. | | | | Siehe machine-id(5) fur weitere | | | | Informationen. | +-------------+--------------------------------+-------------------------------------------+ |"%M" | Betriebssystemabbildkennung | Die Betriebssystemabbildkennung des | | | | laufenden Systems, wie aus dem Feld | | | | IMAGE_ID= in /etc/os-release ausgelesen. | | | | Falls nicht gesetzt, wird es die leere | | | | Zeichenkette. Siehe os-release(5) fur | | | | weitere Informationen. | +-------------+--------------------------------+-------------------------------------------+ |"%n" | Vollstandiger Unit-Name | | +-------------+--------------------------------+-------------------------------------------+ |"%N" | Vollstandiger Unit-Name | Identisch zu >>%n<<, aber mit entfernter | | | | Typendung. | +-------------+--------------------------------+-------------------------------------------+ |"%o" | Betriebssystemkennung | Die Betriebssystemkennung des laufenden | | | | Systems, wie aus dem Feld ID= in | | | | /etc/os-release ausgelesen. Siehe | | | | os-release(5) fur weitere Informationen. | +-------------+--------------------------------+-------------------------------------------+ |"%p" | Prafixname | Fur instanziierte Units bezieht sich das | | | | auf die Zeichenkette vor dem ersten | | | | >>@<<-Zeichen des Unit-Namens. Fur nicht | | | | instanziierte Units identisch zu >>%N<<. | +-------------+--------------------------------+-------------------------------------------+ |"%P" | Nicht maskierter Prafixname | Identisch zu >>%p<<, aber mit | | | | zuruckgenommener Maskierung. | +-------------+--------------------------------+-------------------------------------------+ |"%q" | Schoner Rechnername | Der schone Rechnername des laufenden | | | | Systems zum Zeitpunkt des Ladens der | | | | Unit-Konfiguration, wie aus dem Feld | | | | PRETTY_HOSTNAME= in /etc/machine-info | | | | ausgelesen. Falls nicht gesetzt, wird es | | | | auf den kurzen Rechnernamen gesetzt. | | | | Siehe machine-info(5) fur weitere | | | | Informationen. | +-------------+--------------------------------+-------------------------------------------+ |"%s" | Benutzer-Shell | Dies ist die Shell des Benutzers, der die | | | | Diensteverwalterinstanz ausfuhrt. | +-------------+--------------------------------+-------------------------------------------+ |"%S" | Wurzel des | Dies ist entweder /var/lib (fur den | | | Zustandsverzeichnisses | Systemverwalter) oder worauf der Pfad | | | | $XDG_CONFIG_HOME zeigt (fur | | | | Benutzerverwalter). | +-------------+--------------------------------+-------------------------------------------+ |"%t" | Wurzel des | Dies ist entweder /run/ (fur den | | | Laufzeitverzeichnisses | Systemverwalter) oder worauf der Pfad | | | | >>$XDG_RUNTIME_DIR<< zeigt (fur | | | | Benutzerverwalter). | +-------------+--------------------------------+-------------------------------------------+ |"%T" | Verzeichnis fur temporare | Dies ist entweder /tmp oder der Pfad, auf | | | Dateien | den >>$TMPDIR<<, >>$TEMP<< oder >>$TMP<< | | | | gesetzt ist. (Beachten Sie, dass das | | | | Verzeichnis ohne abschliessenden | | | | Schragstrich angegeben werden kann.) | +-------------+--------------------------------+-------------------------------------------+ |"%u" | Benutzername | Dies ist der Name des Benutzers, der die | | | | Diensteverwalterinstanz ausfuhrt. Im | | | | Falle des Systemverwalters lost sich dies | | | | auf >>root<< auf. Beachten Sie, dass | | | | diese Einstellung nicht von der im | | | | Abschnitt [Service] der Dienste-Unit | | | | konfigurierbaren Einstellung User= | | | | beeinflusst wird. | +-------------+--------------------------------+-------------------------------------------+ |"%U" | Benutzer-UID | Dies ist die numerische UID des | | | | Benutzers, der die | | | | Diensteverwalterinstanz ausfuhrt. Im | | | | Falle des Systemverwalters lost sich dies | | | | auf >>0<< auf. Beachten Sie, dass diese | | | | Einstellung nicht von der im Abschnitt | | | | [Service] der Dienste-Unit | | | | konfigurierbaren Einstellung User= | | | | beeinflusst wird. | +-------------+--------------------------------+-------------------------------------------+ |"%v" | Kernelveroffentlichung | Identisch zur Ausgabe von uname -r. | +-------------+--------------------------------+-------------------------------------------+ |"%V" | Verzeichnis fur grossere und | Dies ist entweder /var/tmp oder der Pfad, | | | dauerhafte temporare Dateien | auf den >>$TMPDIR<<, >>$TEMP<< oder | | | | >>$TMP<< gesetzt ist. (Beachten Sie, dass | | | | das Verzeichnis ohne abschliessenden | | | | Schragstrich angegeben werden kann.) | +-------------+--------------------------------+-------------------------------------------+ |"%w" | Betriebssystemversionskennung | Die Betriebssystemversionskennzeichnung | | | | des laufenden Systems, wie aus dem Feld | | | | VERSION_ID= in /etc/os-release | | | | ausgelesen. Falls nicht gesetzt, wird es | | | | die leere Zeichenkette. Siehe | | | | os-release(5) fur weitere Informationen. | +-------------+--------------------------------+-------------------------------------------+ |"%W" | Betriebssystemvariantenkennung | Die Betriebssystemvariantenkennung des | | | | laufenden Systems, wie aus dem Feld | | | | VARIANT_ID= in /etc/os-release | | | | ausgelesen. Falls nicht gesetzt, wird es | | | | die leere Zeichenkette. Siehe | | | | os-release(5) fur weitere Informationen. | +-------------+--------------------------------+-------------------------------------------+ |"%y" | Der Pfad zum Fragment. | Dies ist der Pfad dorthin, wo sich der | | | | Hauptteil der Unit-Datei befindet. Fur | | | | verlinkte Unit-Dateien wird der echte | | | | Pfad ausserhalb der | | | | Unit-Suchverzeichnisse verwandt. Fur | | | | Units ohne Fragementdateien wird der | | | | Kennzeichner einen Fehler hervorrufen. | +-------------+--------------------------------+-------------------------------------------+ |"%Y" | Das Verzeichnis des Fragement. | Dies ist der Verzeichnisanteil von | | | | >>%y<<. | +-------------+--------------------------------+-------------------------------------------+ |"%%" | Einzelnes Prozentzeichen | Verwenden Sie >>%%<< anstelle von >>%<<, | | | | um ein einzelnes Prozentzeichen | | | | anzugeben. | +-------------+--------------------------------+-------------------------------------------+ BEISPIELE Beispiel 1. Units erlauben, freigegeben zu werden Der nachfolgende Schnipsel (hervorgehoben) erlaubt es einer Unit (z.B. foo.service), mittels systemctl enable freigegeben zu werden: [Unit] Description=Foo [Service] ExecStart=/usr/sbin/foo-daemon [Install] WantedBy=multi-user.target Nach der Ausfuhrung von systemctl enable verlinkt ein Symlink /etc/systemd/system/multi-user.target.wants/foo.service auf die tatsachlich zu erstellende Unit-Datei. Er teilt Systemd mit, die Unit beim Starten von multi-user.target hereinzuziehen. Das inverse systemctl disable wird diesen Symlink wieder entfernen. Beispiel 2. Lieferanteneinstellungen ausser Kraft setzen Es gibt zwei Methoden, die Lieferanteneinstellungen in Unit-Dateien ausser Kraft zu setzen: Kopieren der Unit-Datei aus /usr/lib/systemd/system nach /etc/systemd/system und Anpassen der gewahlten Einstellungen oder alternativ durch Anlage eines Verzeichnisses namens Unit.d/ innerhalb von /etc/systemd/system und darin einer Erganzungsdatei Name.conf, die nur die speziellen Einstellungen, an denen Sie interessiert sind, andert. Beachten Sie, dass diese Erganzungsdateien in lexikalischer Reihenfolge ihres Dateinamens verarbeitet werden, falls mehrere vorhanden sind. Der Vorteil der ersten Methode besteht darin, dass normalerweise die komplette Unit ausser Kraft gesetzt wird und die Unit des Lieferanten uberhaupt nicht mehr ausgewertet wird. Der Nachteil besteht darin, dass Verbesserungen an der Unit-Datei durch den Lieferanten bei Aktualisierungen nicht mehr automatisch mit berucksichtigt werden. Der Vorteil der zweiten Methode besteht darin, dass nur die genau gewunschten Einstellungen ausser Kraft gesetzt und Aktualisierungen vom Lieferanten angewandt werden. Dies hat den Nachteil, dass zukunftige Aktualisierungen vom Lieferanten zu den lokalen Anderungen inkompatibel sein konnten. Dies gilt auch fur Benutzerinstanzen von Systemd, aber mit anderen Orten fur die Unit-Dateien. Siehe den Abschnitt uber Unit-Ladepfade fur weitere Details. Lassen Sie uns annehmen, dass es eine vom Lieferanten bereitgestellte Unit /usr/lib/systemd/system/httpd.service mit dem folgenden Inhalt gibt: [Unit] Description=Ein HTTP-Server After=remote-fs.target sqldb.service Requires=sqldb.service AssertPathExists=/srv/webserver [Service] Type=notify ExecStart=/usr/sbin/some-fancy-httpd-server Nice=5 [Install] WantedBy=multi-user.target Jetzt mochten Sie als Administrator einige Einstellungen andern: zuerst konnte in der lokalen Installation /srv/webserver nicht existieren, da der Webserver stattdessen auf /srv/www konfiguriert ist. Zweitens hangt der HTTP-Server aufgrund der lokalen Konfiguration auch von einem Arbeitsspeicherzwischenspeicherdienst, memcached.service ab, der (mittels Requires=) hereingezogen und auch entsprechend angeordnet (mittels After=) werden soll. Drittens mochte der Administrator zur weiteren Hartung des Dienstes die Einstellung PrivateTmp= (siehe systemd.exec(5) fur Details) setzen. Schliesslich mochte der Administrator die Einstellung des Nice-Wertes des Dienstes auf den Vorgabewert 0 zurucksetzen. Die erste Moglichkeit besteht darin, die Unit-Datei nach /etc/systemd/system/httpd.service zu kopieren und die ausgewahlten Einstellungen zu andern: [Unit] Description=Ein HTTP-Server After=remote-fs.target sqldb.service memcached.service Requires=sqldb.service memcached.service AssertPathExists=/srv/www [Service] Type=notify ExecStart=/usr/sbin/some-fancy-httpd-server Nice=0 PrivateTmp=yes [Install] WantedBy=multi-user.target Alternativ konnte der Administrator eine Erganzungsdatei in /etc/systemd/system/httpd.service.d/local.conf mit folgendem Inhalt erstellen: [Unit] After=memcached.service Requires=memcached.service # Setzt alle Zusicherungen zuruck and fugt dann die gewunschten Bedingungen hinzu AssertPathExists= AssertPathExists=/srv/www [Service] Nice=0 PrivateTmp=yes Beachten Sie, dass bei Einstellungen, die als Liste ausgewertet werden (und die keine Abhangigkeit sind), wie AssertPathExists= (oder z.B. ExecStart= in Dienste-Units), zuerst die Liste bereinigt werden muss, bevor Eintrage (ohne den zu entfernenden) hinzugefugt werden, falls Sie einen Eintrag von einer Einstellung entfernen mochten. Abhangigkeiten (After=, usw.) konnen nicht auf die leere Liste zuruckgesetzt werden, daher konnen in Erganzungsdateien Abhangigkeiten nur hinzugefugt werden. Falls Sie eine Abhangigkeit entfernen mochten, mussen Sie die gesamte Unit ausser Kraft setzen. Beispiel 3. Erganzungen auf oberster Ebene mit Vorlagen-Units Typbezogene Erganzungen auf oberster Stufe konnen zum Andern einiger Aspekte aller Units eines bestimmten Typs verwandt werden. Wird beispielsweise das Verzeichnis /etc/systemd/system/service.d/ mit einer Erganzungsdatei erstellt, konnen die Inhalte der Erganzungsdatei auf alle Dienste-Units angewandt werden. Dies kann weitergetrieben werden, indem die Erganzung auf oberster Stufe eine sekundare Hilfs-Unit realisiert. Betrachten Sie beispielsweise die folgende Gruppe von Units und Erganzungsdateien, bei denen eine Abhangigkeit OnFailure= fur alle Dienste-Units installiert wird. /etc/systemd/system/failure-handler@.service: [Unit] Description=Mein Fehler-Handler fur %i [Service] Type=oneshot # Ausfuhrung einiger besonderer Aktionen, wenn sich %i unerwartet beendet. ExecStart=/usr/sbin/myfailurehandler %i Eine Instanz von failure-handler@.service kann als eine Abhangigkeit OnFailure= fur alle Dienste-Units hinzugefugt werden. /etc/systemd/system/service.d/10-all.conf: [Unit] OnFailure=failure-handler@%N.service Nach der Ausfuhrung von systemctl daemon-reload werden jetzt alle Dienste ein Abhangigkeit OnFailure= auf failure-handler@%N.service erlangt haben. Die Vorlage-Instanz-Units werden auch die Abhangigkeit erlangt haben, die zu der Erstellung einer rekursiven Abhangigkeitskette gefuhrt hat. Systemd wird versuchen, diese rekursiven Abhangigkeitsketten zu erkennen, bei der eine Vorlagen-Unit direkt und rekursiv von sich selbst abhangt und wird solche Abhangigkeiten automatisch entfernen, falls es sie findet. Falls Systemd die rekursive Abhangigkeitskette nicht selbst erkennt, kann die Kette manuell unterbrochen werden, indem die Erganzung fur die Vorlagen-Instanz-Units mittels Symlinks auf /dev/null unterbrochen wird: mkdir /etc/systemd/system/failure-handler@.service.d/ ln -s /dev/null /etc/systemd/system/failure-handler@.service.d/10-all.conf systemctl daemon-reload Dies stellt sicher, dass eine Instanz von failure-handler@.service fehlschlagt, falls sie keine Instanz namens failure-handler@failure-handler.service auslost. SIEHE AUCH systemd(1), systemctl(1), systemd-system.conf(5), systemd.special(7), systemd.service(5), systemd.socket(5), systemd.device(5), systemd.mount(5), systemd.automount(5), systemd.swap(5), systemd.target(5), systemd.path(5), systemd.timer(5), systemd.scope(5), systemd.slice(5), systemd.time(7), systemd-analyze(1), capabilities(7), systemd.directives(7), uname(1) ANMERKUNGEN 1. Schnittstellenportabilitats- und -stabilitatszusage https://systemd.io/PORTABILITY_AND_STABILITY/ 2. Systemd- und Speicher-Daemons fur das Wurzeldateisystem https://systemd.io/ROOT_STORAGE_DAEMONS 3. System- und Dienste-Zugangsberechtigungen https://systemd.io/CREDENTIALS 4. PSI (Pressure Stall Information) https://docs.kernel.org/accounting/psi.html 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.UNIT(5)