systemd.unit

SYSTEMD.UNIT(5)                   systemd.unit                   SYSTEMD.UNIT(5)



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/systemd.attached/*
       /run/systemd/system/*
       /run/systemd/systemd.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/*
       /etc/systemd/user/*
       $XDG_RUNTIME_DIR/systemd/user/*
       /run/systemd/user/*
       $XDG_RUNTIME_DIR/systemd/generator/*
       ~/.local/share/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 »Namensvorsatz« und einem Punkt und
       einer Endung, die den Unit-Typ festlegt. Der »Unit-Vorsatz« muss aus
       einem oder mehreren gültigen Zeichen (ASCII-Buchstaben, Ziffern, »:«,
       »-«, »_«, ».« und »\« bestehen). Die Gesamtlänge des Unit-Names
       einschließlich der Endung darf 256 Zeichen nicht überschreiten. Die
       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 Namens 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.

       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
       Symlink (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.

       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/systemd/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= siehe
       unten. Die bevorzugte Art, Symlinks in den Verzeichnissen .wants/ oder
       .requires/ einer Unit-Datei zu erstellen, ist über Einbettung der
       Abhängigkeit in den Abschnitt [Install] der Ziel-Unit und Erstellung des
       Symlinks im Dateisystem mittel des Befehls enable oder preset von
       systemctl(1).

       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 werden, nachdem die Unit-Datei
       selbst ausgewertet wurde, ausgewertet. 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. Ergänzungsdateien
       müssen 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 Abschneiden des
       Unit-Namens nach allen Bindestrichen entsteht, auch durchsucht.
       Insbesondere wird für einen Unit-Namen foo-bar-baz.service.d/ sowohl
       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.
       Konfigurationen in Typ.d/ haben den niedrigsten Vorrang im Vergleich zu
       Einstellungen in den namensspezifischen Außerkraftsetzungsverzeichnissen.
       Daher würden die Inhalte von foo-.service.d/10-override.conf
       service.d/10-override.conf außer Kraft setzen.

       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 Schnittstellenstabilitä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,
       außer DefaultDependencies=no ist in den festgelegten Units gesetzt. Siehe
       systemd.target(5) für Details. Beachten Sie, dass dieses Verhalten durch
       Setzen von DefaultDependencies=no abgeschaltet werden kann.

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).
       ┌──────────────────────────────┬─────────────────────────────┐
       │Pfad                          Beschreibung                │
       ├──────────────────────────────┼─────────────────────────────┤
       │/etc/systemd/system.control   │ Mittels Dbus-API erstellte  │
       ├──────────────────────────────┤ dauerhafte und flüchtige    │
       │/run/systemd/system.control   │ Konfiguration               │
       ├──────────────────────────────┼─────────────────────────────┤
       │/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).

       ┌────────────────────────────────────────┬─────────────────────────────┐
       │Pfad                                    Beschreibung                │
       ├────────────────────────────────────────┼─────────────────────────────┤
       │$XDG_CONFIG_HOME/systemd/user.control   Dauerhafte und flüchtige    │
       │oder                                    Konfiguration, die mittels  │
       │~/.config/systemd/user.control          des DBus-APIs erstellt wird │
       ├────────────────────────────────────────┤ (($XDG_CONFIG_HOME wird     │
       │$XDG_RUNTIME_DIR/systemd/user.control   verwandt, falls gesetzt,    │
       │                                        │ andernfalls ~/.config)      │
       ├────────────────────────────────────────┼─────────────────────────────┤
       │/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))    │
       ├────────────────────────────────────────┼─────────────────────────────┤
       │$XDG_CONFIG_HOME/systemd/user oder      Benutzerkonfiguration       │
       │$HOME/.config/systemd/user              ($XDG_CONFIG_HOME wird      │
       │                                        │ verwandt, falls gesetzt,    │
       │                                        │ andernfalls ~/.config)      │
       ├────────────────────────────────────────┼─────────────────────────────┤
       │/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) │
       ├────────────────────────────────────────┼─────────────────────────────┤
       │$dir/systemd/user für jedes $dir in     Zusätzliche Orte für        │
       │$XDG_DATA_DIRS                          installierte                │
       │                                        │ 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) für seine
       Verwendung und Vorsichtsmaßnahmen.

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 menschenlesbarer Name für die Unit. Dieser wird von systemd (und
           anderen Benutzeroberflächen) als Bezeichnung für die Unit verwandt,
           daher sollte diese Zeichenkette die Unit identifzieren, statt sie zu
           beschreiben, trotz des Namens. »Apache2 Webserver« ist ein gutes
           Beispiel. Schlechte Beispiele sind »leichtgewichtiger
           Hochleistungs-HTTP-Server« (zu generisch) oder »Apache2« (zu
           spezifisch und für Leute, die Apache nicht kennen, bedeutungslos).
           systemd wird 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.«.

       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.

       Wants=
           Konfiguriert Anforderungsabhängigkeiten auf andere Units. Diese
           Option darf mehr als einmal festgelegt werden oder mehrere, durch
           Leerraum getrennte Units können in einer Option festgelegt 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.

       Requires=
           Ähnlich Wants=, erklärt aber eine stärkerere Abhä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, falls eine der
           anderen Units explizit gestoppt 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).

       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.

       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 fehlenden Bedingungsprüfung
           (wie ConditionPathExists=, ConditionPathIsSymbolicLink=, … \m 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.

       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.

       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.

       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.

       OnFailure=
           Eine Leerraum-getrennte Liste einer oder mehrerer Units, die
           aktiviert werden, wenn diese Unit den Zustand »failed« einnimmt. Eine
           Dienste-Unit, die Restart= verwendet, nimmt den fehlgeschlagenen
           Zustand nur an, nachdem die Startbegrenzung erreicht wurde.

       PropagatesReloadTo=, ReloadPropagatedFrom=
           Eine Leerraum-getrennte Liste einer oder mehrerer Units, bei denen
           Neuladeanforderungen an diese anderen Units ausgebreitet werden bzw.
           Neuladeanforderungen von anderen Units an diese Unit ausgebreitet
           werden. Erteilen einer Neuladeanforderung an eine Unit, wird auch
           eine Neuladeanforderung an alle Units, an die die Neuladeanforderung
           mittels dieser zwei Einstellungen ausgebreitet werden soll, erteilen.

       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. Dies gilt nur für
           Unit-Typen, die die Anweisungen PrivateNetwork=,
           NetworkNamespacePath= 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- und Netzwerk-Namensräume wie die aufgeführte gestartete
           Unit haben. Falls mehrere aufgeführte Units bereits gestartet sind,
           ist nicht definiert, welchem Namensraum beigetreten wird. Beachten
           Sie, dass diese Einstellung nur Wirkung zeigt, falls
           PrivateNetwork=/NetworkNamespacePath= und/oder PrivateTmp= für sowohl
           die Unit, die dem Namensraum beitritt, als auch die Unit, deren
           Namensraum beigetreten wird, aktiviert ist.

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

       OnFailureJobMode=
           Akzeptiert einen Wert aus »fail«, »replace«, »replace-irreversibly«,
           »isolate«, »flush«, »ignore-dependencies«, »ignore-requirements«.
           Standardmäßig »replace«. Legt fest, wie die in 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 OnFailure= nur
           eine einzelne Unit aufgeführt werden.

       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.

       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.

       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.

       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.

       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.

       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.

       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 oder exit-force. 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 die
           Wirkung des Herunterfahrens 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.

       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.

       JobTimeoutSec=, JobRunningTimeoutSec=
           Wenn ein Auftrag für diese Unit in die Warteschlange eingereiht wird,
           kann eine Zeitüberschreitung JobTimeoutSec= konfiguriert werden.
           Ähnlich zu JobRunningTimeoutSec= beginnt er zu zählen, wenn der in
           die Warteschlange eingereihte Auftrag tatsächlich gestartet wird.
           Falls eine der Zeitbegrenzungen erreicht ist, wird der Auftrag
           abgebrochen, die Unit wird allerdings nicht ihren Zustand ändern oder
           sogar den Modus »failed« einnehmen. Dieser Wert beträgt standardmäßig
           »infinity« (Auftrags-Zeitüberschreitungen deaktiviert), außer für
           Geräte-Units (JobRunningTimeoutSec= ist standardmäßig
           DefaultTimeoutStartSec=). Hinweis: Diese Zeitüberschreitung ist
           unabhängig von allen Unit-spezifischen Zeitüberschreitungen
           (beispielsweise den mit TimeoutStartSec= in Dienste-Units gesetzten
           Zeitüberschreitungen), da die Auftragszeitüberschreitung keine
           Wirkung für die Unit selbst hat, nur für den Auftrag, der für sie
           warten könnte. 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.

       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 StartLimitAction=. Standardmäßig
           none. JobTimeoutRebootArgument= konfiguriert eine optionale
           Neustartzeichenkette, die an den Systemaufruf reboot(2) übergeben
           wird.

       StartLimitIntervalSec=Intervall, StartLimitBurst=Häufung
           Konfiguriert die Unit-Startratenbegrenzung. Units, die mehr als
           Häufung mal innerhalb des Zeitintervalls Intervall gestartet werden,
           wird kein weiterer Start erlaubt. Verwenden Sie
           StartLimitIntervalSec=, um das Überprüfungsintervall (standardmäßig
           DefaultStartLimitIntervalSec= in Verwalterkonfigurationsdatei, setzen
           Sie es auf 0, um jede Art von Ratenbegrenzung zu deaktivieren) zu
           konfigurieren. Verwenden Sie StartLimitBurst=, um zu konfigurieren,
           wie viele Starts pro Intervall erlaubt sind (standardmäßig
           DefaultStartLimitBurst= in Verwalterkonfigurationsdatei). Diese
           Konfigurationsoptionen sind insbesondere in Zusammenspiel mit der
           Diensteeinstellung Restart= (siehe systemd.service(5)) nützlich;
           allerdings gelten sie für alle Arten von Starts (einschließlich
           manuellen), nicht nur die durch die Logik Restart= ausgelösten.
           Beachten Sie, dass Units, die für Restart= konfiguriert sind und die
           die Startbegrenzung erreicht haben, nicht mehr zum Neustarten
           versucht werden; allerdings können sie weiterhin manuell zu einem
           späteren Zeitpunkt neu gestartet werden, nachdem das Intervall
           abgelaufen ist. Von diesem Zeitpunkt an ist die Neustartlogik wieder
           aktiviert. Beachten Sie, dass systemctl reset-failed dazu führen
           wird, dass der Neustartratenzähler für einen Dienst entleert wird,
           was nützlich ist, falls der Administrator eine Unit manuell starten
           möchte und die Startratenbegrenzung dabei stört. Beachten Sie, dass
           diese Ratenbegrenzung durchgesetzt wird, nachdem alle
           Unit-Bedingungsprüfungen ausgeführt sind und daher zählen
           Unit-Aktivierungen mit fehlschlagenden Bedingungen nicht bei dieser
           Ratenbegrenzung mit. Diese Einstellung wird für Scheiben-, Ziel-,
           Geräte- und Bereichs-Units nicht angewandt, da dies Unit-Typen sind,
           deren Aktivierung niemals fehlschlagen oder nur ein einziges Mal
           erfolgreich sein dürfen.

           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.

       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.

       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.

       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.

   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 wahr sind.
       Falls nicht, wird das Starten der Unit (fast ohne Ausgabe) übersprungen.
       Fehlschlagende Bedingungen führen nicht dazu, dass die Unit in den
       Zustand »failed« überführt wird. Die Bedingungen 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. 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
       ausgeführt, falls mindestens eine der auslösenden Bedingungen und alle
       der 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=, … stellen einen
       ähnlichen Mechanismus bereit, der dazu führt, dass Aufträge fehlschlagen
       (statt übersprungen zu werden). Die fehlgeschlagene Prüfung wird
       protokolliert. Units mit fehlgeschlagenen 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.

       Das Bedingungs-Verb 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«.

           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.

       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«, »zvm«,
           »vmware«, »microsoft«, »oracle«, »xen«, »bochs«, »uml«, »bhyve«,
           »qnx«, »openvz«, »lxc«, »lxc-libvirt«, »systemd-nspawn«, »docker«,
           »podman«, »rkt«, »wsl«, »proot«, »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.

       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.

       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.

       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. Für jeden der Ausdrücke
           wird, falls er mit einem aus »<«, »<=«, »=«, »!=«, »>=«, »>« beginnt,
           ein relativer Vergleich durchgeführt, andernfalls wird die
           festgelegte Zeichenkette mit Shell-artigen Globs abgeglichen.

           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.

       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.

       ConditionSecurity=
           ConditionSecurity= kann zur Prüfung, ob die übergebene
           Sicherheitstechnik auf dem System aktiviert ist, verwandt werden.
           Derzeit sind die erkannten Werte »selinux«, »apparmor«, »tomoyo«,
           »ima«, »smack«, »audit« und »uefi-secureboot«. Der Test kann durch
           Voranstellung eines Ausrufezeichens negiert werden.

       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.

       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.

       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
           festgelegte Verzeichnis einer Aktualisierung bedarf, da die
           Änderungszeit von /usr neuer als die Stempeldatei .updated in dem
           festgelegten 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 festgelegt 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
           dies 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 festgelegt wird.

       ConditionFirstBoot=
           Akzeptiert ein logisches Argument. Diese Bedingung kann eingesetzt
           werden, um Units davon abhängig zu machen, ob das System mit einem
           unbestückten /etc-Verzeichnis (genauer: einem /etc ohne
           /etc/machine-id) gestartet wurde. Dies kann zum Bestücken von /etc
           beim ersten Systemstart nach einem Zurücksetzen auf
           Werkseinstellungen oder wenn eine neue Systeminstanz erstmalig
           startet verwandt werden.

           Falls die Option systemd.condition-first-boot= auf der
           Kernelbefehlszeile festgelegt 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.

       ConditionPathExists=
           Prüft auf die Existenz einer Datei. Falls der festgelegte 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.

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

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

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

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

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

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

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

       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.

       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.

       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.

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

       ConditionControlGroupController=
           Prüft, ob der angegebene Cgroup-Controller-Name (z.B. »cpu«) für den
           Einsatz im System verfügbar ist. Ein bestimmter Controller könnte
           beispielsweise nicht verfügbar sein, falls er auf der
           Kernelbefehlszeile mit cgroup_disable=Controller deaktiviert wurde.
           Werden mehrere Controller übergeben, müssen sie mit Leerzeichen
           getrennt werden und die Bedingung wird nur durchgehen, falls alle
           aufgeführten Controller für den Einsatz verfügbar sind. Systemd
           unbekannte Controller werden ignoriert. Gültige Controller sind
           »cpu«, »cpuacct«, »io«, »blkio«, »memory«, »devices« und »pids«.

       ConditionMemory=
           Überprüft, ob die festgelegte Menge an Systemspeicher für das
           aktuelle System verfügbar ist. Akzeptiert eine Speichergröße in Byte
           als Argument, optional kann ein Vergleichsoperator »<«, »<=«, »=«,
           »!=«, »>=«, »>« vorangestellt werden. Auf Systemen, die direkt auf
           der Hardware laufen, vergleicht es die Menge an physischen Speicher
           im System mit der festgelegten Größe unter Berücksichtigung des
           festgelegten Vergleichsoperators. In Containern wird stattdessen die
           Menge des zugewiesenen Speichers verglichen.

       ConditionCPUs=
           Überprüft, dass die festgelegte Anzahl an CPUs für das aktuelle
           System verfügbar ist. Akzeptiert eine Anzahl an CPUs als Argument,
           optional kann ein Vergleichsoperator »<«, »<=«, »=«, »!=«, »>=«, »>«
           vorangestellt werden. Vergleicht die Anzahl der CPUs in der
           CPU-Affinitätsmaske, die im Diensteverwalter selbst konfiguriert ist,
           mit der festgelegten Zahl unter Berücksichtigung des festgelegten
           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.

       AssertArchitecture=, AssertVirtualization=, AssertHost=,
       AssertKernelCommandLine=, AssertKernelVersion=, AssertSecurity=,
       AssertCapability=, AssertACPower=, AssertNeedsUpdate=, AssertFirstBoot=,
       AssertPathExists=, AssertPathExistsGlob=, AssertPathIsDirectory=,
       AssertPathIsSymbolicLink=, AssertPathIsMountPoint=,
       AssertPathIsReadWrite=, AssertDirectoryNotEmpty=, AssertFileNotEmpty=,
       AssertFileIsExecutable=, AssertUser=, AssertGroup=,
       AssertControlGroupController=
           Ä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.

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 3.  Vorwärts- und Rückwärts-Unit-Eigenschaften
       ┌───────────────────────┬─────────────────────────┬────────────────────────────────────────┐
       │»Vorwärts«-Eigenschaft »Rückwärts«-Eigenschaft Wo benutzt                             │
       ├───────────────────────┼─────────────────────────┼────────────────────────────────────────┤
       │Before=                After=                  │                                        │
       ├───────────────────────┼─────────────────────────┤ [Unit]-Abschnitt                       │
       │After=                 Before=                 │                                        │
       ├───────────────────────┼─────────────────────────┼──────────────────┬─────────────────────┤
       │Requires=              RequiredBy=             │ [Unit]-Abschnitt │ [Install]-Abschnitt │
       ├───────────────────────┼─────────────────────────┼──────────────────┼─────────────────────┤
       │Wants=                 WantedBy=               │ [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         │
       ├───────────────────────┼─────────────────────────┼──────────────────┴─────────────────────┤
       │Triggers=              TriggeredBy=            │ automatische Eigenschaften,            │
       │                       │                         │ siehe Hinweise unten                   │
       ├───────────────────────┼─────────────────────────┼──────────────────┬─────────────────────┤
       │Conflicts=             ConflictedBy=           │ [Unit]-Abschnitt │ eine automatische   │
       │                       │                         │                  │ Eigenschaft         │
       ├───────────────────────┼─────────────────────────┼──────────────────┴─────────────────────┤
       │PropagatesReloadTo=    ReloadPropagatedFrom=   │                                        │
       ├───────────────────────┼─────────────────────────┤ [Unit]-Abschnitt                       │
       │ReloadPropagatedFrom=  PropagatesReloadTo=     │                                        │
       ├───────────────────────┼─────────────────────────┼──────────────────┬─────────────────────┤
       │Following=             │ n.Z.                    │ eine             │                     │
       │                       │                         │ automatische     │                     │
       │                       │                         │ Eigenschaft      │                     │
       └───────────────────────┴─────────────────────────┴──────────────────┴─────────────────────┘

       Beachten Sie: WantedBy= und RequiredBy= werden im Abschnitt [Install]
       verwandt, um Symlinks in .wants/- und .requires/-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.

       WantedBy=, RequiredBy=
           Diese Option kann mehr als einmal verwendet werden oder eine durch
           Leerzeichen getrennte Liste von Unit-Namen kann übergeben werden. Im
           .wants/- oder .requires/-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= oder
           Requires= von der aufgeführten Unit zu der aktuellen Unit
           hinzugefügt. Das Hauptergebnis besteht darin, dass die aktuelle Unit
           gestartet wird, wenn die aufgeführte Unit gestartet wird. Siehe die
           Beschreibung von Wants= und Requires= im Abschnitt [Unit] für
           Details.

           WantedBy=foo.service in einem Dienst bar.service ist größtenteils
           äquivalent zu Alias=foo.service.wants/bar.service in der gleichen
           Datei. Im Falle von Vorlagen-Units muss systemctl enable mit einem
           Instanzennamen aufgerufen werden und diese Instanz wird zu der
           .wants/- oder .requires/-Liste der aufgeführten Unit hinzugefügt. So
           wird z.B. WantedBy=getty.target in einem Dienst getty@.service dazu
           führen, dass systemctl enable getty@tty2.service einen Link
           getty.target.wants/getty@tty2.service auf getty@.service erstellt.

       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.

       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.

       Die folgenden Kennzeicher werden in dem Abschnitt Install interpretiert:
       %n, %N, %p, %i, %j, %g, %G, %U, %u, %m, %H, %b, %v. 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 4. In Unit-Dateien verfügbare Kennzeichner
       ┌─────────────┬────────────────────────────────┬─────────────────────────────────────┐
       │Kennzeichner Bedeutung                      Details                             │
       ├─────────────┼────────────────────────────────┼─────────────────────────────────────┤
       │"%a"         │ Architektur                    │ Eine kurze                          │
       │             │                                │ Zeichenkette, die                   │
       │             │                                │ die Architektur des                 │
       │             │                                │ lokalen Systems                     │
       │             │                                │ identifiziert. Eine                 │
       │             │                                │ Zeichenkette wie                    │
       │             │                                │ x86, x86-64 oder                    │
       │             │                                │ arm64. Siehe die für                │
       │             │                                │ ConditionArchitecture=              │
       │             │                                │ weiter oben                         │
       │             │                                │ definierten                         │
       │             │                                │ Architekturen für                   │
       │             │                                │ die vollständige                    │
       │             │                                │ Liste.                              │
       ├─────────────┼────────────────────────────────┼─────────────────────────────────────┤
       │"%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                   │
       │             │ Zwischenspeichers              │ /var/cache (für den                 │
       │             │                                │ Systemverwalter) oder               │
       │             │                                │ worauf der Pfad                     │
       │             │                                │ »$XDG_CACHE_HOME« zeigt             │
       │             │                                │ (für Benutzerverwalter).            │
       ├─────────────┼────────────────────────────────┼─────────────────────────────────────┤
       │"%E"         │ Wurzelverzeichnis der          │ Dies ist entweder /etc              │
       │             │ Konfiguration                  │ (für den                            │
       │             │                                │ 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.                      │
       ├─────────────┼────────────────────────────────┼─────────────────────────────────────┤
       │"%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.                 │
       ├─────────────┼────────────────────────────────┼─────────────────────────────────────┤
       │"%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.                          │
       ├─────────────┼────────────────────────────────┼─────────────────────────────────────┤
       │"%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       │ Dies ist die                        │
       │             │ des Präfixes                   │ Zeichenkette zwischen               │
       │             │                                │ dem letzten »-« und dem             │
       │             │                                │ Ende des Präfixnamens.              │
       │             │                                │ Falls es kein »-« gibt,             │
       │             │                                │ ist dies zu »%p«                    │
       │             │                                │ identisch.                          │
       ├─────────────┼────────────────────────────────┼─────────────────────────────────────┤
       │"%J"         │ Nicht maskierte                │ Identisch zu »%j«, aber             │
       │             │ abschließende Komponente       │ mit zurückgenommener                │
       │             │ des Präfixes                   │ Maskierung.                         │
       ├─────────────┼────────────────────────────────┼─────────────────────────────────────┤
       │"%L"         │ Wurzel des                     │ Dies ist entweder                   │
       │             │ Protokollierverzeichnisses     │ /var/log (für den                   │
       │             │                                │ 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.              │
       ├─────────────┼────────────────────────────────┼─────────────────────────────────────┤
       │"%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.              │
       ├─────────────┼────────────────────────────────┼─────────────────────────────────────┤
       │"%n"         │ Vollständiger Unit-Name        │                                     │
       ├─────────────┼────────────────────────────────┼─────────────────────────────────────┤
       │"%N"         │ Vollständiger Unit-Name        │ Identisch zu »%n«, aber             │
       │             │                                │ mit entfernter                      │
       │             │                                │ Typendung.                          │
       ├─────────────┼────────────────────────────────┼─────────────────────────────────────┤
       │"%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               │ Identisch zu »%p«, aber             │
       │             │ Präfixname                     │ mit zurückgenommener                │
       │             │                                │ Maskierung.                         │
       ├─────────────┼────────────────────────────────┼─────────────────────────────────────┤
       │"%s"         │ Benutzer-Shell                 │ Dies ist die Shell des              │
       │             │                                │ Benutzers, der die                  │
       │             │                                │ Diensteverwalterinstanz             │
       │             │                                │ ausführt. Im Falle des              │
       │             │                                │ Systemverwalters wird               │
       │             │                                │ dies auf »/bin/sh«                  │
       │             │                                │ aufgelöst.                          │
       ├─────────────┼────────────────────────────────┼─────────────────────────────────────┤
       │"%S"         │ Wurzel des                     │ Dies ist entweder                   │
       │             │ Zustandsverzeichnisses         │ /var/lib (für den                   │
       │             │                                │ Systemverwalter) oder               │
       │             │                                │ worauf der Pfad                     │
       │             │                                │ »$XDG_CONFIG_HOME« zeigt            │
       │             │                                │ (für Benutzerverwalter).            │
       ├─────────────┼────────────────────────────────┼─────────────────────────────────────┤
       │"%t"         │ Wurzel des                     │ Dies ist entweder /run              │
       │             │ Laufzeitverzeichnisses         │ (für den                            │
       │             │                                │ Systemverwalter) oder               │
       │             │                                │ worauf der Pfad                     │
       │             │                                │ »$XDG_RUNTIME_DIR« zeigt            │
       │             │                                │ (für Benutzerverwalter).            │
       ├─────────────┼────────────────────────────────┼─────────────────────────────────────┤
       │"%T"         │ Verzeichnis für temporäre      │ Dies ist entweder /tmp              │
       │             │ Dateien                        │ oder der Pfad, auf den              │
       │             │                                │ »$TMPDIR«, »$TEMP« oder             │
       │             │                                │ »$TMP« gesetzt ist.                 │
       ├─────────────┼────────────────────────────────┼─────────────────────────────────────┤
       │"%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.              │
       ├─────────────┼────────────────────────────────┼─────────────────────────────────────┤
       │"%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        │ Dies ist entweder                   │
       │             │ und dauerhafte temporäre       │ /var/tmp oder der Pfad,             │
       │             │ Dateien                        │ auf den »$TMPDIR«,                  │
       │             │                                │ »$TEMP« oder »$TMP«                 │
       │             │                                │ gesetzt ist.                        │
       ├─────────────┼────────────────────────────────┼─────────────────────────────────────┤
       │"%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.                      │
       ├─────────────┼────────────────────────────────┼─────────────────────────────────────┤
       │"%%"         │ Einzelnes Prozentzeichen       │ Verwenden Sie »%%« anstelle von     │
       │             │                                │ »%«, um ein einzelnes               │
       │             │                                │ Prozentzeichen festzulegen.         │
       └─────────────┴────────────────────────────────┴─────────────────────────────────────┘

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

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. Schnittstellenstabilitätszusage
           https://www.freedesktop.org/wiki/Software/systemd/InterfaceStabilityPromise


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

       Diese Übersetzung ist Freie Dokumentation; lesen Sie die GNU General
       Public License Version 3 oder neuer bezüglich der Copyright-Bedingungen.
       Es wird KEINE HAFTUNG übernommen.

       Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken
       Sie bitte eine E-Mail an <debian-l10n-german@lists.debian.org>.



systemd 246                                                      SYSTEMD.UNIT(5)