oracular (5) systemd.unit.5.gz

Provided by: manpages-de_4.23.1-1_all bug

BEZEICHNUNG

       systemd.unit - Unit-Konfiguration

ÜBERSICHT

       Dienst.service, Socket.socket, Gerät.device, Einhängung.mount, Selbsteinhängung.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 über einen
       Dienst, ein Socket, ein Gerät, einen Einhängepunkt, einen Selbsteinhängepunkt, eine Auslagerungsdatei
       oder -partition, ein Startziel, einen überwachten Dateipfad, einen von systemd(1) gesteuerten und
       überwachten Timer, eine Ressourcenverwaltungsscheibe oder eine Gruppe von extern erstellten Prozessen
       kodiert. Siehe systemd.syntax(7) für eine allgemeine Beschreibung der Syntax.

       Diese Handbuchseite führt die gemeinsamen Konfigurationsoptionen aller Unit-Typen auf. Diese Optionen
       müssen in den Abschnitten [Unit] oder [Install] der Unit-Dateien konfiguriert werden.

       Zusätzlich zu den hier beschriebenen generischen Abschnitten [Unit] und [Install] kann jede Unit einen
       typspezifischen Abschnitt haben, z.B. [Service] für eine Dienste-Unit. Siehe die respektiven
       Handbuchseiten für 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 während der Compilierung bestimmt werden, geladen.
       Dies wird im nächsten Abschnitt beschrieben.

       Gültige 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 gültigen Zeichen
       (ASCII-Buchstaben, Ziffern, »:«, »-«, »_«, ».« und »\« bestehen). Die Gesamtlänge des Unit-Names
       einschließlich der Endung darf 255 Zeichen nicht überschreiten. Die Unit-Typ-Endung muss entweder
       ».service«, ».socket«, ».device«, ».mount«, ».automount«, ».swap«, ».target«, ».path«, ».timer«, ».slice«
       oder ».scope« sein.

       Unit-Namen können 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 Einfügung 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 dürfen zusätzliche zu den hier aufgeführten Optionen enthalten. Falls Systemd auf eine
       unbekannte Option stößt, 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 benötigen die vorangestellte Kennung
       nicht. Anwendungen können dies dazu verwenden, zusätzliche Informationen in den Unit-Dateien aufzunehmen.
       Um auf diese Optionen zuzugreifen, müssen Anwendungen die Unit-Dateien selbst auswerten.

       Aliase (alternative Namen) können für 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 während der Installation als ein Symlink erstellt wird,
       so dass systemd auf die Anfrage über 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 über einen Alias mit entweder multi-user.target oder
       graphical.target verbunden, um auszuwählen, was standardmäßig gestartet wird. Aliasnamen können in
       Befehlen wie disable, start, stop, status und ähnlichen und in allen Unit-Abhängigkeitsanweisungen
       einschließlich Wants=, Requires=, Before=, After= verwandt werden. Aliase können nicht mit dem Befehl
       preset verwandt werden.

       Alias unterliegen den folgenden Beschränkungen: 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 für 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 für diese spezielle Instanz
       ein Alias angelegt, während 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 für eine gegebene Unit und alle ihre Aliase definiert ist. Das Ziel des
       Alias-Symlinks muss auf einen gültigen 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 für weitere Details. Beachten Sie, dass die Zieldatei nicht
       existieren könnte, d.h. der Symlink hängen könnte.

       Zusätzlich können Unit-Dateien Aliase mittels der Anweisung Alias= im Abschnitt [Install] festlegen. Wenn
       die Unit aktiviert ist, werden Symlinks für 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 gedrückt wird, systemd nach ctrl-alt-del.service suchen und reboot.service
       ausführen wird. systemd schaut während des normalen Betriebs überhaupt nicht in den Abschnitt [Install],
       daher haben sämtliche Direktiven in diesem Abschnitt nur durch während 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 verknüpft sind, werden implizit als
       Abhängigkeiten vom Typ Wants= für die Unit hinzugefügt. Eine ähnliche Funktionalität existiert auch für
       Abhängigkeiten vom Typ Requires=, die Verzeichnisendung ist in diesem Fall .requires/. Diese
       Funktionalität ist nützlich, um Units in den Start von anderen Units einzuhängen, ohne ihre Unit-Dateien
       zu verändern. Für Details über die Semantik von Wants= und Requires= siehe unten. Die bevorzugte Art,
       Symlinks in den Verzeichnissen .wants/ oder .requires/ erfolgt durch die Angabe der Abhängigkeit 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 gültige Unit-Instanz
       zu bilden. Das Ziel von Symlinks in .wants/ oder .requires/ muss daher auf einen gültigen Unit-Dateiort
       zeigen, d.h. der Symlink-Zielname muss die beschriebenen Anforderungen erfüllen und der Zielpfad muss in
       einem der Unit-Suchpfade liegen, siehe nachfolgenden UNIT-DATEI-LADEPFAD für weitere Details. Beachten
       Sie, dass die Zieldatei nicht existieren könnte, d.h. der Symlink hängen könnte.

       Zusammen mit einer Unit-Datei foo.service kann ein »Ergänzungs«-Verzeichnis foo.service.d/ existieren.
       Alle Dateien mit der Endung ».conf« aus diesem Verzeichnis in alphanumerischer Reihenfolge
       zusammengeführt und ausgewertet, nachdem die Unit-Datei selbst ausgewertet wurde. Dies ist nützlich, um
       die Konfigurationseinstellungen für eine Unit zu verändern oder zu ergänzen, ohne die Unit-Dateien selbst
       verändern zu müssen. Jede Ergänzungsdatei muss geeignete Abschnittskopfzeilen enthalten. Für
       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. Für 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 für einen Unit-Namen
       foo-bar-baz.service.d/ nicht nur der reguläre Ergänzungsverzeichnis foo-bar-baz.service.d/ durchsucht,
       sondern auch foo-bar-.service.d/ als auch foo-.service.d/ durchsucht. Dies ist nützlich, um gemeinsame
       Ergänzungen für eine Gruppe von zusammengehörigen Units zu definieren, deren Namen mit einem gemeinsamen
       Anfang beginnen. Dieses Schema ist insbesondere für Einhänge-, Automount- und Scheiben-Units, deren
       systematische Benennungsstruktur rund um Bindestriche als Komponententrenner aufgebaut ist, nützlich.
       Beachten Sie, dass gleichbenannte Ergänzungsdateien weiter unten in der Anfangshierarchie solche weiter
       oben außer Kraft setzen, d.h. foo-bar-.service.d/10-override.conf setzt foo-.service.d/10-override.conf
       außer Kraft.

       Im Falle von (den oben beschriebenen) Unit-Aliasen, werden die Ergänzungen für die Aliasnamen und alle
       Aliasse geladen. Falls beispielsweise default.target ein Alias für graphical.target ist, würden
       default.target.d/, default.target.wants/, default.target.requires/, graphical.target.d/,
       graphical.target.wants/, graphical.target.requires/ alle gelesen. Für Vorlagen werden die Ergänzungen für
       die Vorlage, alle Vorlagen-Aliasse, die Vorlageninstanz und alle Alias-Instanzen gelesen. Wird nur für
       eine bestimmte Vorlageninstanz ein Alias angelegt, dann werden die Ergänzungen für die Zielvorlage, die
       Zielvorlageninstanz und die Alias-Vorlageninstanz gelesen.

       Zusätzlich zu /etc/systemd/system können Ergänzungs-».d/«-Verzeichnisse in die Verzeichnisse
       /usr/lib/systemd/system oder /run/systemd/system abgelegt werden. Ergänzungsdateien in /etc/ haben
       Vorrang vor denen in /run/, die wiederum Vorrang vor denen in /usr/lib/ haben. Ergänzungsdateien unter
       all diesen Verzeichnissen haben Vorrang vor der Haupt-Netdev-Datei, wo auch immer sich diese befindet.
       Mehrere Ergänzungsdateien mit verschiedenen Namen werden in lexikographischer Reihenfolge angewandt,
       unabhängig von dem Verzeichnis, in dem sie sich befinden.

       Units unterstützen auch ein Ergänzungs-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 verändern oder zu ergänzen. Die Formatierung und die Vorrangregeln bei der Anwendung von
       Ergänzungskonfigurationen folgen dem oben definiertem. Dateien in Typ.d/ haben niedrigeren Vorrang im
       Vergleich zu Dateien in namensspezifischen Außerkraftsetzungsverzeichnissen. Es gelten die normalen
       Regeln: mehrere Ergänzungsdateien mit verschiedenen Namen werden in lexikographischer Reihenfolge
       angewandt, unabhängig davon, in welchem Verzeichnis sie sich befinden, daher gilt eine Datei in Typ.d/
       für eine Unit nur, falls es keine Ergänzung oder Maskierung mit diesem Namen in Verzeichnissen mit
       höherem Vorrang gibt. Siehe Beispiele.

       Beachten Sie, dass Systemd zwar ein flexibles Abhängigkeitssystem zwischen Units bereitstellt, es aber
       empfohlen wird, diese Funktionalität nur sparsam zu verwenden und stattdessen auf Techniken wie
       Bus-basierte oder Socket-basierte Aktivierung zu setzen, wodurch Abhängigkeiten implizit werden und damit
       sowohl ein einfacheres als auch flexibleres System entsteht.

       Wie oben erwähnt können 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 wörtlichen Dateinamen in dem Dateisystem suchen. Falls das zu keinem
       Erfolg führt und der Unit-Name das Zeichen »@« enthält, 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, können Sie den
       speziellen Kennzeichner »%i« in vielen Konfigurationsoptionen verwenden. Siehe unten für Details.

       Falls eine Unit-Datei leer ist (d.h. die Größe 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 unmöglich zu machen, sie sogar manuell zu starten.

       Das Unit-Dateiformat wird durch die Schnittstellenportabilitäts- und -stabilitätszusage[1] abgedeckt.

ZEICHENKETTENMASKIERUNG FÜR DIE AUFNAHME IN UNIT-NAMEN

       Manchmal ist es nützlich, eine beliebige Zeichenkette in Unit-Namen umzuwandeln. Um dies zu unterstützen,
       wird eine Zeichenkettenmaskierungsmethode verwandt, um Zeichenketten, die beliebige Byte-Werte (außer
       NUL) enthalten, in gültige Namen und ihren begrenzten Zeichensatz umzuwandeln. Ein häufiger Spezialfall
       sind Unit-Namen, die Pfade zu Objekten in der Dateisystemhierarchie widerspiegeln. Beispiel: eine
       Geräte-Unit dev-sda.device bezieht sich auf ein Gerät mit dem Geräteknoten /dev/sda in dem Dateisystem.

       Der Maskieralgorithmus funktioniert wie folgt: in einer gegebenen Zeichenkette wird jedes »/«-Zeichen
       durch »-« und alle anderen Zeichen außer den alphanumerischen ASCII-Zeichen, »:«, »_« oder ».« werden
       durch ihr C-artige »\x2d«-Maskierung ersetzt. Wenn ».« als erstes Zeichen in der maskierten Zeichenkette
       auftauchen würde, wird es zusätzlich 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. Zusätzlich werden alle
       führenden, abschließenden 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 für Pfad- und Nichtpfadzeichenketten). Verwenden Sie
       systemd-escape --path, um Pfade zu maskieren und andernfalls systemd-escape ohne --path.

