SYSTEMD.UNIT(5)

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, Timer.timer, Scheibe.slice, Bereich.scope

/etc/systemd/system.control/*
/run/systemd/system.control/*
/run/systemd/transient/*
/run/systemd/generator.early/*
/etc/systemd/system/*
/run/systemd/system/*
/run/systemd/generator/*
…
/lib/systemd/system/*
/run/systemd/generator.late/*

~/.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 Timer, eine Ressourcenverwaltungsscheibe oder eine Gruppe von extern erstellten Prozessenkodiert. 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.

In Unit-Dateien verwandte logische Argumente können in verschiedenen Formaten geschrieben werden. Für positive Einstellungen sind die Zeichenketten 1, yes, true und on äquivalent. Für negative Einstellungen sind die Zeichenketten 0, no, false und off äquivalent.

In Unit-Dateien kodierte Zeitraumwerte können in verschiedenen Formaten geschrieben werden. Eine einzelstehende Zahl legt eine Zeit in Sekunden fest. Falls ihr eine Zeiteinheit angehängt ist, wird diese Einheit respektiert. Eine Aneinanderhängung mehrerer Werte mit Einheiten wird unterstützt; in diesem Fall werden die Werte addiert. Beispiel: »50« bezieht sich auf 50 Sekunden; »2min 200ms« bezieht sich auf 2 Minuten und 200 Millisekunden, d.h. 120200 ms. Die folgenden Zeiteinheiten werden verstanden: »s«, »min«, »h«, »d«, »w«, »ms«, »us«. Für Details siehe systemd.time(7).

Aliase (alternative Namen) können für Units angelegt werden, indem ein Symlink vom neuen Namen auf den alten Namen in einer 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. Zuätzlich können Unit-Dateien Aliase mittels der Direktive 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ängigkeitsdirektiven 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 gesymlinkt 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 »Reinlege«-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. Reinlegedateien 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 Reinlegungen 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 Reinlegedateien 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 Reinlege-».d/«-Verzeichnisse in die Verzeichnisse /lib/systemd/system oder /run/systemd/system abgelegt werden. Reinlege-Dateien in /etc haben Vorrang vor denen in /run, die wiederum Vorrang vor denen in /lib haben. Reinlege-Dateien unter all diesen Verzeichnissen haben Vorrang vor der Haupt-Netdev-Datei, wo auch immer sich diese befindet. Mehrere Reinlege-Dateien 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 eine 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 auf /dev/null gesymlinkt ist, 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 wiederspiegeln. 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ßerhalb der ASCII alphanumerischen 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).
Pfad | Beschreibung
/etc/systemd/system.control | Mittels Dbus-API erstellte dauerhafte und flüchtige Konfiguration
/run/systemd/system.control |
/run/systemd/transient | Dynamische Konfiguration für flüchtige Units
/run/systemd/generator.early | Erstellte Units mit hoher Priorität (siehe early-dir in system.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 system.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 system.generator(7))

Tabelle 2. Ladepfad bei der Ausführung im Benutzermodus (--user).
Pfad | Beschreibung
$XDG_CONFIG_HOME/systemd/user.control oder ~/.config/systemd/user.control | Dauerhafte und flüchtige Konfiguration, die mittels des DBus-APIs erstellt wird (($XDG_CONFIG_HOME wird verwandt, falls gesetzt, andernfalls ~/.config)
$XDG_RUNTIME_DIR/systemd/user.control |
/run/systemd/transient | Dynamische Konfiguration für flüchtige Units
/run/systemd/generator.early | Erstellte Units mit hoher Priorität (siehe early-dir in system.generator(7))
$XDG_CONFIG_HOME/systemd/user oder $HOME/.config/systemd/user | Benutzerkonfiguration ($XDG_CONFIG_HOME wird verwandt, falls gesetzt, andernfalls ~/.config)
/etc/systemd/user | Lokale Konfiguration
$XDG_RUNTIME_DIR/systemd/user | Laufzeit-Units (nur verwandt, falls $XDG_RUNTIME_DIR gesetzt ist)
/run/systemd/user | Laufzeit Units
$XDG_RUNTIME_DIR/systemd/generator | Erstellte Units mit mittlerer Priorität (siehe normal-dir in system.generator(7))
$XDG_DATA_HOME/systemd/user oder $HOME/.local/share/systemd/user | Units von Paketen, die im Home-Verzeichnis installiert wurden ($XDG_DATA_HOME wird verwandt, falls gesetzt, andernfalls ~/.local/share)
$dir/systemd/user für jedes $dir in $XDG_DATA_DIRS | Zusätzliche Orte für installierte Benutzer-Units, einen für jeden Eintrag in $XDG_DATA_DIRS
/usr/local/lib/systemd/user | Units für Pakete, die systemweit installiert wurden
/usr/lib/systemd/user |
$XDG_RUNTIME_DIR/systemd/generator.late | Erstellte Units mit niedriger Priorität (siehe late-dir in system.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=
    Eine formatfreie Zeichenkette, die die Unit beschreibt. Dies ist für den Einsatz in UIs gedacht, um beschreibende Informationen zusammen mit dem Unit-Namen anzuzeigen. Die Beschreibung sollte einen Namen enthalten, der dem Endbenutzer etwas sagt. Ein gutes Beispiel ist »Apache2 Web Server«. Schlechte Beispiele sind »leichtgewichtiger Hochleistungs-HTTP-Server« (zu generisch) oder »Apache2« (zu speziell und bedeutungslos für Personen, die Apache nicht kennen).

Documentation=
    Eine Leeraum-getrennte Liste von URIs, die Dokumentation für diese Unit oder seine 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, Leerraum-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önnten 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 beim Starten 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, gestopppt 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 Leeraum-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, gleichzeitig zum Starten wie 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 Leeraum-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 foo.service mit dem Starten abgeschlossen hat. 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 die aufgeführte Unit das Starten abgeschlossen hat, 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 geordnet. 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 eine Unit das Starten abgeschlossen hat. 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 berichteten.

OnFailure=
    Eine Leeraum-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 Leeraum-getrennte Liste einer oder mehrerer Units, bei denen Neuladeanforderungen an diese anderen Units fortgepflanzt werden bzw. Neuladeanforderungen von anderen Units an diese Unit fortgepflanzt werden. Erteilen einer Neuladeanforderunge an eine Unit, wird auch eine Neuladeanforderung an alle Units, an die die Neuladeanforderung mittles dieser zwei Einstellungen fortgepflanzt 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ärer Namensraum beigetreten werden soll. Dies gilt nur für Unit-Typen, die die Direktiven 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, wessen 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 Leeraum-getrennte Liste absoluter Pfade. Führt 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-, Timer- und Pfad-Units und true für Scheiben-, Bereichs-, Geräte-, Swap-, Einhänge- und Automount-Units.

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

RefuseManualStart=, RefuseManualStop=
    Akzeptiert ein logisches Argument. Falls true kann diese Unit nur indirekt aktiviert oder deaktiviert werden. In diesem Fall werden direkte Start- oder Beendigungs-Anfragen des Benutzers zurückgewiesen, erfolgt das Starten oder Beenden allerdings als Abhängigkeit von einer anderen Unit, dann wird das Starten oder Beenden erfolgreich sein. Dies ist primär eine Sicherheitsfunktionalität, um sicherzustellen, dass der Benutzer nicht versehentlich Units aktiviert, die nicht für direkte Aktivierung gedacht sind und nicht versehentlich Units deaktiviert, die nicht zur Beendigung gedacht sind. Diese Option ist standardmäßig false.

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

DefaultDependencies=
    Akzeptiert ein logisches Argument. Falls true (die Vorgabe) werden ein paar 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.

JobTimeoutSec=, JobRunningTimeoutSec=, JobTimeoutAction=, JobTimeoutRebootArgument=
    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= konfiguriert optional eine zusätzliche Aktion, die beim Erreichen der Zeitüberschreitung unternommen werden soll. Es akzeptiert die gleichen Werte wie StartLimitAction=. Standardmäßig none. JobTimeoutRebootArgument= konfiguriert eine optionale Neustartzeichenkette, die an den Systemaufruf reboot(2) übergeben wird.

StartLimitIntervalSec=Interval, StartLimitBurst=Häufung
    Konfiguriert die Unit-Startratenbegrenzung. Units, die mehr als Häufung mal innerhalb des Zeitintervals Interval gestartet werden, wird kein weiterer Start erlaubt. Verwenden Sie StartLimitIntervalSec=, um das Überprüfungsinterval (standardmäßig DefaultStartLimitIntervalSec= in Verwalterkonfigurationsdatei, setzten Sie es auf 0, um jede Art von Ratenbegrenzung zu deaktivieren) zu konfigurieren. Verwenden Sie StartLimitBurst=, um zu konfigurieren, wie viele Starts pro Interval 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 Interval 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 die durchzuführende Aktion, falls die mit StartLimitIntervalSec= und StartLimitBurst= konfigurierte Ratenbegrenzung erreicht wird. Akzeptiert entweder none, reboot, reboot-force, reboot-immediate, poweroff, poweroff-force oder poweroff-immediate. Falls none gesetzt ist, wird das Erreichen der Ratenbegrenzung keine Aktion auslösen, außer dass der Start nicht erlaubt wird. 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. Ähnlich haben poweroff, poweroff-force, poweroff-immediate die Wirkung des Herunterfahrens des Systems mit ähnlichen Semantiken. Standardmäßig none.

FailureAction=, SuccessAction=
    Konfiguriert die Aktion, die ergriffen werden soll, wenn eine Unit stoppt und in einen Fehler- oder inaktiven Zustand eintritt. Akzeptiert die gleichen Werte wie die Einstellung StartLimitAction= und führt die gleichen Aktionen aus. Beide Optionen sind 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 leise) übersprungen, allerdings werden alle ihre Ordnungsabhängigkeiten weiterhin berücksichtigt. Eine fehlschlagende Bedingung führt nicht dazu, dass die Unit in den Fehlerzustand 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 geräuschlos 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 die Unit in eine Fehlerzustand legt und über die fehlgeschlagene Prüfung protokolliert (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 Sytem 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 berichtet 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 bereitgetellte 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 Stromstecker 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= übergebene 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= is similar to ConditionPathExists= but verifies whether a certain path exists and is a mount point.

    ConditionPathIsReadWrite= is similar to ConditionPathExists= but verifies whether the underlying file system is readable and writable (i.e. not mounted read-only).

    ConditionDirectoryNotEmpty= is similar to ConditionPathExists= but verifies whether a certain path exists and is a non-empty directory.

    ConditionFileNotEmpty= is similar to ConditionPathExists= but verifies whether a certain path exists and refers to a regular file with a non-zero size.

    ConditionFileIsExecutable= is similar to ConditionPathExists= but verifies whether a certain path exists, is a regular file and marked executable.

    ConditionUser= takes a numeric "UID", a UNIX user name, or the special value "@system". This condition may be used to check whether the service manager is running as the given user. The special value "@system" can be used to check if the user id is within the system user range. This option is not useful for system services, as the system manager exclusively runs as the root user, and thus the test result is constant.

    ConditionGroup= is similar to ConditionUser= but verifies that the service manager's real or effective group, or any of its auxiliary groups match the specified group or GID. This setting does not have a special value "@system".

    ConditionControlGroupController= takes a cgroup controller name (eg. cpu), verifying that it is available for use on the system. For example, a particular controller may not be available if it was disabled on the kernel command line with "cgroup_disable="controller. Multiple controllers may be passed with a space separating them; in this case the condition will only pass if all listed controllers are available for use. Controllers unknown to systemd are ignored. Valid controllers are cpu, cpuacct, io, blkio, memory, devices, and pids.

    If multiple conditions are specified, the unit will be executed if all of them apply (i.e. a logical AND is applied). Condition checks can be prefixed with a pipe symbol (|) in which case a condition becomes a triggering condition. If at least one triggering condition is defined for a unit, then the unit will be executed if at least one of the triggering conditions apply and all of the non-triggering conditions. If you prefix an argument with the pipe symbol and an exclamation mark, the pipe symbol must be passed first, the exclamation second. Except for ConditionPathIsSymbolicLink=, all path checks follow symlinks. If any of these options is assigned the empty string, the list of conditions is reset completely, all previous condition settings (of any kind) will have no effect.

AssertArchitecture=, AssertVirtualization=, AssertHost=, AssertKernelCommandLine=, AssertKernelVersion=, AssertSecurity=, AssertCapability=, AssertACPower=, AssertNeedsUpdate=, AssertFirstBoot=, AssertPathExists=, AssertPathExistsGlob=, AssertPathIsDirectory=, AssertPathIsSymbolicLink=, AssertPathIsMountPoint=, AssertPathIsReadWrite=, AssertDirectoryNotEmpty=, AssertFileNotEmpty=, AssertFileIsExecutable=, AssertUser=, AssertGroup=, AssertControlGroupController=
    Similar to the ConditionArchitecture=, ConditionVirtualization=, ..., condition settings described above, these settings add assertion checks to the start-up of the unit. However, unlike the conditions settings, any assertion setting that is not met results in failure of the start job (which means this is logged loudly). Use assertion expressions for units that cannot operate when specific requirements are not met, and when this is something the administrator or user should look into.

SourcePath=
    A path to a configuration file this unit has been generated from. This is primarily useful for implementation of generator tools that convert configuration from an external configuration file format into native unit files. This functionality should not be used in normal units.

ABBILDUNG VON UNIT-EIGENSCHAFTEN AUF IHR INVERSES

Unit settings that create a relationship with a second unit usually show up in properties of both units, for example in systemctl show output. In some cases the name of the property is the same as the name of the configuration setting, but not always. This table lists the properties that are shown on two units which are connected through some dependency, and shows which property on "source" unit corresponds to which property on the "target" unit.

Table 3. Forward and reverse unit properties
»Forward«-Eigenschaft | »Reverse«-Eigenschaft | Wo benutzt
Before= | After= | Beides sind Unit-Datei-Optionen
After= | Before= |
Requires= | RequiredBy= | A unit file option; an option in the [Install] section
Wants= | WantedBy= | A unit file option; an option in the [Install] section
PartOf= | ConsistsOf= | A unit file option; an automatic property
BindsTo= | BoundBy= | A unit file option; an automatic property
Requisite= | RequisiteOf= | A unit file option; an automatic property
Triggers= | TriggeredBy= | automatische Eigenschaften, siehe Hinweise unten
Conflicts= | ConflictedBy= | A unit file option; an automatic property
PropagatesReloadTo= | ReloadPropagatedFrom= | Beides sind Unit-Datei-Optionen
ReloadPropagatedFrom= | PropagatesReloadTo= |
Following= | n.Z. | eine automatische Eigenschaft

Note: WantedBy= and RequiredBy= are used in the [Install] section to create symlinks in .wants/ and .requires/ directories. They cannot be used directly as a unit configuration setting.

Note: ConsistsOf=, BoundBy=, RequisiteOf=, ConflictedBy= are created implicitly along with their reverse and cannot be specified directly.

Note: Triggers= is created implicitly between a socket, path unit, or an automount unit, and the unit they activate. By default a unit with the same name is triggered, but this can be overridden using Sockets=, Service=, and Unit= settings. See systemd.service(5), systemd.socket(5), systemd.path(5), and systemd.automount(5) for details. TriggersBy= is created implicitly on the triggered unit.

Note: Following= is used to group device aliases and points to the "primary" device unit that systemd is using to track device state, usually corresponding to a sysfs path. It does not show up in the "target" unit.

[INSTALL]-ABSCHNITT-OPTIONEN

Unit files may include an "[Install]" section, which carries installation information for the unit. This section is not interpreted by systemd(1) during runtime; it is used by the enable and disable commands of the systemctl(1) tool during installation of a unit.

Alias=
    A space-separated list of additional names this unit shall be installed under. The names listed here must have the same suffix (i.e. type) as the unit filename. This option may be specified more than once, in which case all listed names are used. At installation time, systemctl enable will create symlinks from these names to the unit filename. Note that not all unit types support such alias names, and this setting is not supported for them. Specifically, mount, slice, swap, and automount units do not support aliasing.

WantedBy=, RequiredBy=
    This option may be used more than once, or a space-separated list of unit names may be given. A symbolic link is created in the .wants/ or .requires/ directory of each of the listed units when this unit is installed by systemctl enable. This has the effect that a dependency of type Wants= or Requires= is added from the listed unit to the current unit. The primary result is that the current unit will be started when the listed unit is started. See the description of Wants= and Requires= in the [Unit] section for details.

    WantedBy=foo.service in a service bar.service is mostly equivalent to Alias=foo.service.wants/bar.service in the same file. In case of template units, systemctl enable must be called with an instance name, and this instance will be added to the .wants/ or .requires/ list of the listed unit. E.g. WantedBy=getty.target in a service getty@.service will result in systemctl enable getty@tty2.service creating a getty.target.wants/getty@tty2.service link to getty@.service.

Also=
    Additional units to install/deinstall when this unit is installed/deinstalled. If the user requests installation/deinstallation of a unit with this option configured, systemctl enable and systemctl disable will automatically install/uninstall units listed in this option as well.

    This option may be used more than once, or a space-separated list of unit names may be given.

DefaultInstance=
    In template unit files, this specifies for which instance the unit shall be enabled if the template is enabled without any explicitly set instance. This option has no effect in non-template unit files. The specified string must be usable as instance identifier.

The following specifiers are interpreted in the Install section: %n, %N, %p, %i, %j, %U, %u, %m, %H, %b, %v. For their meaning see the next section.

KENNZEICHNER

Many settings resolve specifiers which may be used to write generic unit files referring to runtime or unit parameters that are replaced when the unit files are loaded. Specifiers must be known and resolvable for the setting to be valid. The following specifiers are understood:

Table 4. Specifiers available in unit files
Kenzeichner | Bedeutung | Details
"%b" | Boot-Kennung | Die Boot-Kennung des laufenden Systems, formatiert als Zeichenkette. Siehe random(4) für weitere Informationen.
"%C" | Cache directory root | This is either /var/cache (for the system manager) or the path "$XDG_CACHE_HOME" resolves to (for user managers).
"%E" | Configuration directory root | This is either /etc (for the system manager) or the path "$XDG_CONFIG_HOME" resolves to (for user managers).
"%f" | Unescaped filename | This is either the unescaped instance name (if applicable) with / prepended (if applicable), or the unescaped prefix name prepended with /. This implements unescaping according to the rules for escaping absolute file system paths discussed above.
"%h" | Benutzer-Home-Verzeichnis. | Dies ist das Home-Verzeichnis des Benutzers, der die Dienste-Manager-Instanz ausführt. Im Falle des Systemmanagers löst sich dies auf »/root« auf.
"%H" | Rechnername | The hostname of the running system at the point in time the unit configuration is loaded.
"%i" | Instanzenname | For instantiated units this is the string between the first "@" character and the type suffix. Empty for non-instantiated units.
"%I" | Unescaped instance name | Same as "%i", but with escaping undone.
"%j" | Abschließende Komponente des Präfixes | This is the string between the last "-" and the end of the prefix name. If there is no "-", this is the same as "%p".
"%J" | Unescaped final component of the prefix | Same as "%j", but with escaping undone.
"%L" | Log directory root | This is either /var/log (for the system manager) or the path "$XDG_CONFIG_HOME" resolves to with /log appended (for user managers).
"%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 | Same as "%n", but with the type suffix removed.
"%p" | Präfixname | For instantiated units, this refers to the string before the first "@" character of the unit name. For non-instantiated units, same as "%N".
"%P" | Unescaped prefix name | Same as "%p", but with escaping undone.
"%s" | Benutzer-Shell | This is the shell of the user running the service manager instance. In case of the system manager this resolves to "/bin/sh".
"%S" | State directory root | This is either /var/lib (for the system manager) or the path "$XDG_CONFIG_HOME" resolves to (for user managers).
"%t" | Runtime directory root | This is either /run (for the system manager) or the path "$XDG_RUNTIME_DIR" resolves to (for user managers).
"%T" | Verzeichnis für temporäre Dateien | Dies ist entweder /tmp, oder der Pfad, auf den »$TMPDIR«, »$TEMP« oder »$TMP« gesetzt ist.
"%u" | Benutzername | Dies ist der Name des Benutzers, der die Dienste-Manager-Instanz ausführt. Im Falle des Systemmanagers löst sich dies auf »root« auf.
"%U" | Benutzer-UID | This is the numeric UID of the user running the service manager instance. In case of the system manager this resolves to "0".
"%v" | Kernelveröffentlichung | Identisch zur Ausgabe von uname -r
"%V" | Verzeichnis für größere und dauerhafte temporäre Dateien | Dies ist entweder /var/tmp, oder der Pfad, auf den »$TMPDIR«, »$TEMP« oder »$TMP« gesetzt ist.
"%%" | Einzelnes Prozentzeichen | Use "%%" in place of "%" to specify a single percent sign.

BEISPIELE

Example 1. Allowing units to be enabled

The following snippet (highlighted) allows a unit (e.g. foo.service) to be enabled via systemctl enable:

    [Unit]
    Description=Foo
    [Service]
    ExecStart=/usr/sbin/foo-daemon
    [Install]
    WantedBy=multi-user.target

After running systemctl enable, a symlink /etc/systemd/system/multi-user.target.wants/foo.service linking to the actual unit will be created. It tells systemd to pull in the unit when starting multi-user.target. The inverse systemctl disable will remove that symlink again.

Example 2. Overriding vendor settings

There are two methods of overriding vendor settings in unit files: copying the unit file from /lib/systemd/system to /etc/systemd/system and modifying the chosen settings. Alternatively, one can create a directory named unit.d/ within /etc/systemd/system and place a drop-in file name.conf there that only changes the specific settings one is interested in. Note that multiple such drop-in files are read if present, processed in lexicographic order of their filename.

The advantage of the first method is that one easily overrides the complete unit, the vendor unit is not parsed at all anymore. It has the disadvantage that improvements to the unit file by the vendor are not automatically incorporated on updates.

The advantage of the second method is that one only overrides the settings one specifically wants, where updates to the unit by the vendor automatically apply. This has the disadvantage that some future updates by the vendor might be incompatible with the local changes.

This also applies for user instances of systemd, but with different locations for the unit files. See the section on unit load paths for further details.

Suppose there is a vendor-supplied unit /lib/systemd/system/httpd.service with the following contents:

    [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

Now one wants to change some settings as an administrator: firstly, in the local setup, /srv/webserver might not exist, because the HTTP server is configured to use /srv/www instead. Secondly, the local configuration makes the HTTP server also depend on a memory cache service, memcached.service, that should be pulled in (Requires=) and also be ordered appropriately (After=). Thirdly, in order to harden the service a bit more, the administrator would like to set the PrivateTmp= setting (see systemd.exec(5) for details). And lastly, the administrator would like to reset the niceness of the service to its default value of 0.

The first possibility is to copy the unit file to /etc/systemd/system/httpd.service and change the chosen settings:

    [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

Alternatively, the administrator could create a drop-in file /etc/systemd/system/httpd.service.d/local.conf with the following contents:

    [Unit]
    After=memcached.service
    Requires=memcached.service
    # Reset all assertions and then re-add the condition we want
    AssertPathExists=
    AssertPathExists=/srv/www
    [Service]
    Nice=0
    PrivateTmp=yes

Note that for drop-in files, if one wants to remove entries from a setting that is parsed as a list (and is not a dependency), such as AssertPathExists= (or e.g. ExecStart= in service units), one needs to first clear the list before re-adding all entries except the one that is to be removed. Dependencies (After=, etc.) cannot be reset to an empty list, so dependencies can only be added in drop-ins. If you want to remove dependencies, you have to override the entire unit.

SIEHE AUCH

systemd(1), systemctl(1), 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>.