BEZEICHNUNG

       systemd.unit - Unit-Konfiguration

ÜBERSICHT

       Dienst.service, Socket.socket, Gerät.device, Einhängung.mount, Selbsteinhängung.automount,
       Auslagerung.swap, Ziel.target, Pfad.path, Timer.timer, Scheibe.slice, Bereich.scope

   System-Unit-Suchpfad
       /etc/systemd/system.control/*
       /run/systemd/system.control/*
       /run/systemd/transient/*
       /run/systemd/generator.early/*
       /etc/systemd/system/*
       /etc/systemd/system.attached/*
       /run/systemd/system/*
       /run/systemd/system.attached/*
       /run/systemd/generator/*
       …
       /lib/systemd/system/*
       /run/systemd/generator.late/*

   Benutzer-Unit-Suchpfad
       ~/.config/systemd/user.control/*
       $XDG_RUNTIME_DIR/systemd/user.control/*
       $XDG_RUNTIME_DIR/systemd/transient/*
       $XDG_RUNTIME_DIR/systemd/generator.early/*
       ~/.config/systemd/user/*
       $XDG_CONFIG_DIRS/systemd/user/*
       /etc/systemd/user/*
       $XDG_RUNTIME_DIR/systemd/user/*
       /run/systemd/user/*
       $XDG_RUNTIME_DIR/systemd/generator/*
       $XDG_DATA_HOME/systemd/user/*
       $XDG_DATA_DIRS/systemd/user/*
       …
       /usr/lib/systemd/user/*
       $XDG_RUNTIME_DIR/systemd/generator.late/*

BESCHREIBUNG

       Eine Unit-Konfigurationsdatei ist eine reine Textdatei im Ini-Format, die Informationen
       über einen Dienst, ein Socket, ein Gerät, einen Einhängepunkt, einen Selbsteinhängepunkt,
       eine Auslagerungsdatei oder -partition, ein Startziel, einen überwachten Dateipfad, einen
       von systemd(1) gesteuerten und überwachten Timer, eine Ressourcenverwaltungsscheibe oder
       eine Gruppe von extern erstellten Prozessen kodiert. Siehe systemd.syntax(7) für eine
       allgemeine Beschreibung der Syntax.

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

       Zusätzlich zu den hier beschriebenen generischen Abschnitten [Unit] und [Install] kann
       jede Unit einen typspezifischen Abschnitt haben, z.B. [Service] für eine Dienste-Unit.
       Siehe die respektiven Handbuchseiten für weitere Informationen: systemd.service(5),
       systemd.socket(5), systemd.device(5), systemd.mount(5), systemd.automount(5),
       systemd.swap(5), systemd.target(5), systemd.path(5), systemd.timer(5), systemd.slice(5),
       systemd.scope(5).

       Unit-Dateien werden von einer Reihe von Pfaden, die während der Compilierung bestimmt
       werden, geladen. Dies wird im nächsten Abschnitt beschrieben.

       Gültige Unit-Namen bestehen aus einen »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. Um auf diese
       Optionen zuzugreifen, müssen Anwendungen die Unit-Dateien selbst auswerten.

       Aliase (alternative Namen) können für Units angelegt werden, indem ein Symlink vom neuen
       Namen auf den alten Namen in einem der Unit-Suchpfade angelegt wird Beispielsweise hat
       systemd-networkd.service den Alias dbus-org.freedesktop.network1.service, der während der
       Installation als ein Symlink erstellt wird, so dass systemd auf die Anfrage über D-Bus,
       dbus-org.freedesktop.network1.service zu laden, systemd-networkd.service laden wird. Als
       weiteres Beispiel ist default.target — das Standard-Systemziel, was beim Systemstart
       gestartet wird — oft über einen Alias mit entweder multi-user.target oder graphical.target
       verbunden, um auszuwählen, was standardmäßig gestartet wird. Aliasnamen können in Befehlen
       wie disable, start, stop, status und ähnlichen und in allen Unit-Abhängigkeitsanweisungen
       einschließlich Wants=, Requires=, Before=, After= verwandt werden. Aliase können nicht mit
       dem Befehl preset verwandt werden.

       Alias unterliegen den folgenden Beschränkungen: Eine Unit eines bestimmten Typs
       (».service«, ».socket«, …) kann nur ein Alias auf einen Namen mit der gleichen Typendung
       werden. Eine einfache Unit (keine Vorlage oder Instanz) darf nur ein Alias auf einen
       einfachen Namen werden. Eine Vorlageninstanz darf nur durch eine andere Vorlageninstanz
       einen Alias erhalten und der Instanzanteil muss identisch sein. Eine Vorlage darf durch
       eine andere Vorlage einen Alias erhalten (dann gilt der Alias für alle Instanzen der
       Vorlage). Eine Vorlageninstanz (z.B. »alias@inst.service«) darf als Spezialfall ein
       Symlink auf eine andere Vorlage sein (z.B. »template@inst.service«). In diesem Fall wird
       nur für diese spezielle Instanz ein Alias angelegt, während andere Instanzen dieser
       Vorlage (z.B. »alias@foo.service«, »alias@bar.service«) keinen Alias erhalten. Diese
       Regeln erhalten die Anforderung, dass die Instanz (falls vorhanden) immer eindeutig für
       eine gegebene Unit und alle ihre Aliase definiert ist. Das Ziel des Alias-Symlinks muss
       auf einen gültigen Unit-Dateiort zeigen, d.h. der Symlink-Zieldateiname muss wie
       beschrieben auf den Symlink-Quellnamen passen und der Zielpfad muss in einem der
       Unit-Suchpfade sein, siehe nachfolgenden UNIT-DATEI-LADEPFAD für weitere Details. Beachten
       Sie, dass die Zieldatei nicht existieren könnte, d.h. der Symlink hängen könnte.

       Zusätzlich können Unit-Dateien Aliase mittels der Anweisung Alias= im Abschnitt [Install]
       festlegen. Wenn die Unit aktiviert ist, werden Symlinks für diese Namen erstellt und
       wieder entfernt, wenn die Unit deaktiviert wird. Beispielsweise legt reboot.target
       Alias=ctrl-alt-del.target so fest, dass der Symlink
       /etc/systemd/system/ctrl-alt-del.service auf die Datei reboot.target bei der Aktivierung
       erstellt wird und wenn Strg-Alt-Entf gedrückt wird, systemd nach ctrl-alt-del.service
       suchen und reboot.service ausführen wird. systemd schaut während des normalen Betriebs
       überhaupt nicht in den Abschnitt [Install], daher haben sämtliche Direktiven in diesem
       Abschnitt nur durch während der Aktivierung erstellte Symlinks eine Wirkung.

       Das Verzeichnis foo.service.wants/ kann zusammen mit der Unit-Datei foo.service
       existieren. Alle Unit-Dateien, die von so einem Verzeichnis mittels Symlink verknüpft
       sind, werden implizit als Abhängigkeiten vom Typ Wants= für die Unit hinzugefügt. Eine
       ähnliche Funktionalität existiert auch für Abhängigkeiten vom Typ Requires=, die
       Verzeichnisendung ist in diesem Fall .requires/. Diese Funktionalität ist nützlich, um
       Units in den Start von anderen Units einzuhängen, ohne ihre Unit-Dateien zu verändern. Für
       Details über die Semantik von Wants= und Requires= siehe unten. Die bevorzugte Art,
       Symlinks in den Verzeichnissen .wants/ oder .requires/ erfolgt durch die Angabe der
       Abhängigkeit in dem Abschnitt [Install] der Ziel-Unit und Erstellung des Symlinks im
       Dateisystem mittels des Befehls enable oder preset von systemctl(1). Das Ziel kann eine
       normale Unit sein (entweder einfach oder durch eine bestimmte Instanz einer
       Vorlagen-Unit). Falls die Quell-Unit eine Vorlage ist, kann die Ziel-Unit auch eine
       Vorlage sein, dann wird die Instanz zu der Ziel-Unit »weitergeleitet«, um eine gültige
       Unit-Instanz zu bilden. Das Ziel von Symlinks in .wants/ oder .requires/ muss daher auf
       einen gültigen Unit-Dateiort zeigen, d.h. der Symlink-Zielname muss die beschriebenen
       Anforderungen erfüllen und der Zielpfad muss in einem der Unit-Suchpfade liegen, siehe
       nachfolgenden UNIT-DATEI-LADEPFAD für weitere Details. Beachten Sie, dass die Zieldatei
       nicht existieren könnte, d.h. der Symlink hängen könnte.

       Zusammen mit einer Unit-Datei foo.service kann ein »Ergänzungs«-Verzeichnis foo.service.d/
       existieren. Alle Dateien mit der Endung ».conf« aus diesem Verzeichnis in alphanumerischer
       Reihenfolge zusammengeführt und ausgewertet, nachdem die Unit-Datei selbst ausgewertet
       wurde. Dies ist nützlich, um die Konfigurationseinstellungen für eine Unit zu verändern
       oder zu ergänzen, ohne die Unit-Dateien selbst verändern zu müssen. Jede Ergänzungsdatei
       muss geeignete Abschnittskopfzeilen enthalten. Für instanziierte Units wird diese Logik
       zuerst nach dem Instanzen-Unterverzeichnis ».d/« (z.B. »foo@bar.service.d/«) schauen und
       dessen ».conf«-Dateien lesen, gefolgt von dem Vorlagenunterverzeichnis ».d/« (z.B.
       »foo@.service.d/«) und den ».conf«-Dateien dort. Für Unit-Namen, die desweiteren
       Bindestriche (»-«) enthalten, wird die Menge der Verzeichnisse, die durch wiederholtes
       Abschneiden des Unit-Namens nach allen Bindestrichen entsteht, auch durchsucht.
       Insbesondere wird für einen Unit-Namen foo-bar-baz.service.d/ 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 /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 /lib/ haben. Ergänzungsdateien unter all diesen Verzeichnissen haben Vorrang vor
       der Haupt-Netdev-Datei, wo auch immer sich diese befindet. Mehrere Ergänzungsdateien mit
       verschiedenen Namen werden in lexikographischer Reihenfolge angewandt, unabhängig von dem
       Verzeichnis, in dem sie sich befinden.

       Units unterstützen auch ein Ergänzungs-Typ.d/-Verzeichnis auf oberster Ebene, wobei Typ
       z.B. »service« oder »socket« sein darf. Dies erlaubt es, die Einstellungen aller
       entsprechenden Unit-Dateien auf dem System zu verändern oder zu ergänzen. Die Formatierung
       und die Vorrangregeln bei der Anwendung von Ergänzungskonfigurationen folgen dem oben
       definiertem. Dateien in Typ.d/ haben niedrigeren Vorrang im Vergleich zu Dateien in
       namensspezifischen Außerkraftsetzungsverzeichnissen. Es gelten die normalen Regeln:
       mehrere Ergänzungsdateien mit verschiedenen Namen werden in lexikographischer Reihenfolge
       angewandt, unabhängig davon, in welchem Verzeichnis sie sich befinden, daher gilt eine
       Datei in Typ.d/ für eine Unit nur, falls es keine Ergänzung oder Maskierung mit diesem
       Namen in Verzeichnissen mit höherem Vorrang gibt. Siehe Beispiele.

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

       Wie oben erwähnt können Units von Vorlagendateien instanziiert werden. Dies erlaubt die
       Erstellung mehrere Units aus einer einzelnen Konfigurationsdatei. Falls Systemd nach einer
       Unit-Konfigurationsdatei schaut, wird es zuerst nach dem wörtlichen Dateinamen in dem
       Dateisystem suchen. Falls das zu keinem Erfolg führt und der Unit-Name das Zeichen »@«
       enthält, wird Systemd nach einer Unit-Vorlage suchen, die auch den gleichen Namen hat,
       aber mit einer entfernten Instanzzeichenkette (d.h. der Teil zwischen dem »@«-Zeichen und
       der Endung entfernt). Beispiel: Falls ein Dienst getty@tty3.service angefragt wird und
       keine Datei mit diesem Namen gefunden wird, dann wird Systemd nach getty@.service suchen
       und einen Dienst aus dieser Konfigurationsdatei instanziieren, falls sie gefunden wurde.

       Um sich innerhalb der Konfigurationsdatei auf die Instanziierungszeichenkette zu beziehen,
       können Sie den speziellen Kennzeichner »%i« in vielen Konfigurationsoptionen verwenden.
       Siehe unten für Details.

       Falls eine Unit-Datei leer ist (d.h. die Größe 0 hat) oder ein Symlink ist, der auf
       /dev/null zeigt, wird seine Konfiguration nicht geladen und sie erscheint mit einem
       Ladezustand »masked« und kann nicht aktiviert werden. Verwenden Sie dies als wirksame
       Methode, um eine Unit komplett zu deaktivieren und es somit unmöglich zu machen, sie sogar
       manuell zu starten.

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

ZEICHENKETTENMASKIERUNG FÜR DIE AUFNAHME IN UNIT-NAMEN

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

       Der Maskieralgorithmus funktioniert wie folgt: in einer gegebenen Zeichenkette wird jedes
       »/«-Zeichen durch »-« und alle anderen Zeichen außer den alphanumerischen ASCII-Zeichen,
       »:«, »_« oder ».« werden durch ihr C-artige »\x2d«-Maskierung ersetzt. Wenn ».« als erstes
       Zeichen in der maskierten Zeichenkette auftauchen würde, wird es zusätzlich mit seiner
       C-artigen Maskierung ersetzt.

       Wenn die Eingabe als absoluter Systempfad geeignet ist, wird dieser Algorithmus leicht
       erweitert: der Pfad zum Wurzelverzeichnis »/« wird als einzelner Bindestrich »-« kodiert.
       Zusätzlich werden alle führenden, abschließenden oder doppelten »/« Zeichen vor der
       Umwandlung aus der Zeichenkette entfernt. Beispiel: /foo//bar/baz/ wird »foo-bar-baz«.

       Diese Maskierung ist komplett umkehrbar, solange bekannt ist, ob die maskierte
       Zeichenkette ein Pfad war (die demaskierten Ergebnisse unterscheiden sich für Pfad- und
       Nichtpfadzeichenketten). Verwenden Sie systemd-escape --path, um Pfade zu maskieren und
       andernfalls systemd-escape ohne --path.

AUTOMATISCHE ABHÄNGIGKEITEN

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

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

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

       Beispielsweise werden Ziel-Units alle konfigurierten Abhängigkeiten des Typs Wants= oder
       Requires= mit Abhängigkeiten vom Typ After= ergänzen, 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 │
       ├──────────────────────────────┼──────────────────────────────────┤
       │/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 des     │
       │~/.config/systemd/user.control           │ DBus-APIs erstellt wird            │
       ├─────────────────────────────────────────┤ (($XDG_CONFIG_HOME wird            │
       │$XDG_RUNTIME_DIR/systemd/user.control    │ verwandt, falls gesetzt,           │
       │                                         │ andernfalls ~/.config)             │
       ├─────────────────────────────────────────┼────────────────────────────────────┤
       │$XDG_RUNTIME_DIR/systemd/transient       │ Dynamische Konfiguration für       │
       │                                         │ flüchtige Units                    │
       ├─────────────────────────────────────────┼────────────────────────────────────┤
       │$XDG_RUNTIME_DIR/systemd/generator.early │ Erstellte Units mit hoher          │
       │                                         │ Priorität (siehe early-dir in      │
       │                                         │ systemd.generator(7))              │
       ├─────────────────────────────────────────┼────────────────────────────────────┤
       │$XDG_CONFIG_HOME/systemd/user oder       │ Benutzerkonfiguration              │
       │$HOME/.config/systemd/user               │ ($XDG_CONFIG_HOME wird verwandt,   │
       │                                         │ falls gesetzt, andernfalls         │
       │                                         │ ~/.config)                         │
       ├─────────────────────────────────────────┼────────────────────────────────────┤
       │$XDG_CONFIG_DIRS/systemd/user oder       │ Zusätzliche                        │
       │/etc/xdg/systemd/user                    │ Konfigurationsverzeichnisse, wie   │
       │                                         │ diese durch die                    │
       │                                         │ XDG-Basisverzeichnis-Spezifikation │
       │                                         │ festgelegt werden                  │
       │                                         │ ($XDG_CONFIG_DIRS wird verwandt,   │
       │                                         │ falls gesetzt, andernfalls         │
       │                                         │ /etc/xdg)                          │
       ├─────────────────────────────────────────┼────────────────────────────────────┤
       │/etc/systemd/user                        │ Benutzer-Units, die vom            │
       │                                         │ Administrator erstellt wurden      │
       ├─────────────────────────────────────────┼────────────────────────────────────┤
       │$XDG_RUNTIME_DIR/systemd/user            │ Laufzeit-Units (nur verwandt,      │
       │                                         │ falls $XDG_RUNTIME_DIR gesetzt     │
       │                                         │ ist)                               │
       ├─────────────────────────────────────────┼────────────────────────────────────┤
       │/run/systemd/user                        │ Laufzeit-Units                     │
       ├─────────────────────────────────────────┼────────────────────────────────────┤
       │$XDG_RUNTIME_DIR/systemd/generator       │ Erstellte Units mit mittlerer      │
       │                                         │ Priorität (siehe normal-dir in     │
       │                                         │ systemd.generator(7))              │
       ├─────────────────────────────────────────┼────────────────────────────────────┤
       │$XDG_DATA_HOME/systemd/user oder         │ Units von Paketen, die im          │
       │$HOME/.local/share/systemd/user          │ Home-Verzeichnis installiert       │
       │                                         │ wurden ($XDG_DATA_HOME wird        │
       │                                         │ verwandt, falls gesetzt,           │
       │                                         │ andernfalls ~/.local/share)        │
       ├─────────────────────────────────────────┼────────────────────────────────────┤
       │$XDG_DATA_DIRS/systemd/user oder         │ Zusätzliche Datenverzeichnisse,    │
       │/usr/local/share/systemd/user und        │ wie diese durch die                │
       │/usr/share/systemd/user                  │ XDG-Basisverzeichnis-Spezifikation │
       │                                         │ festgelegt werden ($XDG_DATA_DIRS  │
       │                                         │ wird verwandt, falls gesetzt,      │
       │                                         │ andernfalls /usr/local/share und   │
       │                                         │ /usr/share)                        │
       ├─────────────────────────────────────────┼────────────────────────────────────┤
       │$dir/systemd/user für jedes $dir in      │ Zusätzliche Orte für installierte  │
       │$XDG_DATA_DIRS                           │ Benutzer-Units, einen für jeden    │
       │                                         │ Eintrag in $XDG_DATA_DIRS          │
       ├─────────────────────────────────────────┼────────────────────────────────────┤
       │/usr/local/lib/systemd/user              │ Benutzer-Units, die durch den      │
       │                                         │ Administrator installiert wurden   │
       ├─────────────────────────────────────────┼────────────────────────────────────┤
       │/usr/lib/systemd/user                    │ Benutzer-Units, die durch den      │
       │                                         │ Paketverwalter der Distribution    │
       │                                         │ installiert wurden                 │
       ├─────────────────────────────────────────┼────────────────────────────────────┤
       │$XDG_RUNTIME_DIR/systemd/generator.late  │ Erstellte Units mit niedriger      │
       │                                         │ Priorität (siehe late-dir in       │
       │                                         │ systemd.generator(7))              │
       └─────────────────────────────────────────┴────────────────────────────────────┘

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

           systemd-analyze --user unit-paths

       Desweiteren können zusätzliche Units aus Verzeichnissen, die nicht im Unit-Ladepfad sind,
       in Systemd hereingeladen werden, indem ein Symlink erstellt wird, der auf eine Unit-Datei
       im Verzeichnis zeigt. Sie können systemctl link für diese Aktion verwenden; siehe
       systemctl(1). Das Dateisystem, in dem sich die verlinkten Dateien befinden, muss beim
       Start von Systemd zugreifbar sein (d.h. alles unterhalb von /home/ oder /var/ ist nicht
       erlaubt, außer diese Verzeichnisse befinden sich auf dem Wurzeldateisystem).

       Es ist wichtig, »verlinkte Unit-Dateien« von »Unit-Dateien mit Alias« zu unterscheiden:
       Jeder Symlink, dessen Symlink-Ziel sich innerhalb des Unit-Ladepfades befindet, wird ein
       Alias: der Quellname und der Zielname müssen den bestimmten, oben bei der Besprechung von
       Aliasen aufgeführten Einschränkungen genügen, aber das Symlink-Ziel muss nicht existieren.
       Tatsächlich wird der Pfad zum Symlink-Ziel nicht verwandt, außer zu prüfen, ob das Ziel
       sich innerhalb des Unit-Ladepfades befindet. Im Gegensatz dazu bedeutet ein Symlink, der
       außerhalb des Unit-Ladepfades führt, eine verlinkete Unit-Datei. Beim Laden der Datei wird
       dem Symlink gefolgt, aber der Zielname wird ansonsten nicht verwandt (und braucht noch
       nicht mal ein gültiger Unit-Dateiname zu sein). Beispielsweise sind
       /etc/systemd/system/alias1.service → Dienst1.service, /etc/systemd/system/alias2.service →
       /usr/lib/systemd/Dienst1.service, /etc/systemd/system/alias3.service →
       /etc/systemd/system/Dienst1.service alle gültige Aliase und Dienst1.service wird vier
       Namen haben, selbst falls sich die Unit-Datei unter /run/systemd/system/Dienst1.service
       befindet. Im Gegensatz dazu bedeutet ein Symlink /etc/systemd/system/link1.service →
       ../link1_Dienstedatei, dass link1.service eine »verlinkte Unit« ist und der Inhalt von
       /etc/systemd/link1_Dienstedatei seine Konfiguration bereitstellt.

UNIT-MÜLLABFUHR

       Der System- und Diensteverwalter lädt die Konfiguration einer Unit automatisch, wenn die
       Unit das erste Mal referenziert wird. Er wird die Unit-Konfiguration und den Zustand
       wieder entladen, wenn die Unit nicht mehr benötigt wird (»Müllabfuhr«). Eine Unit kann
       über eine Reihe von Mechanismen referenziert werden:

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

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

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

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

        5. Die Unit ist durch ein aktives IPC-Client-Programm verankert.

        6. Die Unit ist eine besondere »ewige« Unit, die immer aktiv und geladen ist. Beispiele
           für ewige Units sind die Wurzeleinhänge-Unit -.mount und die Bereichs-Unit init.scope,
           in der der Diensteverwalter selbst lebt.

        7. Die Unit hat ihr zugeordnete laufende Prozesse.

       Die Müllabfuhrlogik kann mit der Option CollectMode= verändert werden. Diese Option
       erlaubt die Konfiguration, ob automatisches Entladen von Units, die im Zustand failed
       sind, erlaubt ist, siehe unten.

       Beachten Sie, dass beim Entladen der Konfiguration und des Zustandes einer Unit alle
       Ausführungsergebnisse, wie Exit-Codes, Exit-Signale und Resourcenverbrauch- und andere
       Statistiken, verloren gehen, außer für den Anteil, der im Protokolluntersystem gespeichert
       ist.

       Verwenden Sie systemctl daemon-reload oder einen äquivalenten Befehl, um die
       Unit-Konfiguration neu zu laden, während die Unit bereits geladen ist. In diesem Fall
       werden alle Konfigurationseinstellungen rausgeschoben und durch die neue Konfiguration
       ersetzt (die allerdings nicht sofort in Kraft sein muss), allerdings wird sämtlicher
       Laufzeitzustand gespeichert/wiederhergestellt.

[UNIT]-ABSCHNITT-OPTIONEN

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

       Description=
           Ein kurzer menschenlesbarer Titel für die Unit. Dieser kann von systemd (und anderen
           Benutzeroberflächen) als eine für den Benutzer sichtbare Bezeichnung für die Unit
           verwandt werden, daher sollte diese Zeichenkette die Unit identifizieren, statt sie zu
           beschreiben, trotz des Namens. Diese Zeichenkette sollte auch nicht nur einfach den
           Unit-Namen wiederholen. »Apache2 Webserver« ist ein gutes Beispiel. Schlechte
           Beispiele sind »leichtgewichtiger Hochleistungs-HTTP-Server« (zu generisch) oder
           »Apache2« (für Leute, die Apache nicht kennen, bedeutungslos, wiederholt den Namen der
           Unit). systemd kann dies als Substantiv in Statusnachrichten (»Starting
           description...«, »Started description.«, »Reached target description.«, »Failed to
           start description.«) verwenden, daher sollte er groß geschrieben werden und kein
           vollständiger Satz oder eine Phrase mit einem kontinuierlichen Verb sein. Schlechte
           Beispiele sind auch »exiting the container« oder »updating the database once per
           day.«.

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

           In dieser Option aufgeführte Units werden gestartet, wenn die konfigurierende Unit es
           wird. Falls allerdings die aufgeführte Unit nicht startet oder der Transaktion nicht
           hinzugefügt werden kann, hat dies keine Auswirkungen auf die Gültigkeit der
           Transaktion als Ganzes und diese Unit wird dennoch gestartet. Dies ist die empfohlene
           Art, das Starten einer Unit in den Start einer anderen Unit einzuhängen.

           Beachten Sie, dass Anforderungsabhängigkeiten nicht die Reihenfolge beeinflussen, in
           der Dienste gestartet oder gestoppt werden. Dies muss unabhängig davon mit den
           Optionen After= oder Before= konfiguriert werden. Falls die Unit foo.service die Unit
           bar.service wie mit Wants= konfiguriert hereinzieht und mit After= oder Before= keine
           Ordnung konfiguriert ist, dann werden beide Units gleichzeitig und ohne Verzögerung
           untereinander gestartet, wenn foo.service aktiviert wird.

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

           Falls diese Unit aktiviert wird, werden die aufgeführten Units ebenfalls aktiviert.
           Falls die Aktivierung einer der anderen Units fehlschlägt und eine
           Ordnungsabhängigkeit After= auf die fehlgeschlagene Unit gesetzt ist, dann wird diese
           Unit nicht gestartet. Darüberhinaus wird diese Unit gestoppt (oder neu gestartet),
           falls eine der anderen Units explizit gestoppt (oder neu gestartet) wird, unahängig
           davon, ob After= gesetzt ist oder nicht.

           Oft ist es eine bessere Wahl, Wants= statt Requires= zu verwenden, um ein System zu
           erreichen, das im Umgang mit fehlschlagenden Diensten robuster ist.

           Beachten Sie, dass dieser Abhängigkeitstyp nicht impliziert, dass andere Units immer
           im aktiven Zustand sein müssen, wenn diese Unit läuft. Insbesondere: Fehlschlagende
           Bedingungsüberprüfungen (wie ConditionPathExists=, ConditionPathIsSymbolicLink=, … —
           siehe unten) führen nicht dazu, dass der Start einer Unit mit einer
           Requires=-Abhängigkeit darauf fehlschlägt. Auch können sich einige Unit-Typen von
           selbst deaktivieren (beispielsweise kann sich ein Diensteprozess entscheiden, sich
           sauber zu beenden, oder ein Gerät könnte von einem Benutzer ausgesteckt werden), was
           nicht an die Units mit einer Requires=-Abhängigkeit übertragen wird. Verwenden Sie den
           Abhängigkeitstyp BindsTo= zusammen mit After=, um sicherzustellen, dass sich eine Unit
           niemals im aktiven Zustand befindet, ohne dass eine andere Unit sich auch in einem
           aktiven Zustand befindet (siehe unten).

       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.

       Upholds=
           Konfiguriert Abhängigkeiten ähnlich wie Wants=, aber alle in Upholds= aufgeführten
           Units starten immer, wenn sie als inaktiv oder fehlgeschlagen erkannt werden und für
           sie kein Auftrag in der Warteschlange ist so lange diese Unit aktiv ist. Während eine
           Abhängigkeit Wants= auf eine andere Unit eine einmalige Auswirkung hat, wenn diese
           Unit gestartet wird, hat eine Abhängigkeit Upholds= eine dauerhafte Auswirkung,
           fortwährend die Unit neustartend, falls notwendig. Dies ist eine Alternative zu der
           Einstellung Restart= von Dienste-Units, um sicherzustellen, dass sie am Laufen
           gehalten werden, was auch immer passiert.

           Wenn Upholds=b.service auf a.service  benutzt wird, wird diese Abhängigkeit als
           UpheldBy=a.service in der Eigenschaftsliste von b.service angezeigt. Die
           UpheldBy=-Abhängigkeit kann 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.

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

       PropagatesReloadTo=, ReloadPropagatedFrom=
           Eine Leerraum-getrennte Liste einer oder mehrerer Units, an die Neuladeanforderungen
           ausgebreitet werden sollen bzw. Units, von denen Neuladeanforderungen an diese Unit
           ausgebereitet werden sollen. Erteilen einer Neuladeanforderung an eine Unit, wird auch
           eine Neuladeanforderungen an alle Units, die mittels dieser zwei Einstellungen damit
           verlinkt sind, in die Warteschlange einstellen.

       PropagatesStopTo=, StopPropagatedFrom=
           Eine Leerraum-getrennte Liste einer oder mehrerer Units, an die Stop-Aufforderungen
           ausgebreitet werden sollen bzw. Units, von denen Stop-Aufforderungen an diese Unit
           ausgebereitet werden sollen. Erteilen einer Stop-Aufforderungen an eine Unit, wird
           auch eine Stop-Aufforderungen an alle Units, die mittels dieser zwei Einstellungen
           damit verlinkt sind, in die Warteschlange einstellen.

       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=PrivateIPC=, IPCNamespacePath= und PrivateTmp= unterstützen
           (siehe systemd.exec(5) für Details). Falls eine Unit, die diese Einstellung hat,
           gestartet wird, werden deren Prozesse die gleichen /tmp/-, /var/tmp/-, IPC- und
           Netzwerk-Namensräume wie die aufgeführte gestartete Unit haben. Falls mehrere
           aufgeführte Units bereits gestartet sind, ist nicht definiert, welchem Namensraum
           beigetreten wird. Beachten Sie, dass diese Einstellung nur Wirkung zeigt, falls
           PrivateNetwork=/NetworkNamespacePath=, PrivateIPC=/IPCNamespacePath= und/oder
           PrivateTmp= für sowohl die Unit, die dem Namensraum beitritt, als auch die Unit, deren
           Namensraum beigetreten wird, aktiviert ist.

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

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

       OnFailureJobMode=
           Akzeptiert einen Wert aus »fail«, »replace«, »replace-irreversibly«, »isolate«,
           »flush«, »ignore-dependencies«, »ignore-requirements«. Standardmäßig »replace«. Gibt
           an, 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=
           JobTimeoutSec= legt eine Zeitüberschreitung für den gesamten Auftrag fest, dessen
           Ausführung beginnt, wenn der Auftrag in die Warteschlange eingereiht wird.
           JobRunningTimeoutSec= legt eine Zeitüberschreitung fest, dessen Ausführung beginnt,
           wenn der Auftrag in der Warteschlange tatsächlich gestartet wird. Falls eine der
           beiden Begrenzungen erreicht wird, wird der Auftrag abgebrochen, die Unit wird
           allerdings ihren Zustand weder ändern noch in den Modus »failed« eintreten.

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

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

       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-Startraten-Begrenzung. Units, die häufiger als Häufung
           innherhalb der Zeitdauer Intervall gestartet werden, wird kein weiterer Start erlaubt.
           Verwenden Sie StartLimitIntervalSec=, um das Überprüfungsintervall zu konfigurieren
           und StartLimitBurst=, um zu konfigurieren, wie viele Starts pro Intervall erlaubt
           sind.

           Intervall ist eine Zeitdauer in der Standardeinheit Sekunden, aber andere Einheiten
           können angegeben werden, siehe systemd.time(5). Standardmäßig
           DefaultStartLimitIntervalSec= in der Verwalterkonfigurationsdatei und kann auf 0
           gesetzt werden, um jegliche Art von Ratenbegrenzung zu deaktivieren. Häufung ist eine
           Zahl, die in der Verwalterkonfigurationsdatei standardmäßig DefaultStartLimitBurst=
           ist.

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

           Beachten Sie, dass nicht versucht wird, Units, die für Restart= konfiguriert ist und
           die die Startbegrenzung erreichen, weiterhin zu starten; allerdings können sie zu
           einem späteren Zeitpunkt noch manuell oder von einem Timer oder Socket gestartet
           werden, nachdem das Intervall abgelaufen ist. Von diesem Zeitpunkt an ist die
           Neustartlogik wieder aktiviert. systemctl reset-failed führt dazu, dass der
           Neustartratenzähler für einen Dienst gelöscht wird, was nützlich ist, wenn der
           Administrator eine Unit manuell starten möchte und die Startbegrenzung damit in die
           Quere kommt. Ratenbegrenzung wird durchgesetzt, nachdem alle Unit-Bedingungsprüfungen
           ausgeführt wurden. Daher zählen für die Ratenbegrenzung Unit-Aktivierungen mit
           fehlgeschlagenen Bedingungen nicht mit.

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

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

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

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

       Die Optionen AssertArchitecture=, AssertVirtualization=, … sind zu Bedingungen ähnlich,
       führen aber dazu, dass Aufträge fehlschlagen (statt übersprungen zu werden). Die
       fehlgeschlagene Prüfung wird protokolliert. Units mit 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.

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

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

       ConditionArchitecture=
           Prüft, ob das System auf einer bestimmten Architektur läuft. Akzeptiert einen aus
           »x86«, »x86-64«, »ppc«, »ppc-le«, »ppc64«, »ppc64-le«, »ia64«, »parisc«, »parisc64«,
           »s390«, »s390x«, »sparc«, »sparc64«, »mips«, »mips-le«, »mips64«, »mips64-le«,
           »alpha«, »arm«, »arm-be«, »arm64«, »arm64-be«, »sh«, »sh64«, »m68k«, »tilegx«, »cris«,
           »arc«, »arc-be« oder »native«.

           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.

       ConditionFirmware=
           Prüft, ob die Firmware des Systems von einem bestimmten Typ ist. Mögliche Werte sind
           »uefi« (für Systeme mit EFI), »device-tree« (für System mit einem Gerätebaum) und
           »device-tree-compatible(xyz)« (für Systeme mit einem Gerätebaum, der kompatibel zu
           »xyz« ist).

       ConditionVirtualization=
           Prüft, ob das System in einer virtualisierten Umgebung ausgeführt wird und testet
           optional, ob es eine bestimmte Implementierung ist. Akzeptiert entweder einen
           logischen Wert, um zu prüfen, ob es in einer virtualisierten Umgebung ausgeführt wird
           oder entweder »vm« oder »container«, um gegen eine generische Art von
           Virtualisierungslösung zu prüfen oder einen aus »qemu«, »kvm«, »amazon«, »zvm«,
           »vmware«, »microsoft«, »oracle«, »powervm«, »xen«, »bochs«, »uml«, »bhyve«, »qnx«,
           »openvz«, »lxc«, »lxc-libvirt«, »systemd-nspawn«, »docker«, »podman«, »rkt«, »wsl«,
           »proot«, »pouch«, »acrn«, um gegen eine bestimmte Implementierung zu prüfen oder
           »private-users«, um zu prüfen, ob das System in einem Benutzernamensraum läuft. Siehe
           systemd-detect-virt(1) für eine vollständige Liste der bekannten
           Virtualisierungstechniken und ihrer Kennungen. Falls mehrere Virtualisierungstechniken
           verschachtelt sind, wird nur die innerste betrachtet. Der Test kann durch
           Voranstellung eines Ausrufezeichens negiert werden.

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

       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 angegebene 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«, »uefi-secureboot« und »tpm2«. 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 angegebene Verzeichnis einer Aktualisierung bedarf,
           da die Änderungszeit von /usr/ neuer als die Stempeldatei .updated in dem angegebenen
           Verzeichnis ist. Dies ist nützlich, um Offline-Aktualisierungen der
           Betriebssystemressourcen des Lieferanten in /usr/ zu implementieren, die
           Aktualisierungen von /etc/ oder /var/ beim nachfolgenden Systemstart benötigen. Units,
           die von dieser Bedingung Gebrauch machen, sollten sich vor
           systemd-update-done.service(8) einordnen, um sicherzustellen, dass sie ausgeführt
           werden, bevor die Änderungszeit der Stempeldatei zurückgesetzt wird, wodurch eine
           abgeschlossene Aktualisierung angezeigt wird.

           Falls die Option systemd.condition-needs-update= auf der Kernelbefehlszeile angegeben
           ist (sie akzeptiert einen logischen Wert), wird sie das Ergebnis dieser
           Zustandsüberprüfung außer Kraft setzen und Vorrang vor allen Dateiänderungsprüfungen
           haben. Falls die Kernelbefehlszeilenoption verwandt wird, wird
           systemd-update-done.service keine direkte Auswirkung auf die nachfolgenden
           ConditionNeedsUpdate=-Überprüfungen haben, bis das System neu gestartet und dabei die
           Kernelbefehlszeilenoption nicht mehr angegeben wird.

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

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

       ConditionFirstBoot=
           Akzeptiert ein logisches Argument. Diese Bedingung kann eingesetzt werden, um Units
           davon abhängig zu machen, ob das System erstmalig startet. Dies bedeutet grob, dass
           /etc/ nicht bestückt ist (für Details, siehe »SEMANTIK BEIM ERSTEN SYSTEMSTART« in
           machine-id(5)). 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.

           Zur Robustheit sollten sich Units mit ConditionFirstBoot=yes vor
           first-boot-complete.target anordnen und dieses passive Ziel mit Wants= hereinziehen.
           Dies stellt sicher, dass bei einem abgebrochenen ersten Systemstart die Units erneut
           beim nächsten Systemstart ausgeführt werden.

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

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

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

       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 angegebene
           Pfad sich auf einem Dateisystem oberhalb eines per Looback eingehängten Gerätes
           befindet. Es wird nicht erkannt, ob das dem Loopback zugrundeliegende Blockgerät
           verschlüsselt ist.

       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
           angegebene Gruppe oder GID passt. Diese Einstellung unterstützt den besonderen Wert
           »@system« nicht.

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

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

           Alternativ können die zwei besonderen Zeichenketten »v1« und »v2« (ohne irgendwelche
           Controller-Namen) angegeben werden. »v2« wird zutreffen, falls die vereinigte
           v2-Cgroup-Hierarchie verwandt wird und »v1« wird zutreffen, falls die veraltete
           v1-Hierarchie oder die hybride Hierarchie verwandt wird (siehe die Diskussion in
           systemd.unified_cgroup_hierarchy und systemd.legacy_systemd_cgroup_controller in
           systemd.service(5) für weitere Informationen).

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

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

       ConditionCPUFeature=
           Prüft nach, ob die angegebene CPU-Funktionalität mittels der »CPUID«-Anweisung
           verfügbar ist. Diese Bedingung macht nur auf i386- und x86-64-Prozessoren etwas. Auf
           anderen Prozessoren wird angenommen, dass die CPU die angegebene Funktionalität nicht
           unterstützt. Es prüft die Erlaubnisse »1«, »7«, »0x80000001« und »0x80000007«. Gültige
           Werte sind: »fpu«, »vme«, »de«, »pse«, »tsc«, »msr«, »pae«, »mce«, »cx8«, »apic«,
           »sep«, »mtrr«, »pge«, »mca«, »cmov«, »pat«, »pse36«, »clflush«, »mmx«, »fxsr«, »sse«,
           »sse2«, »ht«, »pni«, »pclmul«, »monitor«, »ssse3«, »fma3«, »cx16«, »sse4_1«, »sse4_2«,
           »movbe«, »popcnt«, »aes«, »xsave«, »osxsave«, »avx«, »f16c«, »rdrand«, »bmi1«, »avx2«,
           »bmi2«, »rdseed«, »adx«, »sha_ni«, »syscall«, »rdtscp«, »lm«, »lahf_lm«, »abm«,
           »constant_tsc«.

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

           Neben der genauen Übereinstimmung mit »=« und »!=« werden relative Vergleiche für
           versionierte Parameter unterstützt (z.B. »VERSION_ID«). Der Vergleichsoperator kann
           »<«, »<=«, »=«, »!=«, »>=« oder »>« sein.

       ConditionMemoryPressure=, ConditionCPUPressure=, ConditionIOPressure=
           Verifiziert, dass der gesamte Systemdruck (Speicher, CPU oder E/A) unterhalb von oder
           identisch zu einem Schwellwert ist. Diese Einstellung akzeptiert einen Schwellwert als
           Argument. Sie kann als einfacher Prozentwert, dem »%« angehängt wird, festgelegt
           werden; in diesem Fall wird der Druck als Durchschnitt über die letzten fünf Minuten
           gemessen, bevor der Versuch, die Unit zu starten, durchgeführt wird. Alternativ kann
           eine durchschnittliche Zeitdauer auch mit »/« als Trenner festgelegt werden,
           beispielsweise »10%/1min«. Die unterstützten Zeitdauern passen auf das Angebot des
           Kernels und sind auf »10sec«, »1min« und »5min« beschränkt. Zuerst wird der
           vollständige PSI geprüft, und falls dieser nicht gefunden wird, werden »einige«
           geprüft. Für weitere Details lesen Sie die Dokumentation unter PSI (Pressure Stall
           Information)[2].

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

       AssertArchitecture=, AssertVirtualization=, AssertHost=, AssertKernelCommandLine=,
       AssertKernelVersion=, AssertEnvironment=, AssertSecurity=, AssertCapability=,
       AssertACPower=, AssertNeedsUpdate=, AssertFirstBoot=, AssertPathExists=,
       AssertPathExistsGlob=, AssertPathIsDirectory=, AssertPathIsSymbolicLink=,
       AssertPathIsMountPoint=, AssertPathIsReadWrite=, AssertPathIsEncrypted=,
       AssertDirectoryNotEmpty=, AssertFileNotEmpty=, AssertFileIsExecutable=, AssertUser=,
       AssertGroup=, AssertControlGroupController=, AssertMemory=, AssertCPUs=, AssertOSRelease=,
       AssertMemoryPressure=, AssertCPUPressure=, AssertIOPressure=
           Ähnlich zu den oben beschriebenen Bedingungseinstellungen ConditionArchitecture=,
           ConditionVirtualization=, … fügen diese Einstellungen Zusicherungsprüfungen zum
           Hochfahren der Unit hinzu. Anders als bei den Bedingungseinstellungen führt jede
           Zusicherungseinstellung, die nicht erfüllt wird, zu einem Fehlschlag des Startauftrags
           (das bedeutet, dass es laut protokolliert wird). Beachten Sie, dass das Erreichen
           einer konfigurierten Zusicherung nicht dazu führt, dass die Unit in den Zustand
           »failed« eintritt (oder tatsächlich zu irgendeiner Zustandsänderung der Unit führt).
           Verwenden Sie Zusicherungsausdrücke für Units, die nicht agieren können, falls
           bestimmte Anforderungen nicht erfüllt sind und wenn dies etwas ist, was sich der
           Administrator oder Benutzer anschauen sollte.

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.

           Falls Vorlagen-Units nicht-Vorlagen-Units aufführen, muss in der aufführenden Unit
           DefaultInstance= gesetzt sein oder systemctl enable muss mit einem Instanzennamen
           aufgerufen werden. Die Instanz (entweder die Vorgabe oder die angegebene) wird zu der
           Liste der .wants/ oder .requires/ der aufgeführten Unit hinzugefügt. Zum Beispiel
           führt WantedBy=getty.target in einem Dienst getty@.service dazuz, dass systemctl
           enable getty@tty2.service einen Link getty.target.wants/getty@tty2.service auf
           getty@.service erstellt. Dies gilt auch für das Aufführen bestimmter Instanzen aus
           einer Vorlagen-Unit: diese bestimmte Instanz wird die Abhängigkeit erhalten. Eine
           Vorlagen-Unit kann auch eine Vorlagen-Unit aufführen. Dann wird eine generische
           Abhängigkeit hinzugefügt, bei der jede Instanz der aufführenden Unit eine Abhängigkeit
           auf eine Instanz der aufgeführten Vorlagen-Unit mit dem gleichen Instanzwert haben
           wird. Beispielsweise wird WantedBy=container@.target dazu führen, dass systemctl
           enable monitor@.service einen Dienste-Link container@.target.wants/monitor@.service
           auf monitor@.service erstellt, der für alle Instanzen von container@.target gilt.

       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: %a, %b, %B, %g,
       %G, %H, %i, %j, %l, %m, %n, %N, %o, %p, %u, %U, %v, %w, %W, %% . Ihre Bedeutung ist im
       nächsten Abschnitt beschrieben.

KENNZEICHNER

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

       Tabelle 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.                       │
       ├─────────────┼────────────────────────────────┼───────────────────────────────────────────┤
       │"%A"         │ Betriebssystemabbildversion    │ Die                                       │
       │             │                                │ Betriebssystemabbildversionskennzeichnung │
       │             │                                │ des laufenden Systems,                    │
       │             │                                │ wie aus dem Feld                          │
       │             │                                │ IMAGE_VERSION= in                         │
       │             │                                │ /etc/os-release                           │
       │             │                                │ ausgelesen. Falls nicht                   │
       │             │                                │ gesetzt, wird es die                      │
       │             │                                │ leere Zeichenkette.                       │
       │             │                                │ Siehe os-release(5) für                   │
       │             │                                │ weitere Informationen.                    │
       ├─────────────┼────────────────────────────────┼───────────────────────────────────────────┤
       │"%b"         │ Boot-Kennung                   │ Die Boot-Kennung des laufenden Systems,   │
       │             │                                │ formatiert als Zeichenkette. Siehe        │
       │             │                                │ random(4) für weitere Informationen.      │
       ├─────────────┼────────────────────────────────┼───────────────────────────────────────────┤
       │"%B"         │ Betriebssystembaukennung       │ Die Betriebssystembaukennung des          │
       │             │                                │ laufenden Systems, wie aus dem Feld       │
       │             │                                │ BUILD_ID= in /etc/os-release ausgelesen.  │
       │             │                                │ Falls nicht gesetzt, wird es zur leeren   │
       │             │                                │ Zeichenkette aufgelöst. Siehe             │
       │             │                                │ os-release(5) für weitere Informationen.  │
       ├─────────────┼────────────────────────────────┼───────────────────────────────────────────┤
       │"%C"         │ Wurzelverzeichnis des          │ Dies ist entweder /var/cache (für den     │
       │             │ Zwischenspeichers              │ Systemverwalter) oder worauf der Pfad     │
       │             │                                │ »$XDG_CACHE_HOME« zeigt (für              │
       │             │                                │ Benutzerverwalter).                       │
       ├─────────────┼────────────────────────────────┼───────────────────────────────────────────┤
       │"%d"         │ Zugangsdaten-Verzeichnis       │ Dies ist der Wert der Umgebungsvariablen  │
       │             │                                │ »$CREDENTIALS_DIRECTORY«, falls           │
       │             │                                │ verfügbar. Siehe den Abschnitt            │
       │             │                                │ »Zugangsdaten« in systemd.exec(5) für     │
       │             │                                │ weitere Informationen.                    │
       ├─────────────┼────────────────────────────────┼───────────────────────────────────────────┤
       │"%E"         │ Wurzelverzeichnis der          │ Dies ist entweder /etc/ (für den          │
       │             │ Konfiguration                  │ Systemverwalter) oder worauf der Pfad     │
       │             │                                │ »$XDG_CONFIG_HOME« zeigt (für             │
       │             │                                │ Benutzerverwalter).                       │
       ├─────────────┼────────────────────────────────┼───────────────────────────────────────────┤
       │"%f"         │ Demaskierter Dateiname         │ Dies ist entweder der demaskierte         │
       │             │                                │ Instanzenname (falls zutreffend), dem /   │
       │             │                                │ vorangestellt wurde (falls zutreffend),   │
       │             │                                │ oder der desmaskierte Präfixname, dem /   │
       │             │                                │ vorangestellt wurde. Hiermit wird das     │
       │             │                                │ Demaskieren entsprechend den oben         │
       │             │                                │ beschriebenen Regeln des Maskierens       │
       │             │                                │ absoluter Dateisystempfade implementiert. │
       ├─────────────┼────────────────────────────────┼───────────────────────────────────────────┤
       │"%g"         │ Benutzergruppe                 │ Dies ist der Name der Gruppe, die die     │
       │             │                                │ Diensteverwalterinstanz ausführt. Im      │
       │             │                                │ Falle des Systemverwalters löst sich dies │
       │             │                                │ auf »root« auf.                           │
       ├─────────────┼────────────────────────────────┼───────────────────────────────────────────┤
       │"%G"         │ Benutzer-GID                   │ Dies ist die numerische GID des           │
       │             │                                │ Benutzers, der die                        │
       │             │                                │ Diensteverwalterinstanz ausführt. Im      │
       │             │                                │ Falle des Systemverwalters löst sich dies │
       │             │                                │ auf »0« auf.                              │
       ├─────────────┼────────────────────────────────┼───────────────────────────────────────────┤
       │"%h"         │ Benutzer-Home-Verzeichnis.     │ Dies ist das Home-Verzeichnis des         │
       │             │                                │ Benutzers, der die                        │
       │             │                                │ Diensteverwalterinstanz ausführt. Im      │
       │             │                                │ Falle des Systemverwalters löst sich dies │
       │             │                                │ auf »/root« auf.                          │
       │             │                                │                                           │
       │             │                                │ Beachten Sie, dass diese Einstellung      │
       │             │                                │ nicht von der im Abschnitt [Service] der  │
       │             │                                │ Dienste-Unit konfigurierbaren Einstellung │
       │             │                                │ User= beeinflusst wird.                   │
       ├─────────────┼────────────────────────────────┼───────────────────────────────────────────┤
       │"%H"         │ Rechnername                    │ Der Rechnername des laufenden Systems zum │
       │             │                                │ Zeitpunkt des Ladens der                  │
       │             │                                │ Unit-Konfiguration.                       │
       ├─────────────┼────────────────────────────────┼───────────────────────────────────────────┤
       │"%i"         │ Instanzenname                  │ Für instanziierte Units ist dies die      │
       │             │                                │ Zeichenkette zwischen dem ersten          │
       │             │                                │ »@«-Zeichen und der Typendung. Leer für   │
       │             │                                │ nichtinstanziierte Units.                 │
       ├─────────────┼────────────────────────────────┼───────────────────────────────────────────┤
       │"%I"         │ Demaskierter Instanzenname     │ Identisch zu »%i«, aber mit               │
       │             │                                │ zurückgenommener Maskierung.              │
       ├─────────────┼────────────────────────────────┼───────────────────────────────────────────┤
       │"%j"         │ Abschließende Komponente       │ Dies ist die Zeichenkette zwischen dem    │
       │             │ des Präfixes                   │ letzten »-« und dem Ende des              │
       │             │                                │ Präfixnamens. Falls es kein »-« gibt, ist │
       │             │                                │ dies zu »%p« identisch.                   │
       ├─────────────┼────────────────────────────────┼───────────────────────────────────────────┤
       │"%J"         │ Nicht maskierte                │ Identisch zu »%j«, aber mit               │
       │             │ abschließende Komponente       │ zurückgenommener Maskierung.              │
       │             │ des Präfixes                   │                                           │
       ├─────────────┼────────────────────────────────┼───────────────────────────────────────────┤
       │"%l"         │ Kurzer Rechnername             │ Der Rechnername des laufenden Systems zum │
       │             │                                │ Zeitpunkt des Ladens der                  │
       │             │                                │ Unit-Konfiguration, abgeschnitten am      │
       │             │                                │ ersten Punkt, um alle Domain-Komponenten  │
       │             │                                │ zu entfernen.                             │
       ├─────────────┼────────────────────────────────┼───────────────────────────────────────────┤
       │"%L"         │ Wurzel des                     │ Dies ist entweder /var/log (für den       │
       │             │ Protokollierverzeichnisses     │ Systemverwalter) oder worauf der Pfad     │
       │             │                                │ »$XDG_CONFIG_HOME« zeigt, mit angehängtem │
       │             │                                │ /log (für Benutzerverwalter).             │
       ├─────────────┼────────────────────────────────┼───────────────────────────────────────────┤
       │"%m"         │ Maschinenkennung               │ Die Maschinenkennung des laufenden        │
       │             │                                │ Systems, formatiert als Zeichenkette.     │
       │             │                                │ Siehe machine-id(5) für weitere           │
       │             │                                │ Informationen.                            │
       ├─────────────┼────────────────────────────────┼───────────────────────────────────────────┤
       │"%M"         │ Betriebssystemabbildkennung    │ Die Betriebssystemabbildkennung des       │
       │             │                                │ laufenden Systems, wie aus dem Feld       │
       │             │                                │ IMAGE_ID= in /etc/os-release ausgelesen.  │
       │             │                                │ Falls nicht gesetzt, wird es die leere    │
       │             │                                │ Zeichenkette. Siehe os-release(5) für     │
       │             │                                │ weitere Informationen.                    │
       ├─────────────┼────────────────────────────────┼───────────────────────────────────────────┤
       │"%n"         │ Vollständiger Unit-Name        │                                           │
       ├─────────────┼────────────────────────────────┼───────────────────────────────────────────┤
       │"%N"         │ Vollständiger Unit-Name        │ Identisch zu »%n«, aber mit entfernter    │
       │             │                                │ Typendung.                                │
       ├─────────────┼────────────────────────────────┼───────────────────────────────────────────┤
       │"%o"         │ Betriebssystemkennung          │ Die Betriebssystemkennung des laufenden   │
       │             │                                │ Systems, wie aus dem Feld ID= in          │
       │             │                                │ /etc/os-release ausgelesen. Siehe         │
       │             │                                │ os-release(5) für weitere Informationen.  │
       ├─────────────┼────────────────────────────────┼───────────────────────────────────────────┤
       │"%p"         │ Präfixname                     │ Für instanziierte Units bezieht sich das  │
       │             │                                │ auf die Zeichenkette vor dem ersten       │
       │             │                                │ »@«-Zeichen des Unit-Namens. Für nicht    │
       │             │                                │ instanziierte Units identisch zu »%N«.    │
       ├─────────────┼────────────────────────────────┼───────────────────────────────────────────┤
       │"%P"         │ Nicht maskierter Präfixname    │ Identisch zu »%p«, aber mit               │
       │             │                                │ zurückgenommener Maskierung.              │
       ├─────────────┼────────────────────────────────┼───────────────────────────────────────────┤
       │"%q"         │ Schöner Rechnername            │ Der schöne Rechnername des laufenden      │
       │             │                                │ Systems zum Zeitpunkt des Ladens der      │
       │             │                                │ Unit-Konfiguration, wie aus dem Feld      │
       │             │                                │ PRETTY_HOSTNAME= in /etc/machine-info     │
       │             │                                │ ausgelesen. Falls nicht gesetzt, wird es  │
       │             │                                │ auf den kurzen Rechnernamen gesetzt.      │
       │             │                                │ Siehe machine-info(5) für weitere         │
       │             │                                │ Informationen.                            │
       ├─────────────┼────────────────────────────────┼───────────────────────────────────────────┤
       │"%s"         │ Benutzer-Shell                 │ Dies ist die Shell des Benutzers, der die │
       │             │                                │ Diensteverwalterinstanz ausführt. Im      │
       │             │                                │ Falle des Systemverwalters wird dies auf  │
       │             │                                │ »/bin/sh« aufgelöst.                      │
       ├─────────────┼────────────────────────────────┼───────────────────────────────────────────┤
       │"%S"         │ Wurzel des                     │ Dies ist entweder /var/lib (für den       │
       │             │ Zustandsverzeichnisses         │ Systemverwalter) oder worauf der Pfad     │
       │             │                                │ »$XDG_CONFIG_HOME« zeigt (für             │
       │             │                                │ Benutzerverwalter).                       │
       ├─────────────┼────────────────────────────────┼───────────────────────────────────────────┤
       │"%t"         │ Wurzel des                     │ Dies ist entweder /run/ (für den          │
       │             │ Laufzeitverzeichnisses         │ Systemverwalter) oder worauf der Pfad     │
       │             │                                │ »$XDG_RUNTIME_DIR« zeigt (für             │
       │             │                                │ Benutzerverwalter).                       │
       ├─────────────┼────────────────────────────────┼───────────────────────────────────────────┤
       │"%T"         │ Verzeichnis für temporäre      │ Dies ist entweder /tmp oder der Pfad, auf │
       │             │ Dateien                        │ den »$TMPDIR«, »$TEMP« oder »$TMP«        │
       │             │                                │ gesetzt ist. (Beachten Sie, dass das      │
       │             │                                │ Verzeichnis ohne abschließenden           │
       │             │                                │ Schrägstrich angegeben werden kann.)      │
       ├─────────────┼────────────────────────────────┼───────────────────────────────────────────┤
       │"%u"         │ Benutzername                   │ Dies ist der Name des Benutzers, der die  │
       │             │                                │ Diensteverwalterinstanz ausführt. Im      │
       │             │                                │ Falle des Systemverwalters löst sich dies │
       │             │                                │ auf »root« auf.                           │
       │             │                                │                                           │
       │             │                                │ Beachten Sie, dass diese Einstellung      │
       │             │                                │ nicht von der im Abschnitt [Service] der  │
       │             │                                │ Dienste-Unit konfigurierbaren Einstellung │
       │             │                                │ User= beeinflusst wird.                   │
       ├─────────────┼────────────────────────────────┼───────────────────────────────────────────┤
       │"%U"         │ Benutzer-UID                   │ Dies ist die numerische UID des           │
       │             │                                │ Benutzers, der die                        │
       │             │                                │ Diensteverwalterinstanz ausführt. Im      │
       │             │                                │ Falle des Systemverwalters löst sich dies │
       │             │                                │ auf »0« auf.                              │
       │             │                                │                                           │
       │             │                                │ Beachten Sie, dass diese Einstellung      │
       │             │                                │ nicht von der im Abschnitt [Service] der  │
       │             │                                │ Dienste-Unit konfigurierbaren Einstellung │
       │             │                                │ User= beeinflusst wird.                   │
       ├─────────────┼────────────────────────────────┼───────────────────────────────────────────┤
       │"%v"         │ Kernelveröffentlichung         │ Identisch zur Ausgabe von uname -r.       │
       ├─────────────┼────────────────────────────────┼───────────────────────────────────────────┤
       │"%V"         │ Verzeichnis für größere und    │ Dies ist entweder /var/tmp oder der Pfad, │
       │             │ dauerhafte temporäre           │ auf den »$TMPDIR«, »$TEMP« oder »$TMP«    │
       │             │ Dateien                        │ gesetzt ist. (Beachten Sie, dass das      │
       │             │                                │ Verzeichnis ohne abschließenden           │
       │             │                                │ Schrägstrich angegeben werden kann.)      │
       ├─────────────┼────────────────────────────────┼───────────────────────────────────────────┤
       │"%w"         │ Betriebssystemversionskennung  │ Die Betriebssystemversionskennzeichnung   │
       │             │                                │ des laufenden Systems, wie aus dem Feld   │
       │             │                                │ VERSION_ID= in /etc/os-release            │
       │             │                                │ ausgelesen. Falls nicht gesetzt, wird es  │
       │             │                                │ die leere Zeichenkette. Siehe             │
       │             │                                │ os-release(5) für weitere Informationen.  │
       ├─────────────┼────────────────────────────────┼───────────────────────────────────────────┤
       │"%W"         │ Betriebssystemvariantenkennung │ Die Betriebssystemvariantenkennung des    │
       │             │                                │ laufenden Systems, wie aus dem Feld       │
       │             │                                │ VARIANT_ID= in /etc/os-release            │
       │             │                                │ ausgelesen. Falls nicht gesetzt, wird es  │
       │             │                                │ die leere Zeichenkette. Siehe             │
       │             │                                │ os-release(5) für weitere Informationen.  │
       ├─────────────┼────────────────────────────────┼───────────────────────────────────────────┤
       │"%y"         │ Der Pfad zum Fragment.         │ Dies ist der Pfad dorthin, wo sich der    │
       │             │                                │ Hauptteil der Unit-Datei befindet. Für    │
       │             │                                │ verlinkte Unit-Dateien wird der echte     │
       │             │                                │ Pfad außerhalb der Unit-Suchverzeichnisse │
       │             │                                │ verwandt. Für Units ohne Fragementdateien │
       │             │                                │ wird der Kennzeichner einen Fehler        │
       │             │                                │ hervorrufen.                              │
       ├─────────────┼────────────────────────────────┼───────────────────────────────────────────┤
       │"%Y"         │ Das Verzeichnis des Fragement. │ Dies ist der Verzeichnisanteil von »%y«.  │
       ├─────────────┼────────────────────────────────┼───────────────────────────────────────────┤
       │"%%"         │ Einzelnes Prozentzeichen       │ Verwenden Sie »%%« anstelle von »%«, um   │
       │             │                                │ ein einzelnes Prozentzeichen anzugeben.   │
       └─────────────┴────────────────────────────────┴───────────────────────────────────────────┘

BEISPIELE

       Beispiel 1. Units erlauben, freigegeben zu werden

       Der nachfolgende Schnipsel (hervorgehoben) erlaubt es einer Unit (z.B. foo.service),
       mittels systemctl enable freigegeben zu werden:

           [Unit]
           Description=Foo

           [Service]
           ExecStart=/usr/sbin/foo-daemon

           [Install]
           WantedBy=multi-user.target

       Nach der Ausführung von systemctl enable verlinkt ein Symlink
       /etc/systemd/system/multi-user.target.wants/foo.service auf die tatsächlich zu erstellende
       Unit-Datei. Er teilt Systemd mit, die Unit beim Starten von multi-user.target
       hereinzuziehen. Das inverse systemctl disable wird diesen Symlink wieder entfernen.

       Beispiel 2. Lieferanteneinstellungen außer Kraft setzen

       Es gibt zwei Methoden, die Lieferanteneinstellungen in Unit-Dateien außer Kraft zu setzen:
       Kopieren der Unit-Datei aus /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
       /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.

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

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

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

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

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

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

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

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

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

           mkdir /etc/systemd/system/failure-handler@.service.d/
           ln -s /dev/null /etc/systemd/system/failure-handler@.service.d/10-all.conf
           systemctl daemon-reload

       Dies stellt sicher, dass eine Instanz von failure-handler@.service fehlschlägt, falls sie
       keine Instanz namens failure-handler@failure-handler.service auslöst.

SIEHE AUCH

       systemd(1), systemctl(1), systemd-system.conf(5), systemd.special(7), systemd.service(5),
       systemd.socket(5), systemd.device(5), systemd.mount(5), systemd.automount(5),
       systemd.swap(5), systemd.target(5), systemd.path(5), systemd.timer(5), systemd.scope(5),
       systemd.slice(5), systemd.time(7), systemd-analyze(1), capabilities(7),
       systemd.directives(7), uname(1)

ANMERKUNGEN

        1. Schnittstellenportabilitäts- und -stabilitätszusage
           https://systemd.io/PORTABILITY_AND_STABILITY/

        2. PSI (Pressure Stall Information)
           https://www.kernel.org/doc/html/latest/accounting/psi.html

ÜBERSETZUNG

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

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

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