AUTOMATISCHE ABHÄNGIGKEITEN

   Implizite Abhängigkeiten
       Eine Reihe von Unit-Abhängigkeiten werden implizit aufgebaut, abhängig vom Unit-Typ und der
       Unit-Konfiguration. Diese impliziten Abhängigkeiten können die Unit-Konfiguration erleichtern. Bitte
       lesen Sie den Abschnitt »Implizite Abhängigkeiten« in der Handbuchseite des jeweiligen Unit-Typs.

       Beispielsweise erlangen Dienste-Units mit Type=dbus automatisch Abhängigkeiten vom Typ Requires= und
       After= von dbus.socket. Siehe systemd.service(5) für Details.

   Standardabhängigkeiten
       Standardabhängigkeiten sind ähnlich impliziten Abhängigkeiten, können aber durch Setzen von
       DefaultDependencies= auf yes (die Vorgabe) und no an- und abgeschaltet werden, während implizite
       Abhängigkeiten immer wirksam sind. Siehe Abschnitt »Standard-Abhängigkeiten« in den jeweiligen
       Handbuchseiten für den Effekt der Aktivierung von DefaultDependencies= in jedem Unit-Typ.

       Beispielsweise werden Ziel-Units alle konfigurierten Abhängigkeiten des Typs Wants= oder Requires= mit
       Abhängigkeiten vom Typ After= ergänzen. Siehe systemd.target(5) für Details. Beachten Sie, dass dieses
       Verhalten durch Setzen von DefaultDependencies=no in den festgelegten Units abgewählt werden kann. Es
       kann auch gezielt über eine explizite Abhängigkeit Before= außer Kraft gesetzt werden.

