Provided by: manpages-de_2.14-1_all bug

BEZEICHNUNG

       systemd.unit - Unit-Konfiguration

ÜBERSICHT

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

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

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

BESCHREIBUNG

       Eine Unit-Konfigurationsdatei ist eine reine Textdatei im Ini-Format, die Informationen
       über einen Dienst, ein Socket, ein Gerät, einen Einhängepunkt, einen automatischen
       Einhängepunkt, eine Auslagerungsdatei oder -partition, ein Startziel, einen überwachten
       Dateipfad, einen von systemd(1) gesteuerten und überwachten Zeitgeber, eine
       Ressourcenverwaltungsscheibe oder eine Gruppe von extern erstellten Prozessen kodiert.
       Siehe systemd.syntax(5) 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.

       Unit-Dateien können durch einen einzelnen Parameter, genannt »Instanzenname«,
       parametrisiert werden. Die Unit wird dann, basierend auf einer »Vorlagendatei«, die als
       Definition mehrerer Dienste oder anderer Units dient, konstruiert. Eine Vorlagendatei muss
       ein einzelnes »@« am Ende des Namens haben (direkt vor der Typendung). Der Name der
       kompletten Unit wird durch Einfügung des Instanzennamens zwischen dem @ und der
       Unit-Typendung gebildet. In der Unit-Datei selbst kann auf den Instanzenparameter mittels
       »%i« und anderen Kennzeichnern Bezug genommen werden, siehe unten.

       Unit-Dateien dürfen zusätzliche zu den hier aufgeführten Optionen enthalten. Falls Systemd
       auf eine unbekannte Option stößt, wird es eine Warnprotokollnachricht schreiben, aber mit
       dem Laden der Unit fortfahren. Falls vor einer Option oder einem Abschnittnamen ein X-
       steht, wird diese(r) von Systemd komplett ignoriert. Optionen innerhalb eines ignorierten
       Abschnittes benötigen die vorangestellte Kennung nicht. Anwendungen können dies dazu
       verwenden, zusätzliche Informationen in den Unit-Dateien aufzunehmen.

       Aliase (alternative Namen) können für Units angelegt werden, indem ein Symlink vom neuen
       Namen auf den alten Namen in einem der Unit-Suchpfade angelegt wird Beispielsweise hat
       systemd-networkd.service den Alias dbus-org.freedesktop.network1.service, der während der
       Installation als Symlink /lib/systemd/system/dbus-org.freedesktop.network1.service
       erstellt wurde. Zusätzlich können Unit-Dateien Aliase mittels der Anweisung Alias= im
       Abschnitt [Install] festlegen. Diese Aliase sind nur wirksam, wenn die Unit aktiviert ist,
       dann werden Symlinks für diese Namen erstellt und wieder entfernt, wenn die Unit
       deaktiviert wird. Beispielsweise legt reboot.target Alias=ctrl-alt-del.target fest, daher
       wird sie aufgerufen, wenn sie aktiviert ist und STRG-ALT+ENTF gedrückt wird. Aliasnamen
       können in Befehlen wie enable, disable, start, stop, status, … und in
       Unit-Abhängigkeitsanweisungen Wants=, Requires=, Before=, After= mit der Einschränkung
       verwandt werden, dass die durch Alias= festgelegten Aliase nur wirksam sind, wenn die Unit
       aktiviert ist. Aliase können nicht mit dem Befehl preset verwandt werden.

       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. Dies ist
       nützlich, um Units in den Start von anderen Units einzuhängen, ohne ihre Unit-Dateien zu
       verändern. Für Details über die Semantik von Wants= siehe unten. Die bevorzugte Art,
       Symlinks in den Verzeichnissen .wants/ einer Unit-Datei zu erstellen, ist über den Befehl
       enable des Werkzeugs systemctl(1), der Informationen vom Abschnitt [Install] von
       Unit-Dateis liest (siehe unten). Eine ähnliche Funktionalität existiert auch für
       Abhängigkeiten vom Typ Requires=, die Verzeichnisendung ist in diesem Fall .requires/.

       Zusammen mit einer Unit-Datei foo.service kann ein »Ergänzungs«-Verzeichnis foo.service.d/
       existieren. Alle Dateien mit der Endung ».conf« aus diesem Verzeichnis werden, nachdem die
       Unit-Datei selbst ausgewertet wurde, ausgewertet. Dies ist nützlich, um die
       Konfigurationseinstellungen für eine Unit zu verändern oder zu ergänzen, ohne die
       Unit-Dateien selbst verändern zu müssen. Ergänzungsdateien müssen geeignete
       Abschnittskopfzeilen enthalten. Für instanziierte Units wird diese Logik zuerst nach dem
       Instanzen-Unterverzeichnis ».d/« (z.B. »foo@bar.service.d/«) schauen und dessen
       ».conf«-Dateien lesen, gefolgt von dem Vorlagenunterverzeichnis ».d/« (z.B.
       »foo@.service.d/«) und den ».conf«-Dateien dort. Für Unit-Namen, die desweiteren
       Gedankenstriche (»-«) enthalten, wird die Menge der Verzeichnisse, die durch Abschneiden
       des Unit-Namens nach allen Gedankenstrichen 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 Gedankenstriche 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.

       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.

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

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

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

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

       Das Unit-Dateiformat wird durch die Schnittstellenstabilitätszusage[1] abgedeckt.