UNIT-DATEI-LADEPFAD

       Unit-Dateien werden von einer Reihe von Pfaden geladen, die während der Kompilierung bestimmt werden, wie
       dies in den zwei Tabellen unten beschrieben ist. Unit-Dateien, die in früher aufgeführten Verzeichnissen
       gefunden werden, setzen Dateien mit dem gleichen Namen in Verzeichnissen, die weiter unten in der Liste
       aufgeführt sind, außer Kraft.

       Wenn die Variable $SYSTEMD_UNIT_PATH gesetzt ist, setzt der Inhalt dieser Variable den Unit-Ladepfad
       außer Kraft. Falls $SYSTEMD_UNIT_PATH mit einer leeren Komponente (»:«) endet, wird der normale
       Unit-Ladepfad an den Inhalt der Variablen angehängt.

       Tabelle 1.  Ladepfad beim Betrieb im Systemmodus (--system).
       ┌──────────────────────────────┬───────────────────────────────────────┐
       │PfadBeschreibung                          │
       ├──────────────────────────────┼───────────────────────────────────────┤
       │/etc/systemd/system.control   │ Mittels Dbus-API erstellte dauerhafte │
       ├──────────────────────────────┤ und flüchtige Konfiguration           │
       │/run/systemd/system.control   │                                       │
       ├──────────────────────────────┼───────────────────────────────────────┤
       │/run/systemd/transient        │ Dynamische Konfiguration für          │
       │                              │ flüchtige Units                       │
       ├──────────────────────────────┼───────────────────────────────────────┤
       │/run/systemd/generator.early  │ Erstellte Units mit hoher Priorität   │
       │                              │ (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         │
       │                              │ Priorität (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         │
       │                              │ Priorität (siehe late-dir in          │
       │                              │ systemd.generator(7))                 │
       └──────────────────────────────┴───────────────────────────────────────┘

       Tabelle 2.  Ladepfad bei der Ausführung im Benutzermodus (--user).
       ┌─────────────────────────────────────────┬───────────────────────────────────────┐
       │PfadBeschreibung                          │
       ├─────────────────────────────────────────┼───────────────────────────────────────┤
       │$XDG_CONFIG_HOME/systemd/user.control    │ Dauerhafte und flüchtige              │
       │oder ~/.config/systemd/user.control      │ Konfiguration, die mittels des        │
       ├─────────────────────────────────────────┤ DBus-APIs erstellt wird               │
       │$XDG_RUNTIME_DIR/systemd/user.control    │ (($XDG_CONFIG_HOME wird verwandt,     │
       │                                         │ falls gesetzt, andernfalls ~/.config) │
       ├─────────────────────────────────────────┼───────────────────────────────────────┤
       │$XDG_RUNTIME_DIR/systemd/transient       │ Dynamische Konfiguration für          │
       │                                         │ flüchtige Units                       │
       ├─────────────────────────────────────────┼───────────────────────────────────────┤
       │$XDG_RUNTIME_DIR/systemd/generator.early │ Erstellte Units mit hoher Priorität   │
       │                                         │ (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       │ Zusätzliche                           │
       │/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         │
       │                                         │ Priorität (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         │ Zusätzliche Datenverzeichnisse, wie   │
       │/usr/local/share/systemd/user und        │ 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 für jedes $dir in      │ Zusätzliche Orte für installierte     │
       │$XDG_DATA_DIRS                           │ Benutzer-Units, einen für 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         │
       │                                         │ Priorität (siehe late-dir in          │
       │                                         │ systemd.generator(7))                 │
       └─────────────────────────────────────────┴───────────────────────────────────────┘

       Die Gruppe der Ladepfade für die Benutzerverwalterinstanzen kann mittels verschiedener Umgebungsvariablen
       ergänzt oder geändert werden. Und Umgebungsvariablen können wiederum mittels Umgebungsgeneratoren gesetzt
       werden, siehe systemd.environment-generator(7). Insbesondere $XDG_DATA_HOME und $XDG_DATA_DIRS können
       leicht mittels systemd-environment-d-generator(8) gesetzt werden. Daher sind die hier aufgeführten
       Verzeichnisse nur die Vorgaben. Um die tatsächlich verwandte Liste, basierend auf den Compiler-Optionen
       und der aktuellen Umgebung, zu sehen, verwenden Sie

           systemd-analyze --user unit-paths

       Desweiteren können zusätzliche 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
       können systemctl link für 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, außer 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 müssen den bestimmten, oben bei der Besprechung von Aliasen aufgeführten Einschränkungen
       genügen, aber das Symlink-Ziel muss nicht existieren. Tatsächlich wird der Pfad zum Symlink-Ziel nicht
       verwandt, außer zu prüfen, ob das Ziel sich innerhalb des Unit-Ladepfades befindet. Im Gegensatz dazu
       bedeutet ein Symlink, der außerhalb des Unit-Ladepfades führt, 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 gültiger 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 gültige 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-MÜLLABFUHR

       Der System- und Diensteverwalter lädt 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 benötigt wird (»Müllabfuhr«). Eine Unit kann über eine Reihe von Mechanismen referenziert
       werden:

        1. Eine andere geladene Unit referenziert sie mit einer Abhängigkeit wie After=, Wants=, …

        2. Die Unit startet, läuft, startet sich neu oder stoppt derzeit.

        3. Die Unit ist derzeit im Zustand failed. (Siehe aber unten.)

        4. Ein Auftrag für die Unit ist anhängig.

        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 für ewige Units
           sind die Wurzeleinhänge-Unit -.mount und die Bereichs-Unit init.scope, in der der Diensteverwalter
           selbst lebt.

        7. Die Unit hat ihr zugeordnete laufende Prozesse.

       Die Müllabfuhrlogik kann mit der Option CollectMode= verändert 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
       Ausführungsergebnisse, wie Exit-Codes, Exit-Signale und Resourcenverbrauch- und andere Statistiken,
       verloren gehen, außer für den Anteil, der im Protokolluntersystem gespeichert ist.

       Verwenden Sie systemctl daemon-reload oder einen äquivalenten Befehl, um die Unit-Konfiguration neu zu
       laden, während 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 sämtlicher Laufzeitzustand gespeichert/wiederhergestellt.

[UNIT]-ABSCHNITT-OPTIONEN

       Die Unit-Datei kann einen Abschnitt [Unit] enthalten, der generische Informationen über die Unit
       transportiert, der nicht vom Unit-Typ abhängt:

       Description=
           Ein kurzer menschenlesbarer Titel für die Unit. Dieser kann von systemd (und anderen
           Benutzeroberflächen) als eine für den Benutzer sichtbare Bezeichnung für 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« (für 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 groß geschrieben werden und kein vollständiger Satz oder eine Phrase mit einem kontinuierlichen
           Verb sein. Schlechte Beispiele sind auch »exiting the container« oder »updating the database once per
           day.«.

           Hinzugefügt in Version 201.

       Documentation=
           Eine Leerraum-getrennte Liste von URIs, die Dokumentation für diese Unit oder ihre Konfiguration
           referenzieren. Es werden nur URIs von den Typen »http://«, »https://«, »file:«, »info:«, »man:«
           akzeptiert. Für weitere Informationen über die Syntax dieser URIs siehe uri(7). Die URIs sollten in
           der Reihenfolge der Bedeutung aufgeführt werden, beginnend mit der relevantesten. Es ist eine gute
           Idee, zuerst Dokumentation zu referenzieren, die erklärt, was der Zweck der Unit ist, gefolgt von
           solcher über seine Konfiguration, gefolgt von anderer relevanter Dokumentation. Diese Option kann
           mehr als einmal angegeben werden, in diesem Fall werden die festgelegten Listen von URIs
           zusammengeführt. Falls dieser Option die leere Zeichenkette zugewiesen wird, wird die Liste
           zurückgesetzt und alle vorherigen Zuweisungen werden keinen Effekt haben.

           Hinzugefügt in Version 201.

       Wants=
           Konfiguriert (schwache) Anforderungsabhängigkeiten auf andere Units. Diese Option darf mehr als
           einmal angegeben werden oder mehrere, durch Leerraum getrennte Units können in einer Option angegeben
           werden, in diesem Fall werden Abhängigkeiten für alle aufgeführten Namen erstellt. Abhängigkeiten
           dieses Typs können auch außerhalb von Unit-Konfigurationsdateien hinzugefügt werden, indem ein
           Symlink auf ein die Unit-Datei begleitendes .wants/-Verzeichnis hinzugefügt wird. Siehe oben für
           Details.

           In dieser Option aufgeführte Units werden gestartet, wenn die konfigurierende Unit es wird. Falls
           allerdings die aufgeführte Unit nicht startet oder der Transaktion nicht hinzugefügt werden kann, hat
           dies keine Auswirkungen auf die Gültigkeit 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
           einzuhängen.

           Beachten Sie, dass Anforderungsabhängigkeiten nicht die Reihenfolge beeinflussen, in der Dienste
           gestartet oder gestoppt werden. Dies muss unabhängig 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 Verzögerung untereinander gestartet, wenn foo.service aktiviert wird.

           Hinzugefügt in Version 201.

       Requires=
           Ähnlich Wants=, erklärt aber eine stärkerere Anforderungsabhängigkeit. Abhängigkeiten dieser Art
           können auch außerhalb der Unit-Konfigurationsdatei konfiguriert werden, indem ein Symlink auf ein die
           Unit-Datei begleitendes .requires/-Verzeichnis hinzugefügt wird.

           Falls diese Unit aktiviert wird, werden die aufgeführten Units ebenfalls aktiviert. Falls die
           Aktivierung einer der anderen Units fehlschlägt und eine Ordnungsabhängigkeit After= auf die
           fehlgeschlagene Unit gesetzt ist, dann wird diese Unit nicht gestartet. Darüberhinaus wird diese Unit
           gestoppt (oder neu gestartet), falls eine der anderen Units explizit gestoppt (oder neu gestartet)
           wird, unahängig 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 Abhängigkeitstyp nicht impliziert, dass andere Units immer im aktiven
           Zustand sein müssen, wenn diese Unit läuft. Insbesondere: Fehlschlagende Bedingungsüberprüfungen (wie
           ConditionPathExists=, ConditionPathIsSymbolicLink=, … — siehe unten) führen nicht dazu, dass der
           Start einer Unit mit einer Requires=-Abhängigkeit darauf fehlschlägt. Auch können sich einige
           Unit-Typen von selbst deaktivieren (beispielsweise kann sich ein Diensteprozess entscheiden, sich
           sauber zu beenden, oder ein Gerät könnte von einem Benutzer ausgesteckt werden), was nicht an die
           Units mit einer Requires=-Abhängigkeit übertragen wird. Verwenden Sie den Abhängigkeitstyp 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).

           Hinzugefügt in Version 201.

       Requisite=
           Ähnlich zu Requires=. Falls die hier aufgeführten Units noch nicht gestartet wurden, werden sie nicht
           gestartet und der Start dieser Unit wird sofort fehlschlagen. Requisite= impliziert keine
           Ordnungsabhängigkeit, 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 Abhängigkeit als
           RequisiteOf=a.service in der Eigenschaftsliste von b.service angezeigt. RequisiteOf=-Abhängigkeiten
           können nicht direkt festgelegt werden.

           Hinzugefügt in Version 201.

       BindsTo=
           Konfiguriert Anforderungsabhängigkeiten, im Stil sehr ähnlich zu Requires=. Allerdings ist dieser
           Abhängigkeitstyp stärker: Zusätzlich 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 plötzlich in einen inaktiven Zustand eintritt, auch gestoppt wird. Units können
           plötzlich und unerwartet aus verschiedenen Gründen in inaktive Zustände eintreten: Der Hauptprozess
           einer Dienste-Unit könnte sich aus eigenem Antrieb beenden, das zugrundeliegende Gerät einer
           Geräte-Unit könnte ausgesteckt werden oder der Einhängepunkt einer Einhänge-Unit könnte ohne
           Beteiligung des System- und Diensteverwalters ausgehängt werden.

           Bei der Verwendung in Verbindung mit After= auf die gleiche Unit ist das Verhalten von BindsTo= sogar
           noch stärker. 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 plötzlich in einen inaktiven Zustand eintritt, sondern auch, die an
           eine andere Unit angebunden ist, die aufgrund einer nicht erfüllten Bedingungsprüfung (wie
           ConditionPathExists=, ConditionPathIsSymbolicLink=, … \n siehe unten) übersprungen wird, gestoppt
           wird, sollte sie laufen. Daher ist es in vielen Fällen am besten, BindsTo= mit After= zu kombinieren.

           Wenn BindsTo=b.service auf a.service  benutzt wird, wird diese Abhängigkeit als BoundBy=a.service in
           der Eigenschaftsliste von b.service angezeigt. BoundBy=-Abhängigkeiten können nicht direkt festgelegt
           werden.

           Hinzugefügt in Version 201.

       PartOf=
           Konfiguriert Abhängigkeiten ähnlich zu Requires=, aber begrenzt auf das Stoppen und Neustarten von
           Units. Wenn Systemd die hier aufgeführten Units stoppt oder neustartet, wird die Aktion zu dieser
           Unit weitergeleitet. Beachten Sie, dass dies eine Einwegeabhängigkeit ist — Änderungen an dieser Unit
           betreffen nicht die aufgeführten Units.

           Wenn PartOf=b.service auf a.service  benutzt wird, wird diese Abhängigkeit als ConsistsOf=a.service
           in der Eigenschaftsliste von b.service angezeigt. ConsistsOf=-Abhängigkeiten können nicht direkt
           festgelegt werden.

           Hinzugefügt in Version 201.

       Upholds=
           Konfiguriert Abhängigkeiten ähnlich wie Wants=, aber alle in Upholds= aufgeführten Units starten
           immer, wenn sie als inaktiv oder fehlgeschlagen erkannt werden und für sie kein Auftrag in der
           Warteschlange ist so lange diese Unit aktiv ist. Während eine Abhängigkeit Wants= auf eine andere
           Unit eine einmalige Auswirkung hat, wenn diese Unit gestartet wird, hat eine Abhängigkeit Upholds=
           eine dauerhafte Auswirkung, fortwährend 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 Verzögerung und die gewöhnlichen
           Unit-abhängigen Ratenbegrenzungen gelten.

           Wenn Upholds=b.service auf a.service  benutzt wird, wird diese Abhängigkeit als UpheldBy=a.service in
           der Eigenschaftsliste von b.service angezeigt.

           Hinzugefügt in Version 249.

       Conflicts=
           Eine Leerraum-getrennte Liste von Unit-Namen. Konfiguriert negative Anforderungsabhängigkeiten. 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 Ordnungsabhängigkeit impliziert, ähnlich der vorher
           beschriebenen Abhängigkeiten Wants= und Requires=. Das bedeutet, dass eine Abhängigkeit After= oder
           Before= erklärt werden muss, um sicherzustellen, dass die in Konflikt stehende Unit gestoppt wird,
           bevor die andere Unit gestartet wird. Es spielt keine Rolle, welche der Ordnungsabhängigkeiten
           verwandt wird, da Stopp-Aufträge immer vor Start-Aufträgen 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 benötigte Teile der Transaktion sind) oder so
           verändert, dass dies behoben wird (falls eine oder beide Aufträge ein nicht benötigter Teil der
           Transaktion sind). In letzterem Fall wird der Auftrag, der nicht benötigt ist, entfernt, oder falls
           beide nicht benötigt werden, wird die den Konflikt auslösende Unit gestartet und die in Konflikt
           stehende gestoppt.

           Hinzugefügt in Version 201.

       Before=, After=
           Diese beiden Einstellungen erwarten eine Leerraum-getrennte Liste von Unit-Namen. Sie können mehrfach
           angegeben werden, wodurch Abhängigkeiten für alle aufgeführten Namen erstellt werden.

           Diese zwei Einstellungen konfigurieren Ordnungsabhängigkeiten zwischen Units. Falls Unit foo.service
           die Einstellung Before=bar.service enthält und beide Units gestartet werden, wird das Starten von
           bar.service verzögert, bis der Start von foo.service abgeschlossen ist.After= ist das Inverse von
           Before=, d.h. während Before= sicherstellt, dass die konfigurierte Unit gestartet wird, bevor die
           aufgeführten Unit mit dem Starten beginnt, stellt After= das Gegenteil sicher, dass die aufgeführte
           Unit vollständig gestartet ist, bevor die konfigurierte Unit gestartet wird.

           Beim Herunterfahren von zwei Units, zwischen denen eine Ordnungsabhängigkeit 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 Ordnungsabhängigkeit 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 Ordnungsabhängigkeit 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 Fällen vor dem Starten eingeordnet. Falls zwischen zwei Units
           keine Ordnungsabhängigkeit besteht, dann werden sie gleichzeitig heruntergefahren und gestartet und
           es findet keine Ordnung statt. Es hängt vom Unit-Typ ab, wann genau der Start einer Unit
           abgeschlossen ist. Am wichtigsten ist, dass für Dienste-Units das Starten für 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 einschließt (oder ExecStopPost für den Herunterfahr-Fall).

           Beachten Sie, dass diese Einstellungen unabhängig von und orthogonal zu den mit Requires=, Wants=,
           Requisite= oder BindsTo= konfigurierten Anforderungsabhängigkeit sind. Es ist ein häufiges Muster,
           einen Unit-Namen sowohl in die Optionen After= als auch in WantWants= aufzunehmen; in diesem Fall
           wird die aufgeführte Unit vor der Unit, die mit diesen Optionen konfiguriert ist, gestartet.

           Beachten Sie, dass Before=-Abhängigkeiten für Geräte-Units nicht wirksam sind und nicht unterstützt
           werden. Geräte werden im Allgemeinen aufgrund externer Einsteck-Ereignisse verfügbar und Systemd
           erstellt die entsprechende Geräte-Unit unverzüglich.

           Hinzugefügt in Version 201.

       OnFailure=
           Eine Leerraum-getrennte Liste einer oder mehrerer Units, die aktiviert werden, wenn diese Unit den
           Zustand »failed« einnimmt.

           Hinzugefügt in Version 201.

       OnSuccess=
           Eine Leerraum-getrennte Liste einer oder mehrerer Units, die aktiviert werden, wenn diese Unit den
           Zustand »inactive« einnimmt.

           Hinzugefügt 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.

           Hinzugefügt 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.

           Hinzugefügt in Version 249.

       JoinsNamespaceOf=
           Für Units, die Prozesse starten (wie Dienste-Units) werden hier eine oder mehrere andere Units
           aufgeführt, dessen Netzwerk- oder temporärem Namensraum beigetreten werden soll. Falls dies für eine
           Unit festgelegt ist (beispielsweise enthält a.service JoinsNamespaceOf=b.service), dann wird die
           inverse Abhängigkeit (JoinsNamespaceOf=a.service für b.service) impliziert. Dies gilt nur für
           Unit-Typen, die die Anweisungen PrivateNetwork=, NetworkNamespacePath=PrivateIPC=, IPCNamespacePath=
           und PrivateTmp= unterstützen (siehe systemd.exec(5) für Details). Falls eine Unit, die diese
           Einstellung hat, gestartet wird, werden deren Prozesse die gleichen /tmp/-, /var/tmp/-, IPC- und
           Netzwerk-Namensräume wie die aufgeführte gestartete Unit haben. Falls mehrere aufgeführte 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= für sowohl
           die Unit, die dem Namensraum beitritt, als auch die Unit, deren Namensraum beigetreten wird,
           aktiviert ist.

           Hinzugefügt in Version 209.

       RequiresMountsFor=
           Akzeptiert eine Leerraum-getrennte Liste absoluter Pfade. Fügt automatisch Abhängigkeiten vom Typ
           Requires= und After= für alle für den Zugriff auf den angegebenen Pfad benötigten Einhänge-Units
           hinzu.

           Mit noauto markierte Einhängepunkte werden nicht durch local-fs.target automatisch eingehängt, werden
           für den Zweck dieser Option aber weiterhin berücksichtigt, d.h. sie werden von dieser Unit
           hereingezogen.

           Hinzugefügt in Version 201.

       WantsMountsFor=
           Identisch zu RequiresMountsFor=, fügt aber Abhängigkeiten vom Typ Wants= anstelle von Requires=
           hinzu.

           Hinzugefügt in Version 256.

       OnSuccessJobMode=, OnFailureJobMode=
           Akzeptiert einen Wert aus »fail«, »replace«, »replace-irreversibly«, »isolate«, »flush«,
           »ignore-dependencies«, »ignore-requirements«. Standardmäßig »replace«. Gibt an, wie die in
           OnSuccess=/OnFailure= aufgeführten Units in die Warteschlange eingestellt werden. Siehe die Option
           --job-mode= von systemctl(1) für Details über die möglichen Werte. Falls dies auf »isolate« gesetzt
           ist, darf in OnSuccess=/OnFailure= nur eine einzelne Unit aufgeführt werden.

           Hinzugefügt in Version 209.

       IgnoreOnIsolate=
           Akzeptiert ein logisches Argument. Falls true, wird die Unit nicht gestoppt, wenn eine andere Unit
           isoliert wird. Standardmäßig false für Dienste-, Ziel-, Socket-, Timer- und Pfad-Units und true für
           Scheiben-, Bereichs-, Geräte-, Swap-, Einhänge- und Automount-Units.

           Hinzugefügt in Version 201.

       StopWhenUnneeded=
           Akzeptiert ein logisches Argument. Falls true, wird diese Unit gestoppt, wenn sie nicht mehr benutzt
           wird. Beachten Sie, dass Systemd standardmäßig Units nicht stoppt, außer sie stehen in Konflikt zu
           anderen Units oder der Benutzer bittet explizit um ihr Herunterfahren, um die auszuführende Arbeit zu
           minimieren. Falls diese Option gesetzt ist, wird eine Unit automatisch bereinigt, falls keine andere
           aktive Unit sie benötigt. Standardmäßig false.

           Hinzugefügt 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
           zurückgewiesen, erfolgt das Starten oder Beenden allerdings als Abhängigkeit von einer anderen Unit,
           dann wird das Starten oder Beenden erfolgreich sein. Dies ist primär eine Sicherheitsfunktionalität,
           um sicherzustellen, dass der Benutzer nicht versehentlich Units aktiviert, die nicht für direkte
           Aktivierung gedacht sind und nicht versehentlich Units deaktiviert, die nicht zur Beendigung gedacht
           sind. Diese Option ist standardmäßig false.

           Hinzugefügt in Version 201.

       AllowIsolate=
           Akzeptiert ein logisches Argument. Falls true, darf diese Unit mit dem Befehl systemctl isolate
           verwandt werden. Andernfalls wird dies zurückgewiesen. Es ist wahrscheinlich eine gute Idee, dies
           außer für Ziel-Units, die ähnlich wie Runlevel in SysV-Init-Systemen verwandt werden sollen,
           deaktiviert zu lassen, nur als Vorsichtsmaßnahme, um unbenutzbare Systemzustände zu vermeiden. Diese
           Option ist standardmäßig false.

           Hinzugefügt in Version 201.

       DefaultDependencies=
           Akzeptiert ein logisches Argument. Falls yes (die Vorgabe), werden einige Standard-Abhängigkeiten
           implizit für die Unit erstellt. Die tatsächlich erstellten Abhängigkeiten hängen vom Unit-Typ ab. Für
           Dienste-Units stellen diese Abhängigkeiten 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 für Details. Im Allgemeinen
           sollten nur Dienste, die im frühen Systemstart oder beim späten Herunterfahren beteiligt sind, diese
           Option auf no setzen. Es wird nachdrücklich empfohlen, diese Option für den Großteil der häufigen
           Units aktiviert zu lassen. Falls auf no gesetzt, deaktiviert diese Option nicht alle impliziten
           Abhängigkeiten, sondern nur nicht essenzielle.

           Hinzugefügt in Version 201.

       SurviveFinalKillSignal=
           Akzeptiert ein logisches Argument. Standardmäßig no. Falls yes, werden Prozessen, die zu dieser Unit
           gehören, nicht die abschließende Signale »SIGTERM« und »SIGKILL« während der abschließenden
           Herunterfahrphase des Systems gesandt. Diese Funktionalität ersetzt den älteren Mechanismus, der es
           einem Programm erlaubte, wie in Systemd- und Speicher-Daemons für das Wurzeldateisystem[2]
           beschrieben »argv[0][0] = '@'« zu setzen. Letzerer Mechanismus wird allerdings weiterhin unterstützt.

           Hinzugefügt in Version 255.

       CollectMode=
           Optimiert den Algorithmus der »Müllabfuhr« für 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, Aufträgen 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 äquivalenten Befehl auf ihnen aufruft, um den
           Zustand failed zurückzusetzen. Dieses Verhalten wird geändert, 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 Zurücksetzen des Zustands failed nicht notwendig.
           Beachten Sie, dass Unit-Ergebnisse (wie Exit-Codes, Exit-Signale, verbrauchte Ressourcen, …) sofort
           nach Abschluss der Units entsorgt werden, außer dem Anteil, der im Protokollieruntersystem
           gespeichert ist, falls dieser Modus verwandt wird. Standardmäßig inactive.

           Hinzugefügt in Version 236.

       FailureAction=, SuccessAction=
           Konfiguriert die durchzuführende 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 und exit-force erlaubt. Beide Optionen sind standardmäßig none.

           Falls none gesetzt ist, wird keine Aktion ausgelöst. reboot verursacht einen Neustart nach der
           normalen Herunterfahrprozedur (d.h. äquivalent zu systemctl reboot). reboot-force führt zu einem
           erzwungenen Neustart, der alle Prozesse zwangsweise beenden wird, aber beim Neustart kein unsauberes
           Dateisystem erzeugen sollte (d.h. äquivalent zu systemctl reboot -f) und reboot-immediate führt zu
           einer sofortigen Ausführung des Systemaufrufs reboot(2), was zu Datenverlust führen kann (d.h.
           äquivalent zu systemctl reboot -ff). Ähnlich haben poweroff, poweroff-force, poweroff-immediate,
           kexec, kexec-force, halt, halt-force und halt-immediate die Wirkung des Herunterfahrens des Systems
           bzw. der Ausführung von Kexec und Anhalten des Systems mit ähnlichen Semantiken. exit führt dazu,
           dass sich der Verwalter beendet, wobei er der normalen Herunterfahrprozedur folgt, und exit-force
           führt dazu, dass er sich ohne Herunterfahren der Dienste beendet. Wenn exit oder exit-force verwandt
           werden, wird standardmäßig der Exit-Status des Hauptprozesses der Unit (falls dies zutrifft) vom
           Diensteverwalter zurückgeliefert. Dies kann allerdings mit
           FailureActionExitStatus=/SuccessActionExitStatus= außer Kraft gesetzt werden, siehe unten.
           soft-reboot wird eine Neustartkaktion im Anwendungsraum auslösen. soft-reboot-force macht dies auch,
           aber durchläuft vorher die Herunterfahrtransaktion nicht.

           Hinzugefügt in Version 236.

       FailureActionExitStatus=, SuccessActionExitStatus=
           Steuert den Exit-Status, der an den Container-Verwalter zurückgeleitet 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 ausgelöst wird.
           Standardmäßig wird der Exit-Status des Hauptprozesses der auslösenden Unit (falls dies zutrifft)
           weitergeleitet. Akzeptiert einen Wert im Bereich 0…255 oder die leere Zeichenkette, um das
           Standardverhalten zu erbitten.

           Hinzugefügt in Version 240.

       JobTimeoutSec=, JobRunningTimeoutSec=
           JobTimeoutSec= legt eine Zeitüberschreitung für den gesamten Auftrag fest, dessen Ausführung beginnt,
           wenn der Auftrag in die Warteschlange eingereiht wird. JobRunningTimeoutSec= legt eine
           Zeitüberschreitung fest, dessen Ausführung beginnt, wenn der Auftrag in der Warteschlange tatsächlich
           gestartet wird. Falls eine der beiden Begrenzungen erreicht wird, wird der Auftrag abgebrochen, die
           Unit wird allerdings ihren Zustand weder ändern noch in den Modus »failed« eintreten.

           Beide Einstellungen akzeptieren eine Zeitdauer mit der Vorgabeeinheit Sekunden, aber andere Einheiten
           können angegeben werden, siehe systemd.time(5). Die Vorgabe ist »infinity«
           (Auftragszeitüberschreitungen sind deaktiviert), außer für Geräte-Units, bei denen standardmäßig
           JobRunningTimeoutSec= auf DefaultDeviceTimeoutSec= gesetzt ist.

           Hinweis: Diese Zeitüberschreitungen sind unabhängig von allen Unit-spezifischen Zeitüberschreitungen
           (beispielsweise den mit TimeoutStartSec= in Dienste-Units gesetzten Zeitüberschreitungen). Die
           Auftragszeitüberschreitung hat keine Wirkung für die Unit selbst. Oder mit anderen Worten:
           Unit-spezifische Zeitüberschreitungen sind nützlich, um Zustandsänderungen von Units abzubrechen und
           sie zurückzunehmen. Die mit dieser Option gesetzten Auftrags-Zeitüberschreitungen sind allerdings nur
           nützlich, um den Auftrag abzubrechen, der darauf wartet, dass die Unit den Zustand ändert.

           Hinzugefügt in Version 201.

       JobTimeoutAction=, JobTimeoutRebootArgument=
           JobTimeoutAction= konfiguriert optional eine zusätzliche Aktion, die beim Erreichen der
           Zeitüberschreitung unternommen werden soll, siehe die Beschreibung von JobTimeoutSec= und
           JobRunningTimeoutSec= oben. Es akzeptiert die gleichen Werte wie FailureAction=/SuccessAction=.
           Standardmäßig none.

           JobTimeoutRebootArgument= konfiguriert eine optionale Neustartzeichenkette, die an den Systemaufruf
           reboot(2) übergeben wird.

           Hinzugefügt in Version 240.

       StartLimitIntervalSec=Intervall, StartLimitBurst=Häufung
           Konfiguriert die Unit-Startraten-Begrenzung. Units, die häufiger als Häufung innherhalb der Zeitdauer
           Intervall gestartet werden, wird kein weiterer Start erlaubt. Verwenden Sie StartLimitIntervalSec=,
           um das Überprüfungsintervall 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 können angegeben
           werden, siehe systemd.time(5). Der besondere Wert »infinity« kann zur Begrenzung der Gesamtanzahl an
           Startversuchen verwandt werden, selbst wenn diese in großen Zeitintervallen passieren. Standardmäßig
           DefaultStartLimitIntervalSec= in der Verwalterkonfigurationsdatei und kann auf 0 gesetzt werden, um
           jegliche Art von Ratenbegrenzung zu deaktivieren. Häufung ist eine Zahl, die in der
           Verwalterkonfigurationsdatei standardmäßig DefaultStartLimitBurst= ist.

           Diese Konfigurationsoptionen sind insbesondere im Zusammenspiel mit der Diensteeinstellung Restart=
           nützlich (siehe systemd.service(5)); allerdings gelten sie für alle Arten von Starts (einschließlich
           manueller), nicht nur denen, die von der Restart=-Logik ausgelöst werden.

           Beachten Sie, dass nicht versucht wird, Units, die für Restart= konfiguriert ist und die die
           Startbegrenzung erreichen, weiterhin zu starten; allerdings können sie zu einem späteren 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 führt dazu,
           dass der Neustartratenzähler für einen Dienst gelöscht wird, was nützlich ist, wenn der Administrator
           eine Unit manuell starten möchte und die Startbegrenzung damit in die Quere kommt. Ratenbegrenzung
           wird durchgesetzt, nachdem alle Unit-Bedingungsprüfungen ausgeführt wurden. Daher zählen für die
           Ratenbegrenzung Unit-Aktivierungen mit fehlgeschlagenen Bedingungen nicht mit.

           Wenn eine Unit aufgrund der Müllabführlogik entladen wird (siehe oben) werden auch ihre
           Ratenbegrenzungszähler entleert. Das bedeutet, dass die Konfiguration einer Startratenbegrenzung für
           eine Unit, die nicht kontinuierlich referenziert wird, keine Wirkung hat.

           Diese Einstellung gilt nicht für Scheiben-, Ziel-, Geräte- und Bereichs-Units, da dies Unit-Typen
           sind, deren Aktivierung entweder nie fehlschlagen oder nur ein einziges Mal erfolgreich sein darf.

           Hinzugefügt in Version 229.

       StartLimitAction=
           Konfiguriert eine zusätzliche 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 auslösen, außer das der Start nicht erlaubt wird. Standardmäßig none.

           Hinzugefügt in Version 229.

       RebootArgument=
           Konfiguriert das globale Argument für den Systemaufruf reboot(2), falls StartLimitAction= oder
           FailureAction= eine Neustartaktion ist. Dies funktioniert genauso wie das optionale Argument für den
           Befehl systemctl reboot.

           Hinzugefügt in Version 229.

       SourcePath=
           Ein Pfad zu der Konfigurationsdatei, aus der die Unit erstellt wurde. Dies ist hauptsächlich für
           Implementierungen von Generatorwerkzeugen nützlich, die Konfigurationen aus externen
           Konfigurationsdateiformaten in native Unit-Dateien umwandeln. Diese Funktionalität sollte in normalen
           Unit-Dateien nicht verwandt werden.

           Hinzugefügt in Version 201.

   Bedingungen und Zusicherungen
       Unit-Dateien können 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) übersprungen (im Falle von Bedingungen)
       oder mit einer Fehlermeldung abgebrochen (im Falle von Zusicherungen). Fehlschlagende Bedingungen oder
       Zusicherungen führen nicht dazu, dass die Unit in den Zustand »failed« überführt wird. Die Bedingungen
       und Zusicherungen werden zum Zeitpunkt überprüft, zu dem der Start-Auftrag in der Warteschlange
       ausgeführt wird. Die Ordnungsabhängigkeiten werden weiterhin berücksichtigt, so dass andere Units
       weiterhin hereingezogen und einsortiert werden, als ob die Unit erfolgreich aktiviert worden wäre und die
       Bedingungen und Zusicherungen werden zu dem genauen Moment ausgeführt, zu dem die Unit normalerweise
       starten würde und kann daher den Systemzustand nach den einsortierten Units und vor Abschluss der
       Initialisierung validieren. Verwenden Sie Bedingungsausdrücke, um Units zu überspringen, die auf dem
       lokalen System nicht zutreffen, beispielsweise da der Kernel oder die Laufzeitumgebung ihre
       Funktionalität nicht benötigt.

       Falls mehrere Bedingungen festgelegt sind, wird die Unit ausgeführt, falls alle von ihnen zutreffen (d.h.
       es wird ein logisches UND angewandt). Den Bedingungsprüfungen kann ein Pipe-Symbol (|) nach dem
       Gleichheitszeichen verwendet (»Bedingung…=!…«) werden, was dazu führt, dass die Bedingung eine auslösende
       Bedingung wird. Falls für eine Unit mindestens eine auslösende Bedingung definiert ist, dann wird die
       Unit gestartet, falls mindestens eine der auslösenden Bedingungen und alle der regulären (d.h. nicht
       auslösenden) Bedingungen zutreffen. Falls Sie einem Argument das Pipe-Symbol und ein Ausrufezeichen
       voranstellen, muss das Pipe-Symbol zuerst und das Ausrufezeichen als zweites übergeben werden. Falls
       einer der Optionen die leere Zeichenkette zugewiesen wird, wird die Liste der Bedingungen komplett
       zurückgesetzt und alle vorhergehenden Bedingungseinstellungen (jeder Art) werden keine Wirkung haben.

       Die Optionen AssertArchitecture=, AssertVirtualization=, … sind zu Bedingungen ähnlich, führen aber dazu,
       dass Aufträge fehlschlagen (statt übersprungen zu werden). Die fehlgeschlagene Prüfung wird
       protokolliert. Units mit nicht zutreffenden Bedingungen werden als in einem sauberen Zustand betrachtet
       und der Speicher wird aufgeräumt, falls sie nicht referenziert werden. Dies bedeutet, dass bei Abfragen
       die Fehlerbedingung im Zustand der Unit angezeigt werden könnte oder auch nicht.

       Beachten Sie, dass weder eine Zusicherung noch ein Bedingungsausdruck zu Unit-Zustandsänderungen führt.
       Beachten Sie auch, dass beide zum Zeitpunkt geprüft werden, zu dem der Auftrag ausgeführt werden soll,
       d.h. lange nachdem abhängige Aufträge und er selbst in die Warteschlange eingereiht wurden. Daher sind
       weder die Bedingungs- noch die Zusicherungsausdrücke dazu geeignet, Unit-Abhängigkeitsbedingungen
       auszudrücken.

       Der Unterbefehl condition aus systemd-analyze(1) kann zum Testen von Bedingungen und
       Zusicherungsausdrücken verwandt werden.

       Außer für ConditionPathIsSymbolicLink= folgen alle Pfadprüfungen Symlinks.

       ConditionArchitecture=
           Prüft, ob das System auf einer bestimmten Architektur läuft. 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«.

           Verwenden Sie systemd-analyze(1) für die vollständieg Liste der bekannten Architekturen.

           Die Architektur wird aus der durch uname(2) zurückgelieferten 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, für die der Systemverwalter selbst kompiliert wurde, abgebildet. Der Test kann durch
           Voranstellung eines Ausrufezeichens negiert werden.

           Hinzugefügt in Version 201.

       ConditionFirmware=
           Prüft, ob die Firmware des Systems von einem bestimmten Typ ist. Die folgenden Werte sind möglich:

           •   »uefi« passt auf Systeme mit EFI.

           •   »device-tree« passt auf Systeme mit einem Devicetree.

           •   »device-tree-compatible(Wert)« passt auf Systeme mit einem Devicetree, die kompatibel mit »Wert«
               sind.

           •   »smbios-field(Feld Operator Wert)« passt auf Systeme mit einem SMBIOS-Feld, das einen bestimmten
               Wert enthält. 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 »!=« für wörtlichen Zeichenkettenvergleich oder »$=«, »!$=« für
               Shell-artigen Glob-Vergleich. Wert ist der erwartete Wert des SMBIOS-Feldes (möglicherweise
               enthält er Shell-artige Globs, falls »$="/"!$=« verwandt wird.

           Hinzugefügt in Version 249.

       ConditionVirtualization=
           Prüft, ob das System in einer virtualisierten Umgebung ausgeführt wird und testet optional, ob es
           eine bestimmte Implementierung ist. Akzeptiert entweder einen logischen Wert, um zu prüfen, ob es in
           einer virtualisierten Umgebung ausgeführt wird oder entweder »vm« oder »container«, um gegen eine
           generische Art von Virtualisierungslösung zu prüfen 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 prüfen oder »private-users«, um zu prüfen, ob das
           System in einem Benutzernamensraum läuft. Siehe systemd-detect-virt(1) für eine vollständige 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.

           Hinzugefügt 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) zurückgeliefert wird,
           geprüft wird oder eine als Zeichenkette formatierte Maschinenkennung (siehe machine-id(5)). Der Test
           kann durch Voranstellung eines Ausrufezeichens negiert werden.

           Hinzugefügt in Version 244.

       ConditionKernelCommandLine=
           ConditionKernelCommandLine= kann zur Prüfung, 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 müssen. Dies agiert auf der Kernelbefehlszeile, die an die
           Anwendungsebene mittels /proc/cmdline kommuniziert wird, außer wenn der Diensteverwalter als Nutzlast
           eines Container-Verwalters gestartet wird - dann wird stattdessen die Befehlszeile von PID 1 verwandt
           (d.h. /proc/1/cmdline).

           Hinzugefügt in Version 244.

       ConditionKernelVersion=
           ConditionKernelVersion= kann zur Prüfung, 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 (möglicherweise in Anführungszeichen gesetzten) Ausdrücken
           sein. Jeder Ausdruck beginnt mit einem aus »=« oder »!=« für Zeichenkettenvergleiche, »<«, »<=«,
           »==«, »<>«, »>=«, »>« für Versionsvergleiche oder »$=«, »!$=« für Shell-artige Glob-Abgleiche. Falls
           kein Operator festgelegt ist, wird »$=« impliziert.

           Beachten Sie, dass die Verwendung der Kernelversionszeichenkette eine unzuverlässige Art ist, um zu
           bestimmen, welche Funktionalitäten vom Kernel unterstützt werden, da häufig Funktionalitäten eines
           Kernels und Korrekturen von neueren Kerneln der Originalautoren in ältere, von Distributionen
           bereitgestellte Versionen zurückportiert werden. Daher ist die Prüfung inhärent unportierbar und
           sollte nicht für Units verwandt werden, die auf verschiedenen Distributionen verwandt werden könnten.

           Hinzugefügt in Version 244.

       ConditionCredential=
           ConditionCredential= kann zum Prüfen, ob eine Zugangsberechtigung mit dem festgelegten Namen in den
           Diensteverwalter übergeben wurde. Siehe System- und Dienste-Zugangsberechtigungen[3] für Details über
           Zugangsberechtigungen. Falls dies in Diensten für den Systemdiensteverwalter verwandt wird, kann dies
           dazu verwendet werden, Dienste abhängig von den hereingegebenen Zugangsberechtigungen zu machen.
           Falls dies in Diensten für den benutzerbezogenen Diensteverwalter verwandt wird, kann dies dazu
           verwendet werden, Dienste abhängig von den in unit@.service-Diensten, die zu dem Benutzer gehören,
           gegebenen Zugangsberechtigungen zu machen. Das Argument muss ein gültiger Zugangsberechtigungsname
           sein.

           Hinzugefügt in Version 252.

       ConditionEnvironment=
           ConditionEnvironment= kann zur Überprüfung, ob eine bestimmte Umgebungsvariable im Umgebungsblock des
           Diensteverwalters gesetzt (bzw. nicht gesetzt, falls ein Ausführungszeichen vorangestellt wird) ist.
           Das Argument kann ein einzelnes Wort sein, um zu prüfen, ob die Variable mit diesem Namen im
           Umgebungsblock definiert ist, oder eine Zuweisung (»Name=Wert«), um zu prüfen, ob die Variable mit
           genau diesem Wert definiert ist. Beachten Sie, dass der Umgebungsblock des Diensteverwalters selbst
           geprüft wird, d.h. keine mit (wie oben beschrieben) Environment= oder EnvironmentFile= definierte
           Variablen. Dies ist besonders nützlich, wenn der Diensteverwalter innerhalb einer Container-Umgebung
           oder als benutzerbezogener Diensteverwalter läuft, um auf Variablen zu prüfen, die durch den
           einschließenden Container-Verwalter oder PAM übergeben wurden.

           Hinzugefügt in Version 246.

       ConditionSecurity=
           ConditionSecurity= kann zur Prüfung, ob die übergebene Sicherheitstechnik auf dem System aktiviert
           ist, verwandt werden. Derzeit werden die folgenden Werte erkannten:

           Tabelle 3.  Erkannte Sicherheitstechniken
           ┌────────────────┬──────────────────────────────────────┐
           │WertBeschreibung                         │
           ├────────────────┼──────────────────────────────────────┤
           │selinux         │ SELinux MAC                          │
           ├────────────────┼──────────────────────────────────────┤
           │apparmor        │ AppArmor MAC                         │
           ├────────────────┼──────────────────────────────────────┤
           │tomoyo          │ Tomoyo MAC                           │
           ├────────────────┼──────────────────────────────────────┤
           │smack           │ SMACK MAC                            │
           ├────────────────┼──────────────────────────────────────┤
           │ima             │ Integritätsmessungsarchitektur (IMA) │
           ├────────────────┼──────────────────────────────────────┤
           │audit           │ Linux-Audit-Rahmenwerk               │
           ├────────────────┼──────────────────────────────────────┤
           │uefi-secureboot │ Sicherer UEFI-Systemstart            │
           ├────────────────┼──────────────────────────────────────┤
           │tpm2            │ Trusted Platform Module 2.0 (TPM2)   │
           ├────────────────┼──────────────────────────────────────┤
           │cvm             │ Vertrauenswürdige virtuelle Maschine │
           │                │ (SEV/TDX)                            │
           ├────────────────┼──────────────────────────────────────┤
           │measured-uki    │ Vereinigtes Kernelabbild mit         │
           │                │ PCR-11-Messung, gemäß                │
           │                │ systemd-stub(7). Hinzugefügt in      │
           │                │ Version 255.                         │
           └────────────────┴──────────────────────────────────────┘
           Der Test kann durch Voranstellung eines Ausrufezeichens negiert werden.

           Hinzugefügt in Version 244.

       ConditionCapability=
           Prüft, ob die übergebene Capability in der Capability-Begrenzungsmenge des Diensteverwalters
           existiert (d.h. dies prüft nicht, ob die Capability tatsächlich in der erlaubten oder effektiven
           Menge verfügbar ist, siehe capabilities(7) für Details), verwandt werden. Übergeben Sie einen
           Capability-Namen wie »CAP_MKNOD«, möglicherweise mit vorangestelltem Ausrufezeichen, um die Prüfung
           zu negieren.

           Hinzugefügt in Version 244.

       ConditionACPower=
           Prüft, ob das System zum Zeitpunkt der Aktivierung der Unit am Netz hängt oder ausschließlich über
           Akku läuft. Dies akzeptiert ein logisches Argument. Falls auf »true« gesetzt, wird die Bedingung nur
           gelten, wenn mindestens ein Netzstecker an einer Wechselstromquelle hängt 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.

           Hinzugefügt in Version 244.

       ConditionNeedsUpdate=
           Akzeptiert entweder /var/ oder /etc/ als Argument, möglicherweise mit vorangestelltem »!« (zur
           Invertierung der Bedingung). Diese Bedingung kann eingesetzt werden, um Units davon abhängig zu
           machen, ob das angegebene Verzeichnis einer Aktualisierung bedarf, da die Änderungszeit von /usr/
           neuer als die Stempeldatei .updated in dem angegebenen Verzeichnis ist. Dies ist nützlich, um
           Offline-Aktualisierungen der Betriebssystemressourcen des Lieferanten in /usr/ zu implementieren, die
           Aktualisierungen von /etc/ oder /var/ beim nachfolgenden Systemstart benötigen. Units, die von dieser
           Bedingung Gebrauch machen, sollten sich vor systemd-update-done.service(8) einordnen, um
           sicherzustellen, dass sie ausgeführt werden, bevor die Änderungszeit der Stempeldatei zurückgesetzt
           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 Zustandsüberprüfung außer Kraft setzen
           und Vorrang vor allen Dateiänderungsprüfungen haben. Falls die Kernelbefehlszeilenoption verwandt
           wird, wird systemd-update-done.service keine direkte Auswirkung auf die nachfolgenden
           ConditionNeedsUpdate=-Überprüfungen haben, bis das System neu gestartet und dabei die
           Kernelbefehlszeilenoption nicht mehr angegeben wird.

           Beachten Sie, dass der Zeitstempel von /usr/ ausdrücklich aktualisiert werden sollte, nachdem die
           Inhalte verändert wurden, damit dieses Schema wirksam wird. Der Kernel wird den
           Veränderungszeitstempel eines Verzeichnisses nur automatisch aktualisieren, wenn direkt darunter
           liegende Einträge eines Verzeichnisses verändert werden; eine Veränderung von verschachtelten Dateien
           wird nicht automatisch dazu führen, dass die mtime von /usr/ aktualisiert wird.

           Beachten Sie auch, dass die Aktualisierungsmethode nicht den Zeitstempel von /usr/ verändern sollte,
           wenn sie einen Aufruf enthält, nach der Aktualisierung selbst geeignete Schritte auszuführen. In
           einem typischen Paketierungsschema einer Distribution werden Pakete alle benötigten
           Aktualisierungsschritte als Teil der Installation oder des Upgrades durchführen, um die Paketinhalte
           sofort nutzbar zu machen. ConditionNeedsUpdate= sollte mit anderen Aktualisierungsmechanismen
           verwandt werden, bei denen eine solche direkte Aktualisierung nicht passiert.

           Hinzugefügt in Version 244.

       ConditionFirstBoot=
           Akzeptiert ein logisches Argument. Diese Bedingung kann eingesetzt werden, um Units davon abhängig zu
           machen, ob das System erstmalig startet. Dies bedeutet grob, dass /etc/ nicht bestückt war, als das
           System den Systemstart begann (für 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 Befüllen von /etc/ beim ersten Systemstart nach Rücksetzen auf
           Werkseinstellungen oder wenn eine neue Systeminstanz das erste Mal einen Systemstart durchführt,
           verwandt werden.

           Beachten Sie, dass der Diensteverwalter selbst Einrichtungsschritte während des ersten Systemstarts
           durchführen wird: er wird die machine-id(5) initialisieren und alle Units voreinstellen, sie gemäß
           der systemd.preset(5)-Einstellungen aktivieren oder deaktivieren. Zusätzliche Einrichtungen können
           mittels Units mit ConditionFirstBoot=yes durchgeführt 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 nächsten Systemstart ausgeführt werden.

           Falls die Option systemd.condition_first_boot= auf der Kernelbefehlszeile angegeben ist (sie
           akzeptiert einen logischen Wert), wird sie das Ergebnis dieser Zustandsüberprüfung außer Kraft setzen
           und Vorrang vor /etc/machine-id-Existenzprüfungen haben.

           Hinzugefügt in Version 244.

       ConditionPathExists=
           Prüft auf die Existenz einer Datei. Falls der angegebene absolute Pfadname nicht existiert, wird die
           Bedingung fehlschlagen. Falls dem an ConditionPathExists= übergebenen absoluten Pfadnamen ein
           Ausrufezeichen (»!«) vorangestellt wird, wird der Test negiert und die Unit nur gestartet, falls der
           Pfadname nicht existiert.

           Hinzugefügt in Version 244.

       ConditionPathExistsGlob=
           ConditionPathExistsGlob= ist zu ConditionPathExists= ähnlich, prüft aber auf die Existenz von
           mindestens einer Datei oder einem Verzeichnis, das auf das angegebene Globbing-Muster passt.

           Hinzugefügt in Version 244.

       ConditionPathIsDirectory=
           ConditionPathIsDirectory= ist zu ConditionPathExists= ähnlich, überprüft aber, dass ein bestimmter
           Pfad existiert und ein Verzeichnis ist.

           Hinzugefügt in Version 244.

       ConditionPathIsSymbolicLink=
           ConditionPathIsSymbolicLink= ist zu ConditionPathExists= ähnlich, überprüft aber, dass ein bestimmter
           Pfad existiert und ein symbolischer Link ist.

           Hinzugefügt in Version 244.

       ConditionPathIsMountPoint=
           ConditionPathIsMountPoint= ist zu ConditionPathExists= ähnlich, überprüft aber, dass ein bestimmter
           Pfad existiert und ein Einhängepunkt ist.

           Hinzugefügt in Version 244.

       ConditionPathIsReadWrite=
           ConditionPathIsReadWrite= ist zu ConditionPathExists= ähnlich, überprüft aber, dass das
           zugrundeliegende Dateisystem les- und schreibbar ist (d.h. nicht rein-lesbar eingehängt ist).

           Hinzugefügt in Version 244.

       ConditionPathIsEncrypted=
           ConditionPathIsEncrypted= ist ähnlich zu ConditionPathExists=, überprüft aber, dass das dem
           Dateisystem zugrundeliegende Blockgerät mittels dm-crypt/LUKS verschlüsselt ist. Beachten Sie, dass
           diese Prüfung keine verzeichnisbezogene Verschlüsselung bei Ext4 berücksichtigt und nur
           Verschlüsselung auf Blockebene erkennt. Desweiteren wird nur die Verschlüsselung oberhalb des
           Loopback-Gerätes erkannt, falls der angegebene Pfad sich auf einem Dateisystem oberhalb eines per
           Looback eingehängten Gerätes befindet. Es wird nicht erkannt, ob das dem Loopback zugrundeliegende
           Blockgerät verschlüsselt ist.

           Hinzugefügt in Version 246.

       ConditionDirectoryNotEmpty=
           ConditionDirectoryNotEmpty= ist zu ConditionPathExists= ähnlich, überprüft aber, dass ein bestimmter
           Pfad existiert und ein nicht leeres Verzeichnis ist.

           Hinzugefügt in Version 244.

       ConditionFileNotEmpty=
           ConditionFileNotEmpty= ist zu ConditionPathExists= ähnlich, überprüft aber, dass ein bestimmter Pfad
           existiert und sich auf eine normale Datei mit einer von Null verschiedenen Größe bezieht.

           Hinzugefügt in Version 244.

       ConditionFileIsExecutable=
           ConditionFileIsExecutable= ist zu ConditionPathExists= ähnlich, überprüft aber, dass ein bestimmter
           Pfad existiert und sich auf eine normale, als ausführbar gekennzeichnete Datei bezieht.

           Hinzugefügt in Version 244.

       ConditionUser=
           ConditionUser= akzeptiert eine numerische »UID«, einen UNIX-Benutzernamen oder den besonderen Wert
           »@system«. Diese Bedingung kann zur Prüfung, ob der Diensteverwalter als der angegebene Benutzer
           läuft, verwandt werden. Der besondere Wert »@system« kann dazu verwandt werden, zu prüfen, ob die
           Benutzerkennung innerhalb des Systembenutzerbereichs ist. Diese Option ergibt für Systemdienste
           keinen Sinn, da der Systemverwalter ausschließlich als Benutzer root läuft und daher das Testergebnis
           konstant ist.

           Hinzugefügt in Version 244.

       ConditionGroup=
           ConditionGroup= ist zu ConditionUser= ähnlich, überprüft aber, ob die reale oder effektive Gruppe des
           Diensteverwalters oder jeder seiner Hilfsgruppen auf die angegebene Gruppe oder GID passt. Diese
           Einstellung unterstützt den besonderen Wert »@system« nicht.

           Hinzugefügt in Version 244.

       ConditionControlGroupController=
           Prüft, ob übergebene Cgroup-Controller (z.B. »cpu«) für die Verwendung auf dem System verfügbar sind
           oder ob die veraltete V1-Cgroup- oder die moderne V2-Cgroup-Hierarchie verwandt wird.

           Durch Leerzeichen getrennt können mehrere Controller übergeben werden; in diesem Fall wird die
           Bedingung nur zutreffen, falls alle aufgeführten Controller zur Verwendung verfügbar sind. Dem System
           unbekannte Controller werden ignoriert. Gültige Controller sind »cpu«, »io«, »memory« und »pids«.
           Selbst falls er im Kernel verfügbar ist, kann ein bestimmter Controller nicht verfügbar sein, falls
           er auf der Kernel-Befehlszeile wie folgt deaktiviert wurde:

           Alternativ können 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) für weitere Informationen.

           Hinzugefügt in Version 244.

       ConditionMemory=
           Überprüft, ob die angegebene Menge an Systemspeicher für das aktuelle System verfügbar ist.
           Akzeptiert eine Speichergröße 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 Größe
           unter Berücksichtigung des angegebenen Vergleichsoperators. In Containern wird stattdessen die Menge
           des zugewiesenen Speichers verglichen.

           Hinzugefügt in Version 244.

       ConditionCPUs=
           Überprüft, dass die angegebene Anzahl an CPUs für das aktuelle System verfügbar ist. Akzeptiert eine
           Anzahl an CPUs als Argument, optional kann ein Vergleichsoperator »<«, »<=«, »=« (oder »==«), »!=«,
           »>=« (oder »<>«), »>« vorangestellt werden. Vergleicht die Anzahl der CPUs in der
           CPU-Affinitätsmaske, die im Diensteverwalter selbst konfiguriert ist, mit der angegebenen Zahl unter
           Berücksichtigung des angegebenen Vergleichsoperators. Auf physischen Systemen passt die Anzahl der
           CPUs in der Affinitätsmaske des Diensteverwalters normalerweise zu der Anzahl der physischen CPUs,
           aber in besonderen und virtuellen Umgebungen kann sich das unterscheiden. Insbesondere in Containern
           passt die Affinitätsmaske normalerweise zu der dem Container zugewiesenen Anzahl an CPUs und nicht zu
           der Anzahl der physisch verfügbaren.

           Hinzugefügt in Version 244.

       ConditionCPUFeature=
           Prüft nach, ob die angegebene CPU-Funktionalität mittels der »CPUID«-Anweisung verfügbar ist. Diese
           Bedingung macht nur auf i386- und x86-64-Prozessoren etwas. Auf anderen Prozessoren wird angenommen,
           dass die CPU die angegebene Funktionalität nicht unterstützt. Es prüft die Erlaubnisse »1«, »7«,
           »0x80000001« und »0x80000007«. Gültige 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«.

           Hinzugefügt in Version 248.

       ConditionOSRelease=
           Bestätigt, dass ein bestimmtes »Schlüssel-Wert«-Paar in der os-release(5) des Rechners gesetzt ist.

           Neben der genauen Zeichenkettenübereinstimmung (mit »=« und »!=«) werden relative Vergleiche für
           versionierte Parameter unterstützt (z.B. »VERSION_ID«; mit »<«, »<=«, »==«, »<>«, »>=«, »>«) und
           Shell-artige Joker-Vergleiche (»*«, »?«, »[]«) werden mit »$=« (Treffer) und »!$=« (nicht Treffer)
           unterstützt.

           Hinzugefügt 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 »%« angehängt wird, festgelegt werden; in diesem Fall wird der Druck als
           Durchschnitt über die letzten fünf Minuten gemessen, bevor der Versuch, die Unit zu starten,
           durchgeführt wird. Alternativ kann eine durchschnittliche Zeitdauer auch mit »/« als Trenner
           festgelegt werden, beispielsweise »10%/1min«. Die unterstützten Zeitdauern passen auf das Angebot des
           Kernels und sind auf »10sec«, »1min« und »5min« beschränkt. Zuerst wird der vollständige PSI geprüft,
           und falls dieser nicht gefunden wird, werden »einige« geprüft. Für weitere Details lesen Sie die
           Dokumentation unter PSI (Pressure Stall Information)[4].

           Optional kann dem Schwellwert die Scheiben-Unit, unter der der Druck überprüft wird, vorangestellt
           werden, gefolgt von »:«. Falls die Scheiben-Unit nicht festgelegt ist, wird der Gesamtsystemdruck
           statt dem einer bestimmten Cgroup gemessen.

           Hinzugefügt 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=
           Ähnlich zu den oben beschriebenen Bedingungseinstellungen ConditionArchitecture=,
           ConditionVirtualization=, … fügen diese Einstellungen Zusicherungsprüfungen zum Hochfahren der Unit
           hinzu. Anders als bei den Bedingungseinstellungen führt jede Zusicherungseinstellung, die nicht
           erfüllt wird, zu einem Fehlschlag des Startauftrags (das bedeutet, dass es laut protokolliert wird).
           Beachten Sie, dass das Erreichen einer konfigurierten Zusicherung nicht dazu führt, dass die Unit in
           den Zustand »failed« eintritt (oder tatsächlich zu irgendeiner Zustandsänderung der Unit führt).
           Verwenden Sie Zusicherungsausdrücke für Units, die nicht agieren können, falls bestimmte
           Anforderungen nicht erfüllt sind und wenn dies etwas ist, was sich der Administrator oder Benutzer
           anschauen sollte.

           Hinzugefügt 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 Fällen (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 Abhängigkeit
       verbunden sind. Sie zeigt, welche Eigenschaft aus der »Quell«-Unit welcher Eigenschaft aus der
       »Ziel«-Unit entspricht.

       Tabelle 4.  Vorwärts- und Rückwärts-Unit-Eigenschaften
       ┌───────────────────────┬─────────────────────────┬────────────────────────────────────────────┐
       │»Vorwärts«-Eigenschaft»Rückwärts«-EigenschaftWo 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 können nicht in
       Unit-Konfigurationseinstellungen direkt verwandt werden.

       Beachten Sie: ConsistsOf=, BoundBy=, RequisiteOf=, ConflictedBy= werden zusammen mit ihren Inversen
       implizit erstellt und können 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. Standardmäßig wird eine Unit mit dem gleichen Namen ausgelöst,
       dies kann aber mit den Einstellungen Sockets=, Service= und Unit= außer Kraft gesetzt werden. Siehe
       systemd.service(5), systemd.socket(5), systemd.path(5) und systemd.automount(5) für ihre Details.
       TriggeredBy= wird implizit von der ausgelösten Unit erstellt.

       Beachten Sie: Following= wird zur Gruppierung von Geräte-Aliassen und -Punkten zu der
       »primären«-Geräte-Unit, die Systemd zur Nachverfolgung des Gerätezustandes verwendet, verwandt,
       normalerweise entspricht dies einem Sysfs-Pfad. Dies taucht nicht in der »Ziel«-Unit auf.

[INSTALL]-ABSCHNITT-OPTIONEN

       Unit-Dateien können einen Abschnitt »[Install]« enthalten, der Installationsinformationen für die Unit
       transportiert. Dieser Abschnitt wird von systemd(1) während der Laufzeit nicht interpretiert; er wird von
       den Befehlen enable und disable des Werkzeugs systemctl(1) während der Installation einer Unit verwandt.

       Alias=
           Eine Lerraum-getrennte Liste von zusätzlichen Namen, unter der diese Unit installiert werden soll.
           Die hier aufgeführten Namen müssen die gleiche Endung (d.h. Typ) wie der Unit-Dateiname haben. Diese
           Option kann mehr als einmal angegeben werden, dann werden alle aufgeführten 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 unterstützen und diese Einstellung für sie
           nicht unterstützt wird. Insbesondere unterstützen Einhänge-, Scheiben, Auslagerungs- und
           Automount-Units keinen Alias.

           Hinzugefügt in Version 201.

       WantedBy=, RequiredBy=, UpheldBy=
           Diese Option kann mehr als einmal verwendet werden oder eine durch Leerzeichen getrennte Liste von
           Unit-Namen kann übergeben werden. Im .wants/-, .requires/- oder .upholds/-Verzeichnis jeder der
           aufgeführten Units wird bei der Installation mit systemctl enable ein symbolischer Link erstellt.
           Dadurch wird eine Abhängigkeit vom Typ Wants=, Requires= oder Upholds= von der aufgeführten Unit zu
           der aktuellen Unit hinzugefügt. Siehe die Beschreibung der erwähnten Abhängigkeitstypen in dem
           Abschnitt [Unit] für Details.

           Falls Vorlagen-Units nicht-Vorlagen-Units aufführen, muss in der aufführenden 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 aufgeführten Unit hinzugefügt. Zum Beispiel führt 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 für das Aufführen
           bestimmter Instanzen aus einer Vorlagen-Unit: diese bestimmte Instanz wird die Abhängigkeit erhalten.
           Eine Vorlagen-Unit kann auch eine Vorlagen-Unit aufführen. Dann wird eine generische Abhängigkeit
           hinzugefügt, bei der jede Instanz der aufführenden Unit eine Abhängigkeit auf eine Instanz der
           aufgeführten Vorlagen-Unit mit dem gleichen Instanzwert haben wird. Beispielsweise wird
           WantedBy=container@.target dazu führen, dass systemctl enable monitor@.service einen Dienste-Link
           container@.target.wants/monitor@.service auf monitor@.service erstellt, der für alle Instanzen von
           container@.target gilt.

           Hinzugefügt in Version 201.

       Also=
           Zusätzliche 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 aufgeführten Units installieren/deinstallieren.

           Diese Option kann mehr als einmal verwandt werden oder eine Lerraum-getrennte Liste von Unit-Namen
           kann übergeben werden.

           Hinzugefügt 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.

           Hinzugefügt 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 nächsten Abschnitt beschrieben.

KENNZEICHNER

       Viele Einstellungen klären Kennzeichner, die zum Schreiben generischer Unit-Dateien verwandt werden
       können, die sich auf Laufzeit- oder Unit-Parameter beziehen, die ersetzt werden, wenn die Unit-Dateien
       geladen werden. Kennzeichner müssen bekannt und auflösbar sein, damit die Einstellungen gültig sind. Die
       folgenden Kennzeichner werden verstanden:

       Tabelle 5. In Unit-Dateien verfügbare Kennzeichner
       ┌─────────────┬────────────────────────────────┬───────────────────────────────────────────┐
       │KennzeichnerBedeutungDetails                                   │
       ├─────────────┼────────────────────────────────┼───────────────────────────────────────────┤
       │"%a"         │ Architektur                    │ Eine kurze Zeichenkette, die              │
       │             │                                │ die Architektur des lokalen               │
       │             │                                │ Systems identifiziert. Eine               │
       │             │                                │ Zeichenkette wie x86, x86-64              │
       │             │                                │ oder arm64. Siehe die für                 │
       │             │                                │ ConditionArchitecture=                    │
       │             │                                │ weiter oben definierten                   │
       │             │                                │ Architekturen für die                     │
       │             │                                │ vollständige 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) für weitere                 │
       │             │                                │ Informationen.                            │
       ├─────────────┼────────────────────────────────┼───────────────────────────────────────────┤
       │"%b"         │ Boot-Kennung                   │ Die Boot-Kennung des laufenden Systems,   │
       │             │                                │ formatiert als Zeichenkette. Siehe        │
       │             │                                │ random(4) für 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 aufgelöst. Siehe             │
       │             │                                │ os-release(5) für weitere Informationen.  │
       ├─────────────┼────────────────────────────────┼───────────────────────────────────────────┤
       │"%C"         │ Wurzelverzeichnis des          │ Dies ist entweder /var/cache (für den     │
       │             │ Zwischenspeichers              │ Systemverwalter) oder worauf der Pfad     │
       │             │                                │ »$XDG_CACHE_HOME« zeigt (für              │
       │             │                                │ Benutzerverwalter).                       │
       ├─────────────┼────────────────────────────────┼───────────────────────────────────────────┤
       │"%d"         │ Zugangsdaten-Verzeichnis       │ Dies ist der Wert der Umgebungsvariablen  │
       │             │                                │ »$CREDENTIALS_DIRECTORY«, falls           │
       │             │                                │ verfügbar. Siehe den Abschnitt            │
       │             │                                │ »Zugangsdaten« in systemd.exec(5) für     │
       │             │                                │ weitere Informationen.                    │
       ├─────────────┼────────────────────────────────┼───────────────────────────────────────────┤
       │"%D"         │ Gemeinsames Datenverzeichnis   │ Dies ist entweder /usr/share (für den     │
       │             │                                │ Systemverwalter) oder worauf der Pfad     │
       │             │                                │ »$XDG_DATA_HOME« zeigt (für               │
       │             │                                │ Benutzerverwalter).                       │
       ├─────────────┼────────────────────────────────┼───────────────────────────────────────────┤
       │"%E"         │ Wurzelverzeichnis der          │ Dies ist entweder /etc/ (für den          │
       │             │ Konfiguration                  │ Systemverwalter) oder worauf der Pfad     │
       │             │                                │ »$XDG_CONFIG_HOME« zeigt (für             │
       │             │                                │ Benutzerverwalter).                       │
       ├─────────────┼────────────────────────────────┼───────────────────────────────────────────┤
       │"%f"         │ Demaskierter Dateiname         │ Dies ist entweder der demaskierte         │
       │             │                                │ Instanzenname (falls zutreffend), dem /   │
       │             │                                │ vorangestellt wurde (falls zutreffend),   │
       │             │                                │ oder der desmaskierte Präfixname, 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 ausführt. Im      │
       │             │                                │ Falle des Systemverwalters löst sich dies │
       │             │                                │ auf »root« auf.                           │
       ├─────────────┼────────────────────────────────┼───────────────────────────────────────────┤
       │"%G"         │ Benutzer-GID                   │ Dies ist die numerische GID des           │
       │             │                                │ Benutzers, der die                        │
       │             │                                │ Diensteverwalterinstanz ausführt. Im      │
       │             │                                │ Falle des Systemverwalters löst sich dies │
       │             │                                │ auf »0« auf.                              │
       ├─────────────┼────────────────────────────────┼───────────────────────────────────────────┤
       │"%h"         │ Benutzer-Home-Verzeichnis      │ Dies ist das Home-Verzeichnis des         │
       │             │                                │ Benutzers, der die                        │
       │             │                                │ Diensteverwalterinstanz ausführt. Im      │
       │             │                                │ Falle des Systemverwalters löst 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                  │ Für instanziierte Units ist dies die      │
       │             │                                │ Zeichenkette zwischen dem ersten          │
       │             │                                │ »@«-Zeichen und der Typendung. Leer für   │
       │             │                                │ nichtinstanziierte Units.                 │
       ├─────────────┼────────────────────────────────┼───────────────────────────────────────────┤
       │"%I"         │ Demaskierter Instanzenname     │ Identisch zu »%i«, aber mit               │
       │             │                                │ zurückgenommener Maskierung.              │
       ├─────────────┼────────────────────────────────┼───────────────────────────────────────────┤
       │"%j"         │ Abschließende Komponente des   │ Dies ist die Zeichenkette zwischen dem    │
       │             │ Präfixes                       │ letzten »-« und dem Ende des              │
       │             │                                │ Präfixnamens. Falls es kein »-« gibt, ist │
       │             │                                │ dies zu »%p« identisch.                   │
       ├─────────────┼────────────────────────────────┼───────────────────────────────────────────┤
       │"%J"         │ Nicht maskierte                │ Identisch zu »%j«, aber mit               │
       │             │ abschließende Komponente des   │ zurückgenommener Maskierung.              │
       │             │ Präfixes                       │                                           │
       ├─────────────┼────────────────────────────────┼───────────────────────────────────────────┤
       │"%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 (für den       │
       │             │ Protokollierverzeichnisses     │ Systemverwalter) oder worauf der Pfad     │
       │             │                                │ $XDG_CONFIG_HOME zeigt, mit angehängtem   │
       │             │                                │ /log (für Benutzerverwalter).             │
       ├─────────────┼────────────────────────────────┼───────────────────────────────────────────┤
       │"%m"         │ Maschinenkennung               │ Die Maschinenkennung des laufenden        │
       │             │                                │ Systems, formatiert als Zeichenkette.     │
       │             │                                │ Siehe machine-id(5) für 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) für     │
       │             │                                │ weitere Informationen.                    │
       ├─────────────┼────────────────────────────────┼───────────────────────────────────────────┤
       │"%n"         │ Vollständiger Unit-Name        │                                           │
       ├─────────────┼────────────────────────────────┼───────────────────────────────────────────┤
       │"%N"         │ Vollständiger 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) für weitere Informationen.  │
       ├─────────────┼────────────────────────────────┼───────────────────────────────────────────┤
       │"%p"         │ Präfixname                     │ Für instanziierte Units bezieht sich das  │
       │             │                                │ auf die Zeichenkette vor dem ersten       │
       │             │                                │ »@«-Zeichen des Unit-Namens. Für nicht    │
       │             │                                │ instanziierte Units identisch zu »%N«.    │
       ├─────────────┼────────────────────────────────┼───────────────────────────────────────────┤
       │"%P"         │ Nicht maskierter Präfixname    │ Identisch zu »%p«, aber mit               │
       │             │                                │ zurückgenommener Maskierung.              │
       ├─────────────┼────────────────────────────────┼───────────────────────────────────────────┤
       │"%q"         │ Schöner Rechnername            │ Der schöne 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) für weitere         │
       │             │                                │ Informationen.                            │
       ├─────────────┼────────────────────────────────┼───────────────────────────────────────────┤
       │"%s"         │ Benutzer-Shell                 │ Dies ist die Shell des Benutzers, der die │
       │             │                                │ Diensteverwalterinstanz ausführt.         │
       ├─────────────┼────────────────────────────────┼───────────────────────────────────────────┤
       │"%S"         │ Wurzel des                     │ Dies ist entweder /var/lib (für den       │
       │             │ Zustandsverzeichnisses         │ Systemverwalter) oder worauf der Pfad     │
       │             │                                │ $XDG_CONFIG_HOME zeigt (für               │
       │             │                                │ Benutzerverwalter).                       │
       ├─────────────┼────────────────────────────────┼───────────────────────────────────────────┤
       │"%t"         │ Wurzel des                     │ Dies ist entweder /run/ (für den          │
       │             │ Laufzeitverzeichnisses         │ Systemverwalter) oder worauf der Pfad     │
       │             │                                │ »$XDG_RUNTIME_DIR« zeigt (für             │
       │             │                                │ Benutzerverwalter).                       │
       ├─────────────┼────────────────────────────────┼───────────────────────────────────────────┤
       │"%T"         │ Verzeichnis für temporäre      │ Dies ist entweder /tmp oder der Pfad, auf │
       │             │ Dateien                        │ den »$TMPDIR«, »$TEMP« oder »$TMP«        │
       │             │                                │ gesetzt ist. (Beachten Sie, dass das      │
       │             │                                │ Verzeichnis ohne abschließenden           │
       │             │                                │ Schrägstrich angegeben werden kann.)      │
       ├─────────────┼────────────────────────────────┼───────────────────────────────────────────┤
       │"%u"         │ Benutzername                   │ Dies ist der Name des Benutzers, der die  │
       │             │                                │ Diensteverwalterinstanz ausführt. Im      │
       │             │                                │ Falle des Systemverwalters löst 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 ausführt. Im      │
       │             │                                │ Falle des Systemverwalters löst 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"         │ Kernelveröffentlichung         │ Identisch zur Ausgabe von uname -r.       │
       ├─────────────┼────────────────────────────────┼───────────────────────────────────────────┤
       │"%V"         │ Verzeichnis für größere und    │ Dies ist entweder /var/tmp oder der Pfad, │
       │             │ dauerhafte temporäre Dateien   │ auf den »$TMPDIR«, »$TEMP« oder »$TMP«    │
       │             │                                │ gesetzt ist. (Beachten Sie, dass das      │
       │             │                                │ Verzeichnis ohne abschließenden           │
       │             │                                │ Schrägstrich 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) für 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) für weitere Informationen.  │
       ├─────────────┼────────────────────────────────┼───────────────────────────────────────────┤
       │"%y"         │ Der Pfad zum Fragment.         │ Dies ist der Pfad dorthin, wo sich der    │
       │             │                                │ Hauptteil der Unit-Datei befindet. Für    │
       │             │                                │ verlinkte Unit-Dateien wird der echte     │
       │             │                                │ Pfad außerhalb der Unit-Suchverzeichnisse │
       │             │                                │ verwandt. Für 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 Ausführung von systemctl enable verlinkt ein Symlink
       /etc/systemd/system/multi-user.target.wants/foo.service auf die tatsächlich 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 außer Kraft setzen

       Es gibt zwei Methoden, die Lieferanteneinstellungen in Unit-Dateien außer Kraft zu setzen: Kopieren der
       Unit-Datei aus /usr/lib/systemd/system nach /etc/systemd/system und Anpassen der gewählten Einstellungen
       oder alternativ durch Anlage eines Verzeichnisses namens Unit.d/ innerhalb von /etc/systemd/system und
       darin einer Ergänzungsdatei Name.conf, die nur die speziellen Einstellungen, an denen Sie interessiert
       sind, ändert. Beachten Sie, dass diese Ergänzungsdateien in lexikalischer Reihenfolge ihres Dateinamens
       verarbeitet werden, falls mehrere vorhanden sind.

       Der Vorteil der ersten Methode besteht darin, dass normalerweise die komplette Unit außer Kraft gesetzt
       wird und die Unit des Lieferanten überhaupt nicht mehr ausgewertet wird. Der Nachteil besteht darin, dass
       Verbesserungen an der Unit-Datei durch den Lieferanten bei Aktualisierungen nicht mehr automatisch mit
       berücksichtigt werden.

       Der Vorteil der zweiten Methode besteht darin, dass nur die genau gewünschten Einstellungen außer Kraft
       gesetzt und Aktualisierungen vom Lieferanten angewandt werden. Dies hat den Nachteil, dass zukünftige
       Aktualisierungen vom Lieferanten zu den lokalen Änderungen inkompatibel sein könnten.

       Dies gilt auch für Benutzerinstanzen von Systemd, aber mit anderen Orten für die Unit-Dateien. Siehe den
       Abschnitt über Unit-Ladepfade für 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 möchten Sie als Administrator einige Einstellungen ändern: zuerst könnte in der lokalen
       Installation /srv/webserver nicht existieren, da der Webserver stattdessen auf /srv/www konfiguriert ist.
       Zweitens hängt 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 möchte der Administrator zur weiteren
       Härtung des Dienstes die Einstellung PrivateTmp= (siehe systemd.exec(5) für Details) setzen. Schließlich
       möchte der Administrator die Einstellung des Nice-Wertes des Dienstes auf den Vorgabewert 0 zurücksetzen.

       Die erste Möglichkeit besteht darin, die Unit-Datei nach /etc/systemd/system/httpd.service zu kopieren
       und die ausgewählten Einstellungen zu ändern:

           [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 könnte der Administrator eine Ergänzungsdatei in
       /etc/systemd/system/httpd.service.d/local.conf mit folgendem Inhalt erstellen:

           [Unit]
           After=memcached.service
           Requires=memcached.service
           # Setzt alle Zusicherungen zurück and fügt dann die gewünschten Bedingungen hinzu
           AssertPathExists=
           AssertPathExists=/srv/www

           [Service]
           Nice=0
           PrivateTmp=yes

       Beachten Sie bei Ergänzungsdateien, dass bei Einstellungen, die als Liste ausgewertet werden (und die
       keine Abhängigkeit sind), wie AssertPathExists= (oder z.B. ExecStart= in Dienste-Units), zuerst die Liste
       bereinigt werden muss, bevor Einträge (ohne den zu entfernenden) hinzugefügt werden, falls Sie einen
       Eintrag von einer Einstellung entfernen möchten. Abhängigkeiten (After=, usw.) können nicht auf die leere
       Liste zurückgesetzt werden, daher können in Ergänzungsdateien Abhängigkeiten nur hinzugefügt werden.
       Falls Sie eine Abhängigkeit entfernen möchten, müssen Sie die gesamte Unit außer Kraft setzen.

       Beispiel 3. Ergänzungen auf oberster Ebene mit Vorlagen-Units

       Typbezogene Ergänzungen auf oberster Stufe können zum Ändern einiger Aspekte aller Units eines bestimmten
       Typs verwandt werden. Wird beispielsweise das Verzeichnis /etc/systemd/system/service.d/ mit einer
       Ergänzungsdatei erstellt, können die Inhalte der Ergänzungsdatei auf alle Dienste-Units angewandt werden.
       Dies kann weitergetrieben werden, indem die Ergänzung auf oberster Stufe eine sekundäre Hilfs-Unit
       realisiert. Betrachten Sie beispielsweise die folgende Gruppe von Units und Ergänzungsdateien, bei denen
       eine Abhängigkeit OnFailure= für alle Dienste-Units installiert wird.

       /etc/systemd/system/failure-handler@.service:

           [Unit]
           Description=Mein Fehler-Handler für %i

           [Service]
           Type=oneshot
           # Ausführung einiger besonderer Aktionen, wenn sich %i unerwartet beendet.
           ExecStart=/usr/sbin/myfailurehandler %i

       Eine Instanz von failure-handler@.service kann als eine Abhängigkeit OnFailure= für alle Dienste-Units
       hinzugefügt werden.

       /etc/systemd/system/service.d/10-all.conf:

           [Unit]
           OnFailure=failure-handler@%N.service

       Nach der Ausführung von systemctl daemon-reload werden jetzt alle Dienste ein Abhängigkeit OnFailure= auf
       failure-handler@%N.service erlangt haben. Die Vorlage-Instanz-Units werden auch die Abhängigkeit erlangt
       haben, die zu der Erstellung einer rekursiven Abhängigkeitskette geführt hat. Systemd wird versuchen,
       diese rekursiven Abhängigkeitsketten zu erkennen, bei der eine Vorlagen-Unit direkt und rekursiv von sich
       selbst abhängt und wird solche Abhängigkeiten automatisch entfernen, falls es sie findet. Falls Systemd
       die rekursive Abhängigkeitskette nicht selbst erkennt, kann die Kette manuell unterbrochen werden, indem
       die Ergänzung für 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 fehlschlägt, falls sie keine Instanz
       namens failure-handler@failure-handler.service auslöst.

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. Schnittstellenportabilitäts- und -stabilitätszusage
           https://systemd.io/PORTABILITY_AND_STABILITY/

        2. Systemd- und Speicher-Daemons für 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

ÜBERSETZUNG

       Die deutsche Übersetzung dieser Handbuchseite wurde von Helge Kreutzmann <debian@helgefjell.de> erstellt.

       Diese Übersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 3
       ⟨https://www.gnu.org/licenses/gpl-3.0.html⟩ oder neuer bezüglich der Copyright-Bedingungen. Es wird KEINE
       HAFTUNG übernommen.

       Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an die
       Mailingliste der Übersetzer ⟨debian-l10n-german@lists.debian.org⟩.