ZEICHENKETTENMASKIERUNG FÜR DIE AUFNAHME IN UNIT-NAMEN

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

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

       Wenn die Eingabe als absoluter Systempfad geeignet ist, wird dieser Algorithmus leicht
       erweitert: der Pfad zum Wurzelverzeichnis »/« wird als einzelner Gedankenstrich »-«
       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).
       ┌──────────────────────────────┬─────────────────────────────────┐
       │PfadBeschreibung                    │
       ├──────────────────────────────┼─────────────────────────────────┤
       │/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           │ Lokale Konfiguration            │
       ├──────────────────────────────┼─────────────────────────────────┤
       │/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 │                                 │
       ├──────────────────────────────┤ Units von installierten Paketen │
       │/lib/systemd/system           │                                 │
       ├──────────────────────────────┼─────────────────────────────────┤
       │/run/systemd/generator.late   │ Erstellte Units mit niedriger   │
       │                              │ Priorität (siehe late-dir in    │
       │                              │ systemd.generator(7))           │
       └──────────────────────────────┴─────────────────────────────────┘

       Tabelle 2.  Ladepfad bei der Ausführung im Benutzermodus
       (--user).

       ┌────────────────────────────────────────┬──────────────────────────────────┐
       │PfadBeschreibung                     │
       ├────────────────────────────────────────┼──────────────────────────────────┤
       │$XDG_CONFIG_HOME/systemd/user.controlDauerhafte und flüchtige         │
       │oderKonfiguration, die mittels des   │
       │~/.config/systemd/user.controlDBus-APIs erstellt wird          │
       ├────────────────────────────────────────┤ (($XDG_CONFIG_HOME wird          │
       │$XDG_RUNTIME_DIR/systemd/user.controlverwandt, falls gesetzt,         │
       │                                        │ andernfalls ~/.config)           │
       ├────────────────────────────────────────┼──────────────────────────────────┤
       │/run/systemd/transientDynamische Konfiguration für     │
       │                                        │ flüchtige Units                  │
       ├────────────────────────────────────────┼──────────────────────────────────┤
       │/run/systemd/generator.earlyErstellte Units mit hoher        │
       │                                        │ Priorität (siehe early-dir in    │
       │                                        │ systemd.generator(7))            │
       ├────────────────────────────────────────┼──────────────────────────────────┤
       │$XDG_CONFIG_HOME/systemd/user oderBenutzerkonfiguration            │
       │$HOME/.config/systemd/user($XDG_CONFIG_HOME wird verwandt, │
       │                                        │ falls gesetzt, andernfalls       │
       │                                        │ ~/.config)                       │
       ├────────────────────────────────────────┼──────────────────────────────────┤
       │/etc/systemd/userLokale Konfiguration             │
       ├────────────────────────────────────────┼──────────────────────────────────┤
       │$XDG_RUNTIME_DIR/systemd/userLaufzeit-Units (nur verwandt,    │
       │                                        │ falls $XDG_RUNTIME_DIR gesetzt   │
       │                                        │ ist)                             │
       ├────────────────────────────────────────┼──────────────────────────────────┤
       │/run/systemd/userLaufzeit-Units                   │
       ├────────────────────────────────────────┼──────────────────────────────────┤
       │$XDG_RUNTIME_DIR/systemd/generatorErstellte Units mit mittlerer    │
       │                                        │ Priorität (siehe normal-dir in   │
       │                                        │ systemd.generator(7))            │
       ├────────────────────────────────────────┼──────────────────────────────────┤
       │$XDG_DATA_HOME/systemd/user oderUnits von Paketen, die im        │
       │$HOME/.local/share/systemd/userHome-Verzeichnis installiert     │
       │                                        │ wurden ($XDG_DATA_HOME wird      │
       │                                        │ verwandt, falls gesetzt,         │
       │                                        │ andernfalls ~/.local/share)      │
       ├────────────────────────────────────────┼──────────────────────────────────┤
       │$dir/systemd/user für jedes $dir inZusätzliche Orte für             │
       │$XDG_DATA_DIRSinstallierte Benutzer-Units,     │
       │                                        │ einen für jeden Eintrag in       │
       │                                        │ $XDG_DATA_DIRS                   │
       ├────────────────────────────────────────┼──────────────────────────────────┤
       │/usr/local/lib/systemd/userUnits für Pakete, die systemweit │
       ├────────────────────────────────────────┤ installiert wurden               │
       │/usr/lib/systemd/user                   │                                  │
       ├────────────────────────────────────────┼──────────────────────────────────┤
       │$XDG_RUNTIME_DIR/systemd/generator.lateErstellte 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 (»gelinkt«) werden. Siehe den Befehl link für systemctl(1).

UNIT-MÜLLABFUHR

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

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

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

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

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

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

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

        7. Die Unit hat ihr zugeordnete laufende Prozesse.

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

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

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

[UNIT]-ABSCHNITT-OPTIONEN

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

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

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

       Requires=
           Konfiguriert Anforderungsabhängigkeiten auf andere Units. Falls diese Unit aktiviert
           wird, werden die hier aufgeführten Units auch aktiviert. Falls die Aktivierung einer
           der anderen Units fehlschlägt und eine Anordnungsabhängigkeit After= auf diese
           fehlgeschlagene Units gesetzt ist, wird diese Unit nicht gestartet. Außerdem wird
           diese Unit, mit oder ohne Angabe von After=, gestoppt, falls eine der anderen Units
           explizit gestoppt wird. Diese Option kann mehr als einmal angegeben oder mehrere,
           Leerzeichen-getrennte Units können in einer Option festgelegt werden; in diesem Fall
           werden für alle aufgeführten Namen Anforderungsabhängigkeiten erstellt. Beachten Sie,
           dass Anforderungsabhängigkeiten nicht die Reihenfolge, in der Dienste gestartet oder
           gestoppt werden, beeinflussen. Dies muss unabhängig mit den Optionen After= oder
           Before= konfiguriert werden. Falls eine Unit foo.service eine Unit bar.service wie mit
           Requires= konfiguriert benötigt und keine Ordnung mit After= oder Before= konfiguriert
           ist, werden beide Units simultan und ohne Verzögerung zwischen ihnen gestartet, falls
           foo.service aktiviert wird. Oft ist es eine bessere Wahl, Wants= statt Requires= zu
           verwenden, um ein System zu erreichen, das robuster ist, wenn Dienste fehlschlagen.

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

           Beachten Sie, dass Abhängigkeiten dieser Art auch außerhalb der
           Unit-Konfigurationsdatei konfiguriert werden können, indem ein Symlink auf ein die
           Unit-Datei begleitendes .requires/-Verzeichnis hinzugefügt wird. Siehe oben für
           Details.

       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.

       Wants=
           Eine schwächere Version von Requires=. 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. Dies ist die empfohlene
           Art, das Starten einer Unit in den Start einer anderen Unit einzuhängen.

           Beachten Sie, dass Abhängigkeiten dieser Art auch außerhalb der
           Unit-Konfigurationsdatei konfiguriert werden können, indem ein Symlink auf ein die
           Unit-Datei begleitendes .wants/-Verzeichnis hinzugefügt wird. Siehe oben für Details.

       BindsTo=
           Konfiguriert Anforderungsabhängigkeiten, im Stil sehr ähnlich zu Requires=. Allerdings
           ist dieser Abhängigkeitstyp stärker: Zusätzlich zu dem Effekt von Requires= deklariert
           er, dass beim Stoppen der gebundenen Unit auch diese Unit gestoppt wird. Das bedeutet,
           dass eine Unit, die an eine andere Unit gebunden ist, die plötzlich in einen inaktiven
           Zustand eintritt, auch gestoppt wird. Units können plötzlich und unerwartet aus
           verschiedenen Gründen in inaktive Zustände eintreten: Der Hauptprozess einer
           Dienste-Unit könnte sich aus eigenem Antrieb beenden, das zugrundeliegende Gerät einer
           Geräte-Unit könnte ausgesteckt werden oder der Einhängepunkt einer Einhänge-Unit
           könnte ohne Beteiligung des System- und Diensteverwalters ausgehängt werden.

           Bei der Verwendung in Verbindung mit After= auf die gleiche Unit ist das Verhalten von
           BindsTo= sogar noch stärker. In diesem Falle muss die angebundene Unit sogar in einem
           aktiven Zustand sein, damit diese Unit auch in einem aktiven Zustand ist. Dies
           bedeutet nicht nur, dass eine Unit, die an eine andere Unit angebunden ist, die
           plötzlich in einen inaktiven Zustand eintritt, sondern auch, die an eine andere Unit
           angebunden ist, die aufgrund einer fehlenden Bedingungsprüfung (wie
           ConditionPathExists=, ConditionPathIsSymbolicLink=, … \m siehe unten) übersprungen
           wird, gestoppt wird, sollte sie laufen. Daher ist es in vielen Fällen am besten,
           BindsTo= mit After= zu kombinieren.

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

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

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

       Conflicts=
           Eine Leerraum-getrennte Liste von Unit-Namen. Konfiguriert negative
           Anforderungsabhängigkeiten. Falls eine Unit eine Einstellung Conflicts= auf eine
           andere Unit hat, wird das Starten ersterer die letzere stoppen und umgekehrt. Beachten
           Sie, dass diese Einstellung unabhängig von und orthogonal zu den
           Ordnungsabhängigkeiten After= und Before= ist.

           Falls eine 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 zwei Einstellungen erwarten eine Leerraum-getrennte Liste von Unit-Namen. Sie
           konfigurieren Ordnungsabhängigkeiten zwischen Units. Falls eine Unit foo.service eine
           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.
           Beachten Sie, dass diese Einstellung unabhängig von und orthogonal zu der mit
           Requires=, Wants= oder BindsTo= konfigurierten Anforderungsabhängigkeit ist. Es ist
           ein häufiges Muster, einen Unit-Namen sowohl in die Optionen After= als auch in
           Requires= aufzunehmen; in diesem Fall wird die aufgeführte Unit vor der Unit, die mit
           diesen Optionen konfiguriert ist, gestartet. Diese Option kann mehr als einmal
           festgelegt werden, dann werden Ordnungsabhängigkeiten für alle aufgeführten Namen
           erstellt. After= ist das Inverse von Before=, d.h. während After= sicherstellt, dass
           die konfigurierte Unit gestartet wird, nachdem der Start der aufgeführten Unit
           abgeschlossen ist, stellt Before= das Gegenteil dar, dass die konfigurierte Unit
           vollständig gestartet ist, bevor die aufgeführte Unit gestartet wird. Beachten Sie,
           dass beim Herunterfahren von zwei Units, zwischen denen eine Ordunngsabhä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.

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

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

       JoinsNamespaceOf=
           Für Units, die Prozesse starten (wie Dienste-Units) werden hier eine oder mehrere
           andere Units aufgeführt, dessen Netzwerk- oder temporärem Namensraum beigetreten
           werden soll. Dies gilt nur für Unit-Typen, die die Anweisungen PrivateNetwork= und
           PrivateTmp= unterstützen (siehe systemd.exec(5) für Details). Falls eine Unit, die
           diese Einstellung hat, gestartet wird, werden deren Prozesse die gleichen /tmp-,
           /var/tmp- und Netzwerk-Namensräume wie die aufgeführte gestartete Unit haben. Falls
           mehrere aufgeführte Units bereits gestartet sind, ist nicht definiert, welchem
           Namensraum beigetreten wird. Beachten Sie, dass diese Einstellung nur Wirkung zeigt,
           falls PrivateNetwork= und/oder PrivateTmp= für sowohl die Unit, die dem Namensraum
           beitritt, als auch die Unit, deren Namensraum beigetreten wird, aktiviert ist.

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

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

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

       IgnoreOnIsolate=
           Akzeptiert ein logisches Argument. Falls true, wird die Unit nicht gestoppt, wenn eine
           andere Unit isoliert wird. Standardmäßig false für Dienste-, Ziel-, Socket-, Busname-,
           Zeitgeber- 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 true (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 false setzen. Es wird nachdrücklich
           empfohlen, diese Option für den Großteil der häufigen Units aktiviert zu lassen. Falls
           auf false 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 Zustand 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 diese
           Option verwandt wird. Standardmäßig inactive.

       FailureAction=, SuccessAction=
           Konfiguriert die durchzuführende Aktion, wenn die Unit stoppt und in einen Fehlzustand
           oder inaktiven Zustand eintritt. Akzeptiert entweder none, reboot, reboot-force,
           reboot-immediate, poweroff, poweroff-force, poweroff-immediate, exit oder exit-force.
           Im Systemmodus sind alle Optionen erlaubt. Im Benutzermodus sind nur none, exit und
           exit-force erlaubt. Beide Optionen sind standardmäßig none.

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

       FailureActionExitStatus=, SuccessActionExitStatus=
           Steuert den Exit-Status, der an den Container-Verwalter zurückgeleitet werden soll (im
           Falle von Systemdiensten) oder dem Diensteverwalter (im Falle eines
           Benutzerverwalters), wenn die FailureAction=/SuccessAction= auf exit oder exit-force
           gesetzt sind und die Aktion ausgelöst wird. Standardmäßig wird der Exit-Status des
           Hauptprozesses der auslösenden Unit (falls dies zutrifft) weitergeleitet. Akzeptiert
           einen Wert im Bereich 0…255 oder die leere Zeichenkette, um das Standardverhalten zu
           erbitten.

       JobTimeoutSec=, JobRunningTimeoutSec=
           Wenn ein Auftrag für diese Unit in die Warteschlange eingereiht wird, kann eine
           Zeitüberschreitung JobTimeoutSec= konfiguriert werden. Ähnlich zu
           JobRunningTimeoutSec= beginnt er zu zählen, wenn der in die Warteschlange eingereihte
           Auftrag tatsächlich gestartet wird. Falls eine der Zeitbegrenzungen erreicht ist, wird
           der Auftrag abgebrochen, die Unit wird allerdings nicht ihren Zustand ändern oder
           sogar den Modus »failed« einnehmen. Dieser Wert beträgt standardmäßig »infinity«
           (Auftrags-Zeitüberschreitungen deaktiviert), außer für Geräte-Units
           (JobRunningTimeoutSec= ist standardmäßig DefaultTimeoutStartSec=). Hinweis: Diese
           Zeitüberschreitung ist unabhängig von allen Unit-spezifischen Zeitüberschreitungen
           (beispielsweise den mit TimeoutStartSec= in Dienste-Units gesetzten
           Zeitüberschreitungen), da die Auftragszeitüberschreitung keine Wirkung für die Unit
           selbst hat, nur für den Auftrag, der für sie warten könnte. Oder mit anderen Worten:
           Unit-spezifische Zeitüberschreitungen sind nützlich, um Zustandsänderungen von Units
           abzubrechen und sie zurückzunehmen. Die mit dieser Option gesetzten
           Auftrags-Zeitüberschreitungen sind allerdings nur nützlich, um den Auftrag
           abzubrechen, der darauf wartet, dass die Unit den Zustand ändert.

       JobTimeoutAction=, JobTimeoutRebootArgument=
           JobTimeoutAction= konfiguriert optional eine zusätzliche Aktion, die beim Erreichen
           der Zeitüberschreitung unternommen werden soll, siehe die Beschreibung von
           JobTimeoutSec= und JobRunningTimeoutSec= oben. Es akzeptiert die gleichen Werte wie
           StartLimitAction=. Standardmäßig none. JobTimeoutRebootArgument= konfiguriert eine
           optionale Neustartzeichenkette, die an den Systemaufruf reboot(2) übergeben wird.

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

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

       StartLimitAction=
           Konfiguriert eine zusätzliche Aktion, die ergriffen werden soll, falls die mit
           StartLimitIntervalSec= und StartLimitBurst= konfigurierte Ratenbegrenzung erreicht
           wird. Akzeptiert die gleichen Werte wie die Einstellungen
           FailureAction=/SuccessAction= und führt die gleichen Aktionen aus. 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.

       ConditionArchitecture=, ConditionVirtualization=, ConditionHost=,
       ConditionKernelCommandLine=, ConditionKernelVersion=, ConditionSecurity=,
       ConditionCapability=, ConditionACPower=, ConditionNeedsUpdate=, ConditionFirstBoot=,
       ConditionPathExists=, ConditionPathExistsGlob=, ConditionPathIsDirectory=,
       ConditionPathIsSymbolicLink=, ConditionPathIsMountPoint=, ConditionPathIsReadWrite=,
       ConditionDirectoryNotEmpty=, ConditionFileNotEmpty=, ConditionFileIsExecutable=,
       ConditionUser=, ConditionGroup=, ConditionControlGroupController=
           Überprüft, dass die festgelegte Bedingung wahr ist, bevor eine Unit gestartet wird.
           Falls sie nicht wahr ist, wird das Starten der Unit (größtenteils stillschweigend)
           übersprungen, allerdings werden alle ihre Ordnungsabhängigkeiten weiterhin
           berücksichtigt. Eine fehlschlagende Bedingung führt nicht dazu, dass die Unit in den
           Zustand »failed« geschoben wird. Die Bedingung wird zu dem Zeitpunkt überprüft, zu dem
           der in der Warteschlange befindliche Auftrag ausgeführt werden soll. Verwenden Sie
           Bedingungsausdrücke, um stillschweigend Units zu überspringen, die in dem lokal
           laufenden System nicht zutreffen, beispielsweise da der Kernel oder die
           Laufzeitumgebung ihre Funktionalität nicht benötigt. Verwenden Sie die verschiedenen
           Optionen AssertArchitecture=, AssertVirtualization=, … für einen ähnlichen
           Mechanismus, die dazu führen, dass ein Auftrag fehlschlägt (statt übersprungen wird)
           und zur Protokollierung über die fehlgeschlagene Überprüfung führt (statt geräuschlos
           verarbeitet zu werden). Für Details über Zusicherungsbedingungen siehe unten.

           ConditionArchitecture= kann zur Prüfung verwandt werden, 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, um gegen eine bestimmte Architektur zu prüfen. 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.

           ConditionArchitecture= kann zur Prüfung verwandt werden, ob das System in einer
           virtualisierten Umgebung ausgeführt wird und optional testen, ob es eine bestimmte
           Implementierung ist. Akzeptiert entweder einen logischen Wert, um zu prüfen, ob es in
           einer virtualisierten Umgebung ausgeführt wird oder entweder vm oder container, um
           gegen eine generische Art von Virtualisierungslösung zu prüfen oder einen aus qemu,
           kvm, zvm, vmware, microsoft, oracle, xen, bochs, uml, bhyve, qnx, openvz, lxc,
           lxc-libvirt, systemd-nspawn, docker, rkt, 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= 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= kann zur Prüfung, ob eine bestimmte
           Kernelbefehlszeilenoption gesetzt ist (oder falls ein Ausrufezeichen vorangestellt
           ist, nicht gesetzt ist) verwandt werden. Das Argument muss entweder ein einzelnes Wort
           oder eine Zuweisung (d.h. zwei Worte, getrennt durch »=«) sein. Im ersten Fall wird
           die Kernelbefehlszeile nach Auftauchen des Wortes wie es ist oder als linke Seite
           einer Zuweisung durchsucht. Im zweitem Fall wird nach der genauen Zuweisung geschaut,
           wobei die rechte und die linke Seite passen müssen.

           ConditionKernelVersion= 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 einzelne Zeichenkette
           sein. Falls die Zeichenkette mit einem aus »<«, »<=«, »=«, »>=«, »>« beginnt, erfolgt
           ein relativer Vergleich, andernfalls wird die festgelegte Zeichenkette mit
           Shell-artigen Globs abgeglichen.

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

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

           ConditionCapability= kann zur Prüfung, 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= kann zur Prüfung, ob das System zum Zeitpunkt der Aktivierung der
           Unit am Netz hängt oder ausschließlich über Akku läuft. Dies akzeptiert ein logisches
           Argument. Falls auf true gesetzt, wird die Bedingung nur gelten, wenn mindestens ein
           Netzstecker an einer Wechselstromquelle hängt oder falls keine Wechselstromstecker
           bekannt sind. Umgekehrt, wenn auf false gesetzt, wird die Bedingung nur gelten, falls
           mindestens ein Wechselstromstecker bekannt ist und alle Wechselstromstecker von einer
           Stromquelle abgetrennt sind.

           ConditionNeedsUpdate= akzeptiert entweder /var oder /etc als Argument, möglicherweise
           mit vorangestelltem »!« (zur Invertierung der Bedingung). Diese Bedingung kann
           eingesetzt werden, um Units davon abhängig zu machen, ob das festgelegte Verzeichnis
           einer Aktualisierung bedarf, da die Änderungszeit von /usr neuer als die Stempeldatei
           .updated in dem festgelegten Verzeichnis ist. Dies ist nützlich, um
           Offline-Aktualisierungen der Betriebssystemressourcen des Lieferanten in /usr zu
           implementieren, die Aktualisierungen von /etc oder /var beim nachfolgenden Systemstart
           benötigen. Units, die von dieser Bedingung Gebrauch machen, sollten sich vor
           systemd-update-done.service(8) einordnen, um sicherzustellen, dass sie ausgeführt
           werden, bevor die Änderungszeit der Stempeldatei zurückgesetzt wird, wodurch eine
           abgeschlossene Aktualisierung angezeigt wird.

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

           Mit ConditionPathExists= wird eine Dateiexistenzbedingung geprüft, bevor eine Unit
           gestartet wird. Falls der festgelegte absolute Pfadname nicht existiert, wird die
           Bedingung fehlschlagen. Falls dem an ConditionPathExists= übergebenen absoluten
           Pfadnamen ein Ausrufezeichen (»!«) vorangestellt wird, wird der Test negiert und die
           Unit nur gestartet, falls der Pfadname nicht existiert.

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

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

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

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

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

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

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

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

           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= ist zu ConditionUser= ähnlich, überprüft aber, ob die reale oder
           effektive Gruppe des Diensteverwalters oder jeder seiner Hilfsgruppen auf die
           festgelegte Gruppe oder GID passt. Diese Einstellung hat keinen besonderen Wert
           »@system«.

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

           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 (|) vorangestellt werden, wodurch die Bedingung eine auslösende
           Bedingung wird. Falls für eine Unit mindestens eine auslösende Bedingung definiert
           ist, dann wird die Unit ausgeführt, falls mindestens eine der auslösenden Bedingungen
           und alle der nicht auslösenden Bedingungen zutreffen. Falls Sie einem Argument das
           Pipe-Symbol und ein Ausrufezeichen voranstellen, muss das Pipe-Symbol zuerst und das
           Ausrufezeichen als zweites übergeben werden. Außer für ConditionPathIsSymbolicLink=
           folgen alle Pfadprüfungen Symlinks. 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.

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

           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.

       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.

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«-EigenschaftWo benutzt               │
       ├───────────────────────┼─────────────────────────┼──────────────────────────┤
       │Before=After=                  │ beides sind              │
       ├───────────────────────┼─────────────────────────┤ Unit-Datei-Optionen      │
       │After=Before=                 │                          │
       ├───────────────────────┼─────────────────────────┼──────────────────────────┤
       │Requires=RequiredBy=             │ eine Unit-Datei-Option,  │
       │                       │                         │ eine Option im Abschnitt │
       │                       │                         │ [Install]                │
       ├───────────────────────┼─────────────────────────┼──────────────────────────┤
       │Wants=WantedBy=               │ eine Unit-Datei-Option,  │
       │                       │                         │ eine Option im Abschnitt │
       │                       │                         │ [Install]                │
       ├───────────────────────┼─────────────────────────┼──────────────────────────┤
       │PartOf=ConsistsOf=             │ eine Unit-Datei-Option,  │
       │                       │                         │ eine automatische        │
       │                       │                         │ Eigenschaft              │
       ├───────────────────────┼─────────────────────────┼──────────────────────────┤
       │BindsTo=BoundBy=                │ eine Unit-Datei-Option,  │
       │                       │                         │ eine automatische        │
       │                       │                         │ Eigenschaft              │
       ├───────────────────────┼─────────────────────────┼──────────────────────────┤
       │Requisite=RequisiteOf=            │ eine Unit-Datei-Option,  │
       │                       │                         │ eine automatische        │
       │                       │                         │ Eigenschaft              │
       ├───────────────────────┼─────────────────────────┼──────────────────────────┤
       │Triggers=TriggeredBy=            │ automatische             │
       │                       │                         │ Eigenschaften, siehe     │
       │                       │                         │ Hinweise unten           │
       ├───────────────────────┼─────────────────────────┼──────────────────────────┤
       │Conflicts=ConflictedBy=           │ eine Unit-Datei-Option,  │
       │                       │                         │ eine automatische        │
       │                       │                         │ Eigenschaft              │
       ├───────────────────────┼─────────────────────────┼──────────────────────────┤
       │PropagatesReloadTo=ReloadPropagatedFrom=   │ beides sind              │
       ├───────────────────────┼─────────────────────────┤ Unit-Datei-Optionen      │
       │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. TriggersBy= wird implizit von
       der ausgelösten Unit erstellt.

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

[INSTALL]-ABSCHNITT-OPTIONEN

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

       Alias=
           Eine Lerraum-getrennte Liste von zusätzlichen Namen, unter der diese Unit installiert
           werden soll. Die hier aufgeführten Namen müssen die gleiche Endung (d.h. Typ) wie der
           Unit-Dateiname haben. Diese Option kann mehr als einmal angegeben werden, dann werden
           alle aufgeführten Namen verwandt. Bei der Installation wird systemctl enable die
           Symlinks von diesen Namen auf den Unit-Dateinamen erstellen. Beachten Sie, dass nicht
           alle Unit-Typen solche Aliase unterstützen und diese Einstellung für sie nicht
           unterstützt wird. Insbesondere unterstützen Einhänge-, Scheiben, Auslagerungs- und
           Automount-Units keinen Alias.

       WantedBy=, RequiredBy=
           Diese Option kann mehr als einmal verwendet werden oder eine durch Leerzeichen
           getrennte Liste von Unit-Namen kann übergeben werden. Im .wants/- oder
           .requires/-Verzeichnis jeder der aufgeführten Units wird bei der Installation mit
           systemctl enable ein symbolischer Link erstellt. Dadurch wird eine Abhängigkeit vom
           Typ Wants= oder Requires= von der aufgeführten Unit zu der aktuellen Unit hinzugefügt.
           Das Hauptergebnis besteht darin, dass die aktuelle Unit gestartet wird, wenn die
           aufgeführte Unit gestartet wird. Siehe die Beschreibung von Wants= und Requires= im
           Abschnitt [Unit] für Details.

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

       Also=
           Zusätzliche Units, die installiert/deinstalliert werden sollen, wenn diese Unit
           installiert/deinstalliert wird. Falls der Benutzer die Installation/Deinstallation
           einer Unit mit dieser konfigurierten Option erbeten hat, wird systemctl enable und
           systemctl disable automatisch auch die in dieser Option aufgeführten Units
           installieren/deinstallieren.

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

       DefaultInstance=
           In Vorlagen-Unit-Dateien kennzeichnet dies, welche Instanz der Unit freigegeben werden
           soll, falls die Vorlage ohne explizit gesetzte Instanz freigegeben wird. Diese Option
           zeigt nur bei Vorlagen-Unit-Dateien Wirkung. Die gekennzeichnete Zeichenkette zur
           Identifizierung einer Instanz geeignet sein.

       Die folgenden Kennzeicher werden in dem Abschnitt Install interpretiert: %n, %N, %p, %i,
       %j, %g, %G, %U, %u, %m, %H, %b, %v. Ihre Bedeutung ist im nächsten Abschnitt beschrieben.

KENNZEICHNER

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

       Tabelle 4. In Unit-Dateien verfügbare Kennzeichner
       ┌─────────────┬────────────────────────────┬──────────────────────────┐
       │KennzeichnerBedeutungDetails                  │
       ├─────────────┼────────────────────────────┼──────────────────────────┤
       │"%b"         │ Boot-Kennung               │ Die Boot-Kennung des     │
       │             │                            │ laufenden Systems,       │
       │             │                            │ formatiert als           │
       │             │                            │ Zeichenkette. Siehe      │
       │             │                            │ random(4) für weitere    │
       │             │                            │ Informationen.           │
       ├─────────────┼────────────────────────────┼──────────────────────────┤
       │"%C"         │ Wurzelverzeichnis des      │ Dies ist entweder        │
       │             │ Zwischenspeichers          │ /var/cache (für den      │
       │             │                            │ Systemverwalter) oder    │
       │             │                            │ worauf der Pfad          │
       │             │                            │ »$XDG_CACHE_HOME« zeigt  │
       │             │                            │ (für Benutzerverwalter). │
       ├─────────────┼────────────────────────────┼──────────────────────────┤
       │"%E"         │ Wurzelverzeichnis der      │ Dies ist entweder /etc   │
       │             │ Konfiguration              │ (für den                 │
       │             │                            │ Systemverwalter) oder    │
       │             │                            │ worauf der Pfad          │
       │             │                            │ »$XDG_CONFIG_HOME« zeigt │
       │             │                            │ (für Benutzerverwalter). │
       ├─────────────┼────────────────────────────┼──────────────────────────┤
       │"%f"         │ Demaskierter Dateiname     │ Dies ist entweder der    │
       │             │                            │ demaskierte              │
       │             │                            │ Instanzenname (falls     │
       │             │                            │ zutreffend), dem /       │
       │             │                            │ vorangestellt wurde      │
       │             │                            │ (falls zutreffend), oder │
       │             │                            │ der desmaskierte         │
       │             │                            │ Präfixname, dem /        │
       │             │                            │ vorangestellt wurde.     │
       │             │                            │ Hiermit wird das         │
       │             │                            │ Demaskieren entsprechend │
       │             │                            │ den oben beschriebenen   │
       │             │                            │ Regeln des Maskierens    │
       │             │                            │ absoluter                │
       │             │                            │ Dateisystempfade         │
       │             │                            │ implementiert.           │
       ├─────────────┼────────────────────────────┼──────────────────────────┤
       │"%h"         │ Benutzer-Home-Verzeichnis. │ Dies ist das             │
       │             │                            │ Home-Verzeichnis des     │
       │             │                            │ Benutzers, der die       │
       │             │                            │ Diensteverwalterinstanz  │
       │             │                            │ ausführt. Im Falle des   │
       │             │                            │ Systemverwalters löst    │
       │             │                            │ sich dies auf »/root«    │
       │             │                            │ auf.                     │
       ├─────────────┼────────────────────────────┼──────────────────────────┤
       │"%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             │
       │             │ des Präfixes               │ Zeichenkette zwischen    │
       │             │                            │ dem letzten »-« und dem  │
       │             │                            │ Ende des Präfixnamens.   │
       │             │                            │ Falls es kein »-« gibt,  │
       │             │                            │ ist dies zu »%p«         │
       │             │                            │ identisch.               │
       ├─────────────┼────────────────────────────┼──────────────────────────┤
       │"%J"         │ Nicht maskierte            │ Identisch zu »%j«, aber  │
       │             │ abschließende Komponente   │ mit zurückgenommener     │
       │             │ des Präfixes               │ Maskierung.              │
       ├─────────────┼────────────────────────────┼──────────────────────────┤
       │"%L"         │ Wurzel des                 │ Dies ist entweder        │
       │             │ Protokollierverzeichnisses │ /var/log (für den        │
       │             │                            │ Systemverwalter) oder    │
       │             │                            │ worauf der Pfad          │
       │             │                            │ »$XDG_CONFIG_HOME«       │
       │             │                            │ zeigt, mit angehängtem   │
       │             │                            │ /log (für                │
       │             │                            │ Benutzerverwalter).      │
       ├─────────────┼────────────────────────────┼──────────────────────────┤
       │"%m"         │ Maschinenkennung           │ Die Maschinenkennung des │
       │             │                            │ laufenden Systems,       │
       │             │                            │ formatiert als           │
       │             │                            │ Zeichenkette. Siehe      │
       │             │                            │ machine-id(5) für        │
       │             │                            │ weitere Informationen.   │
       ├─────────────┼────────────────────────────┼──────────────────────────┤
       │"%n"         │ Vollständiger Unit-Name    │                          │
       ├─────────────┼────────────────────────────┼──────────────────────────┤
       │"%N"         │ Vollständiger Unit-Name    │ Identisch zu »%n«, aber  │
       │             │                            │ mit entfernter           │
       │             │                            │ Typendung.               │
       ├─────────────┼────────────────────────────┼──────────────────────────┤
       │"%p"         │ Präfixname                 │ Für instanziierte Units  │
       │             │                            │ bezieht sich das auf die │
       │             │                            │ Zeichenkette vor dem     │
       │             │                            │ ersten »@«-Zeichen des   │
       │             │                            │ Unit-Namens. Für nicht   │
       │             │                            │ instanziierte Units      │
       │             │                            │ identisch zu »%N«.       │
       ├─────────────┼────────────────────────────┼──────────────────────────┤
       │"%P"         │ Nicht maskierter           │ Identisch zu »%p«, aber  │
       │             │ Präfixname                 │ mit zurückgenommener     │
       │             │                            │ Maskierung.              │
       ├─────────────┼────────────────────────────┼──────────────────────────┤
       │"%s"         │ Benutzer-Shell             │ Dies ist die Shell des   │
       │             │                            │ Benutzers, der die       │
       │             │                            │ Diensteverwalterinstanz  │
       │             │                            │ ausführt. Im Falle des   │
       │             │                            │ Systemverwalters wird    │
       │             │                            │ dies auf »/bin/sh«       │
       │             │                            │ aufgelöst.               │
       ├─────────────┼────────────────────────────┼──────────────────────────┤
       │"%S"         │ Wurzel des                 │ Dies ist entweder        │
       │             │ Zustandsverzeichnisses     │ /var/lib (für den        │
       │             │                            │ Systemverwalter) oder    │
       │             │                            │ worauf der Pfad          │
       │             │                            │ »$XDG_CONFIG_HOME« zeigt │
       │             │                            │ (für Benutzerverwalter). │
       ├─────────────┼────────────────────────────┼──────────────────────────┤
       │"%t"         │ Wurzel des                 │ Dies ist entweder /run   │
       │             │ Laufzeitverzeichnisses     │ (für den                 │
       │             │                            │ Systemverwalter) oder    │
       │             │                            │ worauf der Pfad          │
       │             │                            │ »$XDG_RUNTIME_DIR« zeigt │
       │             │                            │ (für Benutzerverwalter). │
       ├─────────────┼────────────────────────────┼──────────────────────────┤
       │"%T"         │ Verzeichnis für temporäre  │ Dies ist entweder /tmp   │
       │             │ Dateien                    │ oder der Pfad, auf den   │
       │             │                            │ »$TMPDIR«, »$TEMP« oder  │
       │             │                            │ »$TMP« gesetzt ist.      │
       ├─────────────┼────────────────────────────┼──────────────────────────┤
       │"%g"         │ Benutzergruppe             │ Dies ist der Name der    │
       │             │                            │ Gruppe, die die          │
       │             │                            │ Diensteverwalterinstanz  │
       │             │                            │ ausführt. Im Falle des   │
       │             │                            │ Systemverwalters löst    │
       │             │                            │ sich dies auf »root«     │
       │             │                            │ auf.                     │
       ├─────────────┼────────────────────────────┼──────────────────────────┤
       │"%G"         │ Benutzer-GID               │ Dies ist die numerische  │
       │             │                            │ GID des Benutzers, der   │
       │             │                            │ die                      │
       │             │                            │ Diensteverwalterinstanz  │
       │             │                            │ ausführt. Im Falle des   │
       │             │                            │ Systemverwalters löst    │
       │             │                            │ sich dies auf »0« auf.   │
       ├─────────────┼────────────────────────────┼──────────────────────────┤
       │"%u"         │ Benutzername               │ Dies ist der Name des    │
       │             │                            │ Benutzers, der die       │
       │             │                            │ Diensteverwalterinstanz  │
       │             │                            │ ausführt. Im Falle des   │
       │             │                            │ Systemverwalters löst    │
       │             │                            │ sich dies auf »root«     │
       │             │                            │ auf.                     │
       ├─────────────┼────────────────────────────┼──────────────────────────┤
       │"%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.   │
       ├─────────────┼────────────────────────────┼──────────────────────────┤
       │"%v"         │ Kernelveröffentlichung     │ Identisch zur Ausgabe    │
       │             │                            │ von uname -r             │
       ├─────────────┼────────────────────────────┼──────────────────────────┤
       │"%V"         │ Verzeichnis für größere    │ Dies ist entweder        │
       │             │ und dauerhafte temporäre   │ /var/tmp oder der Pfad,  │
       │             │ Dateien                    │ auf den »$TMPDIR«,       │
       │             │                            │ »$TEMP« oder »$TMP«      │
       │             │                            │ gesetzt ist.             │
       ├─────────────┼────────────────────────────┼──────────────────────────┤
       │"%%"         │ Einzelnes Prozentzeichen   │ Verwenden Sie »%%«       │
       │             │                            │ anstelle von »%«, um ein │
       │             │                            │ einzelnes Prozentzeichen │
       │             │                            │ festzulegen.             │
       └─────────────┴────────────────────────────┴──────────────────────────┘

BEISPIELE

       Beispiel 1. Units erlauben, freigegeben zu werden

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

           [Unit]
           Description=Foo

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

           [Install]
           WantedBy=multi-user.target

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

       Beispiel 2. Lieferanteneinstellungen außer Kraft setzen

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

SIEHE AUCH

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

ANMERKUNGEN

        1. Schnittstellenstabilitätszusage
           https://www.freedesktop.org/wiki/Software/systemd/InterfaceStabilityPromise

ÜBERSETZUNG

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

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

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