Provided by: manpages-de_2.16-1_all 
BEZEICHNUNG
systemd.unit - Unit-Konfiguration
ÜBERSICHT
Dienst.service, Socket.socket, Gerät.device, Einhängung.mount, Selbsteinhängung.automount,
Auslagerung.swap, Ziel.target, Pfad.path, 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 Selbsteinhä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.
Gültige Unit-Namen bestehen aus einen »Namensvorsatz« und einem Punkt und einer Endung, die den Unit-Typ
festlegt. Der »Unit-Vorsatz« muss aus einem oder mehreren gültigen Zeichen (ASCII-Buchstaben, Ziffern,
»:«, »-«, »_«, ».« und »\« bestehen). Die Gesamtlänge des Unit-Names einschließlich der Endung darf 256
Zeichen nicht überschreiten. Die Typ-Endung muss entweder ».service«, ».socket«, ».device«, ».mount«,
».automount«, ».swap«, ».target«, ».path«, ».timer«, ».slice« oder ».scope« sein.
Unit-Namen können durch einen einzelnen Parameter, genannt »Instanzenname«, parametrisiert werden. Die
Unit wird dann, basierend auf einer »Vorlagendatei«, die als Definition mehrerer Dienste oder anderer
Units dient, konstruiert. Eine Vorlagendatei muss ein einzelnes »@« am Ende des Namens haben (direkt vor
der Typendung). Der Name der kompletten Unit wird durch Einfügung des Instanzennamens zwischen dem @ und
der Unit-Typendung gebildet. In der Unit-Datei selbst kann auf den Instanzenparameter mittels »%i« und
anderen Kennzeichnern Bezug genommen werden, siehe unten.
Unit-Dateien dürfen zusätzliche zu den hier aufgeführten Optionen enthalten. Falls Systemd auf eine
unbekannte Option stößt, wird es eine Warnprotokollnachricht schreiben, aber mit dem Laden der Unit
fortfahren. Falls vor einer Option oder einem Abschnittnamen ein X- steht, wird diese(r) von Systemd
komplett ignoriert. Optionen innerhalb eines ignorierten Abschnittes benötigen die vorangestellte Kennung
nicht. Anwendungen können dies dazu verwenden, zusätzliche Informationen in den Unit-Dateien aufzunehmen.
Aliase (alternative Namen) können für Units angelegt werden, indem ein Symlink vom neuen Namen auf den
alten Namen in einem der Unit-Suchpfade angelegt wird Beispielsweise hat systemd-networkd.service den
Alias dbus-org.freedesktop.network1.service, der während der Installation als ein Symlink erstellt wird,
so dass systemd auf die Anfrage über D-Bus, dbus-org.freedesktop.network1.service zu laden,
systemd-networkd.service laden wird. Aliasnamen können in Befehlen wie enable, disable, start, stop,
status und ähnlichen und in allen Unit-Abhängigkeitsanweisungen einschließlich Wants=, Requires=,
Before=, After= verwandt werden. Aliase können nicht mit dem Befehl preset verwandt werden.
Zusätzlich können Unit-Dateien Aliase mittels der Anweisung Alias= im Abschnitt [Install] festlegen. Wenn
die Unit aktiviert ist, werden Symlinks für diese Namen erstellt und wieder entfernt, wenn die Unit
deaktiviert wird. Beispielsweise legt reboot.target Alias=ctrl-alt-del.target so fest, dass der Symlink
/etc/systemd/systemd/ctrl-alt-del.service auf die Datei reboot.target bei der Aktivierung erstellt wird
und wenn Strg-Alt-Entf gedrückt wird, systemd nach ctrl-alt-del.service suchen und reboot.service
ausführen wird. systemd schaut während des normalen Betriebs überhaupt nicht in den Abschnitt [Install],
daher haben sämtliche Direktiven in diesem Abschnitt nur durch während der Aktivierung erstellte Symlinks
eine Wirkung.
Das Verzeichnis foo.service.wants/ kann zusammen mit der Unit-Datei foo.service existieren. Alle
Unit-Dateien, die von so einem Verzeichnis mittels Symlink verknüpft sind, werden implizit als
Abhängigkeiten vom Typ Wants= für die Unit hinzugefügt. Eine ähnliche Funktionalität existiert auch für
Abhängigkeiten vom Typ Requires=, die Verzeichnisendung ist in diesem Fall .requires/. Diese
Funktionalität ist nützlich, um Units in den Start von anderen Units einzuhängen, ohne ihre Unit-Dateien
zu verändern. Für Details über die Semantik von Wants= siehe unten. Die bevorzugte Art, Symlinks in den
Verzeichnissen .wants/ oder .requires/ einer Unit-Datei zu erstellen, ist über Einbettung der
Abhängigkeit in den Abschnitt [Install] der Ziel-Unit und Erstellung des Symlinks im Dateisystem mittel
des Befehls enable oder preset von systemctl(1).
Zusammen mit einer Unit-Datei foo.service kann ein »Ergänzungs«-Verzeichnis foo.service.d/ existieren.
Alle Dateien mit der Endung ».conf« aus diesem Verzeichnis werden, nachdem die Unit-Datei selbst
ausgewertet wurde, ausgewertet. Dies ist nützlich, um die Konfigurationseinstellungen für eine Unit zu
verändern oder zu ergänzen, ohne die Unit-Dateien selbst verändern zu müssen. Ergänzungsdateien müssen
geeignete Abschnittskopfzeilen enthalten. Für instanziierte Units wird diese Logik zuerst nach dem
Instanzen-Unterverzeichnis ».d/« (z.B. »foo@bar.service.d/«) schauen und dessen ».conf«-Dateien lesen,
gefolgt von dem Vorlagenunterverzeichnis ».d/« (z.B. »foo@.service.d/«) und den ».conf«-Dateien dort. Für
Unit-Namen, die desweiteren 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).
┌───────────────────────────────┬───────────────────────────────────────┐
│ 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 │
│ │ systemd.generator(7)) │
├───────────────────────────────┼───────────────────────────────────────┤
│ /etc/systemd/system │ System-Units, die vom Administrator │
│ │ erstellt wurden │
├───────────────────────────────┼───────────────────────────────────────┤
│ /run/systemd/system │ Laufzeit-Units │
├───────────────────────────────┼───────────────────────────────────────┤
│ /run/systemd/generator │ Erstellte Units mit mittlerer │
│ │ Priorität (siehe normal-dir in │
│ │ systemd.generator(7)) │
├───────────────────────────────┼───────────────────────────────────────┤
│ /usr/local/lib/systemd/system │ System-Units, die vom Administrator │
│ │ installiert wurden │
├───────────────────────────────┼───────────────────────────────────────┤
│ /lib/systemd/system │ System-Units, die durch den │
│ │ Paketverwalter der Distribution │
│ │ installiert wurden │
├───────────────────────────────┼───────────────────────────────────────┤
│ /run/systemd/generator.late │ Erstellte Units mit niedriger │
│ │ Priorität (siehe late-dir in │
│ │ systemd.generator(7)) │
└───────────────────────────────┴───────────────────────────────────────┘
Tabelle 2. Ladepfad bei der Ausführung im Benutzermodus (--user).
┌─────────────────────────────────────────┬───────────────────────────────────────┐
│ Pfad │ Beschreibung │
├─────────────────────────────────────────┼───────────────────────────────────────┤
│ $XDG_CONFIG_HOME/systemd/user.control │ Dauerhafte und flüchtige │
│ oder ~/.config/systemd/user.control │ Konfiguration, die mittels des │
├─────────────────────────────────────────┤ DBus-APIs erstellt wird │
│ $XDG_RUNTIME_DIR/systemd/user.control │ (($XDG_CONFIG_HOME wird verwandt, │
│ │ falls gesetzt, andernfalls ~/.config) │
├─────────────────────────────────────────┼───────────────────────────────────────┤
│ /run/systemd/transient │ Dynamische Konfiguration für │
│ │ flüchtige Units │
├─────────────────────────────────────────┼───────────────────────────────────────┤
│ /run/systemd/generator.early │ Erstellte Units mit hoher Priorität │
│ │ (siehe early-dir in │
│ │ systemd.generator(7)) │
├─────────────────────────────────────────┼───────────────────────────────────────┤
│ $XDG_CONFIG_HOME/systemd/user oder │ Benutzerkonfiguration │
│ $HOME/.config/systemd/user │ ($XDG_CONFIG_HOME wird verwandt, │
│ │ falls gesetzt, andernfalls ~/.config) │
├─────────────────────────────────────────┼───────────────────────────────────────┤
│ /etc/systemd/user │ Benutzer-Units, die vom Administrator │
│ │ erstellt wurden │
├─────────────────────────────────────────┼───────────────────────────────────────┤
│ $XDG_RUNTIME_DIR/systemd/user │ Laufzeit-Units (nur verwandt, falls │
│ │ $XDG_RUNTIME_DIR gesetzt ist) │
├─────────────────────────────────────────┼───────────────────────────────────────┤
│ /run/systemd/user │ Laufzeit-Units │
├─────────────────────────────────────────┼───────────────────────────────────────┤
│ $XDG_RUNTIME_DIR/systemd/generator │ Erstellte Units mit mittlerer │
│ │ Priorität (siehe normal-dir in │
│ │ systemd.generator(7)) │
├─────────────────────────────────────────┼───────────────────────────────────────┤
│ $XDG_DATA_HOME/systemd/user oder │ Units von Paketen, die im │
│ $HOME/.local/share/systemd/user │ Home-Verzeichnis installiert wurden │
│ │ ($XDG_DATA_HOME wird verwandt, falls │
│ │ gesetzt, andernfalls ~/.local/share) │
├─────────────────────────────────────────┼───────────────────────────────────────┤
│ $dir/systemd/user für jedes $dir in │ Zusätzliche Orte für installierte │
│ $XDG_DATA_DIRS │ Benutzer-Units, einen für jeden │
│ │ Eintrag in $XDG_DATA_DIRS │
├─────────────────────────────────────────┼───────────────────────────────────────┤
│ /usr/local/lib/systemd/user │ Benutzer-Units, die durch den │
│ │ Administrator installiert wurden │
├─────────────────────────────────────────┼───────────────────────────────────────┤
│ /usr/lib/systemd/user │ Benutzer-Units, die durch den │
│ │ Paketverwalter der Distribution │
│ │ installiert wurden │
├─────────────────────────────────────────┼───────────────────────────────────────┤
│ $XDG_RUNTIME_DIR/systemd/generator.late │ Erstellte Units mit niedriger │
│ │ Priorität (siehe late-dir in │
│ │ systemd.generator(7)) │
└─────────────────────────────────────────┴───────────────────────────────────────┘
Die Gruppe der Ladepfade für die Benutzerverwalterinstanzen kann mittels verschiedener Umgebungsvariablen
ergänzt oder geändert werden. Und Umgebungsvariablen können wiederum mittels Umgebungsgeneratoren gesetzt
werden, siehe systemd.environment-generator(7). Insbesondere $XDG_DATA_HOME und $XDG_DATA_DIRS können
leicht mittels systemd-environment-d-generator(8) gesetzt werden. Daher sind die hier aufgeführten
Verzeichnisse nur die Vorgaben. Um die tatsächlich verwandte Liste, basierend auf den Compiler-Optionen
und der aktuellen Umgebung, zu sehen, verwenden Sie
systemd-analyze --user unit-paths
Desweiteren können zusätzliche Units aus Verzeichnissen, die nicht im Unit-Ladepfad sind, in Systemd
hereingeladen (»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=, NetworkNamespacePath= und PrivateTmp= unterstützen
(siehe systemd.exec(5) für Details). Falls eine Unit, die diese Einstellung hat, gestartet wird,
werden deren Prozesse die gleichen /tmp-, /var/tmp- und Netzwerk-Namensräume wie die aufgeführte
gestartete Unit haben. Falls mehrere aufgeführte Units bereits gestartet sind, ist nicht definiert,
welchem Namensraum beigetreten wird. Beachten Sie, dass diese Einstellung nur Wirkung zeigt, falls
PrivateNetwork=/NetworkNamespacePath= und/oder PrivateTmp= für sowohl die Unit, die dem Namensraum
beitritt, als auch die Unit, deren Namensraum beigetreten wird, aktiviert ist.
RequiresMountsFor=
Akzeptiert eine Leerraum-getrennte Liste absoluter Pfade. Fügt automatisch Abhängigkeiten vom Typ
Requires= und After= für alle für den Zugriff auf den festgelegten Pfad benötigten Einhänge-Units
hinzu.
Mit noauto markierte Einhängepunkte werden nicht durch local-fs.target automatisch eingehängt, werden
für den Zweck dieser Option aber weiterhin berücksichtigt, d.h. sie werden von dieser Unit
hereingezogen.
OnFailureJobMode=
Akzeptiert einen Wert aus »fail«, »replace«, »replace-irreversibly«, »isolate«, »flush«,
»ignore-dependencies«, »ignore-requirements«. Standardmäßig »replace«. Legt fest, wie die in
OnFailure= aufgeführten Units in die Warteschlange eingestellt werden. Siehe die Option --job-mode=
von systemctl(1) für Details über die möglichen Werte. Falls dies auf »isolate« gesetzt ist, darf in
OnFailure= nur eine einzelne Unit aufgeführt werden.
IgnoreOnIsolate=
Akzeptiert ein logisches Argument. Falls true, wird die Unit nicht gestoppt, wenn eine andere Unit
isoliert wird. Standardmäßig false für Dienste-, Ziel-, Socket-, 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 yes (die Vorgabe), werden einige Standard-Abhängigkeiten
implizit für die Unit erstellt. Die tatsächlich erstellten Abhängigkeiten hängen vom Unit-Typ ab. Für
Dienste-Units stellen diese Abhängigkeiten beispielsweise sicher, dass der Dienst erst gestartet
wird, nachdem die grundlegende System-Initialisierung abgeschlossen ist und dass er korrekt beim
System-Herunterfahren beendet wird. Siehe die jeweilige Handbuchseite für Details. Im Allgemeinen
sollten nur Dienste, die im frühen Systemstart oder beim späten Herunterfahren beteiligt sind, diese
Option auf no setzen. Es wird nachdrücklich empfohlen, diese Option für den Großteil der häufigen
Units aktiviert zu lassen. Falls auf no gesetzt, deaktiviert diese Option nicht alle impliziten
Abhängigkeiten, sondern nur nicht essenzielle.
CollectMode=
Optimiert den Algorithmus der »Müllabfuhr« für diese Unit. Akzeptiert entweder inactive oder
inactive-or-failed. Falls auf inactive gesetzt, wird die Unit entladen, falls sie im Zustand inactive
ist und von keinen Clients, Aufträgen oder anderen Units referenziert wird; allerdings wird sie nicht
entladen, wenn sie im Modus failed ist. Im Modus failed werden fehlgeschlagene Units nicht entladen,
bis der Benutzer systemctl reset-failed oder einen äquivalenten Befehl auf ihnen aufruft, um den
Zustand failed zurückzusetzen. Dieses Verhalten wird geändert, falls die Option auf
inactive-or-failed gesetzt wird: in diesem Fall wird die Unit entladen, selbst falls die Unit im
Zustand failed ist und daher ist ein explizites Zurücksetzen des Zustands failed nicht notwendig.
Beachten Sie, dass Unit-Ergebnisse (wie Exit-Codes, Exit-Signale, verbrauchte Ressourcen, …) sofort
nach Abschluss der Units entsorgt werden, außer dem Anteil, der im Protokollieruntersystem
gespeichert ist, falls dieser Modus verwandt wird. Standardmäßig inactive.
FailureAction=, SuccessAction=
Konfiguriert die durchzuführende Aktion, wenn die Unit stoppt und in einen Fehlzustand oder inaktiven
Zustand eintritt. Akzeptiert entweder none, reboot, reboot-force, reboot-immediate, poweroff,
poweroff-force, poweroff-immediate, exit oder exit-force. Im Systemmodus sind alle Optionen erlaubt.
Im Benutzermodus sind nur none, exit und exit-force erlaubt. Beide Optionen sind standardmäßig none.
Falls none gesetzt ist, wird keine Aktion ausgelöst. reboot verursacht einen Neustart nach der
normalen Herunterfahrprozedur (d.h. äquivalent zu systemctl reboot). reboot-force führt zu einem
erzwungenen Neustart, der alle Prozesse zwangsweise beenden wird, aber beim Neustart kein unsauberes
Dateisystem erzeugen sollte (d.h. äquivalent zu systemctl reboot -f) und reboot-immediate führt zu
einer sofortigen Ausführung des Systemaufrufs reboot(2), was zu Datenverlust führen kann (d.h.
äquivalent zu systemctl reboot -ff). Ähnlich haben poweroff, poweroff-force, poweroff-immediate die
Wirkung des Herunterfahrens des Systems mit ähnlichen Semantiken. exit führt dazu, dass sich der
Verwalter beendet, wobei er der normalen Herunterfahrprozedur folgt, und exit-force führt dazu, dass
er sich ohne Herunterfahren der Dienste beendet. Wenn exit oder exit-force verwandt werden, wird
standardmäßig der Exit-Status des Hauptprozesses der Unit (falls dies zutrifft) vom Diensteverwalter
zurückgeliefert. Dies kann allerdings mit FailureActionExitStatus=/SuccessActionExitStatus= außer
Kraft gesetzt werden, siehe unten.
FailureActionExitStatus=, SuccessActionExitStatus=
Steuert den Exit-Status, der an den Container-Verwalter zurückgeleitet werden soll (im Falle von
Systemdiensten) oder dem Diensteverwalter (im Falle eines Benutzerverwalters), wenn die
FailureAction=/SuccessAction= auf exit oder exit-force gesetzt sind und die Aktion ausgelöst wird.
Standardmäßig wird der Exit-Status des Hauptprozesses der auslösenden Unit (falls dies zutrifft)
weitergeleitet. Akzeptiert einen Wert im Bereich 0…255 oder die leere Zeichenkette, um das
Standardverhalten zu erbitten.
JobTimeoutSec=, JobRunningTimeoutSec=
Wenn ein Auftrag für diese Unit in die Warteschlange eingereiht wird, kann eine Zeitüberschreitung
JobTimeoutSec= konfiguriert werden. Ähnlich zu JobRunningTimeoutSec= beginnt er zu zählen, wenn der
in die Warteschlange eingereihte Auftrag tatsächlich gestartet wird. Falls eine der Zeitbegrenzungen
erreicht ist, wird der Auftrag abgebrochen, die Unit wird allerdings nicht ihren Zustand ändern oder
sogar den Modus »failed« einnehmen. Dieser Wert beträgt standardmäßig »infinity«
(Auftrags-Zeitüberschreitungen deaktiviert), außer für Geräte-Units (JobRunningTimeoutSec= ist
standardmäßig DefaultTimeoutStartSec=). Hinweis: Diese Zeitüberschreitung ist unabhängig von allen
Unit-spezifischen Zeitüberschreitungen (beispielsweise den mit TimeoutStartSec= in Dienste-Units
gesetzten Zeitüberschreitungen), da die Auftragszeitüberschreitung keine Wirkung für die Unit selbst
hat, nur für den Auftrag, der für sie warten könnte. Oder mit anderen Worten: Unit-spezifische
Zeitüberschreitungen sind nützlich, um Zustandsänderungen von Units abzubrechen und sie
zurückzunehmen. Die mit dieser Option gesetzten Auftrags-Zeitüberschreitungen sind allerdings nur
nützlich, um den Auftrag abzubrechen, der darauf wartet, dass die Unit den Zustand ändert.
JobTimeoutAction=, JobTimeoutRebootArgument=
JobTimeoutAction= konfiguriert optional eine zusätzliche Aktion, die beim Erreichen der
Zeitüberschreitung unternommen werden soll, siehe die Beschreibung von JobTimeoutSec= und
JobRunningTimeoutSec= oben. Es akzeptiert die gleichen Werte wie StartLimitAction=. Standardmäßig
none. JobTimeoutRebootArgument= konfiguriert eine optionale Neustartzeichenkette, die an den
Systemaufruf reboot(2) übergeben wird.
StartLimitIntervalSec=Intervall, StartLimitBurst=Häufung
Konfiguriert die Unit-Startratenbegrenzung. Units, die mehr als Häufung mal innerhalb des
Zeitintervalls Intervall gestartet werden, wird kein weiterer Start erlaubt. Verwenden Sie
StartLimitIntervalSec=, um das Überprüfungsintervall (standardmäßig DefaultStartLimitIntervalSec= in
Verwalterkonfigurationsdatei, setzen Sie es auf 0, um jede Art von Ratenbegrenzung zu deaktivieren)
zu konfigurieren. Verwenden Sie StartLimitBurst=, um zu konfigurieren, wie viele Starts pro Intervall
erlaubt sind (standardmäßig DefaultStartLimitBurst= in Verwalterkonfigurationsdatei). Diese
Konfigurationsoptionen sind insbesondere in Zusammenspiel mit der Diensteeinstellung Restart= (siehe
systemd.service(5)) nützlich; allerdings gelten sie für alle Arten von Starts (einschließlich
manuellen), nicht nur die durch die Logik Restart= ausgelösten. Beachten Sie, dass Units, die für
Restart= konfiguriert sind und die die Startbegrenzung erreicht haben, nicht mehr zum Neustarten
versucht werden; allerdings können sie weiterhin manuell zu einem späteren Zeitpunkt neu gestartet
werden, nachdem das Intervall abgelaufen ist. Von diesem Zeitpunkt an ist die Neustartlogik wieder
aktiviert. Beachten Sie, dass systemctl reset-failed dazu führen wird, dass der Neustartratenzähler
für einen Dienst entleert wird, was nützlich ist, falls der Administrator eine Unit manuell starten
möchte und die Startratenbegrenzung dabei stört. Beachten Sie, dass diese Ratenbegrenzung
durchgesetzt wird, nachdem alle Unit-Bedingungsprüfungen ausgeführt sind und daher zählen
Unit-Aktivierungen mit fehlschlagenden Bedingungen nicht bei dieser Ratenbegrenzung mit. Diese
Einstellung wird für Scheiben-, Ziel-, Geräte- und Bereichs-Units nicht angewandt, da dies Unit-Typen
sind, deren Aktivierung niemals fehlschlagen oder nur ein einziges Mal erfolgreich sein dürfen.
Wenn eine Unit aufgrund der Müllabführlogik entladen wird (siehe oben) werden auch ihre
Ratenbegrenzungszähler entleert. Das bedeutet, dass die Konfiguration einer Startratenbegrenzung für
eine Unit, die nicht kontinuierlich referenziert wird, keine Wirkung hat.
StartLimitAction=
Konfiguriert eine zusätzliche Aktion, die ergriffen werden soll, falls die mit StartLimitIntervalSec=
und StartLimitBurst= konfigurierte Ratenbegrenzung erreicht wird. Akzeptiert die gleichen Werte wie
die Einstellungen FailureAction=/SuccessAction= 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=,
ConditionMemory=, ConditionCPUs=
Ü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. Units mit fehlgeschlagenen Bedingungen
werden als in einem sauberen Zustand betrachtet und der Speicher wird aufgeräumt (automatische
Speicherbereinigung), falls sie nicht referenziert werden. Das bedeutet, dass bei Abfragen die
Fehlschlagbedingung im Zustand der Unit angezeigt oder nicht angezeigt werden könnte.
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. Das Bedingungs-Verb von systemd-analyze(1) kann zum Testen von
Bedingungen und Zusicherungsausdrücken verwandt werden.
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«, »podman«, »rkt«, »wsl«,
»acrn«, um gegen eine bestimmte Implementierung zu prüfen oder »private-users«, um zu prüfen, ob das
System in einem Benutzernamensraum läuft. Siehe systemd-detect-virt(1) für eine vollständige Liste
der bekannten Virtualisierungstechniken und ihrer Kennungen. Falls mehrere Virtualisierungstechniken
verschachtelt sind, wird nur die innerste betrachtet. Der Test kann durch Voranstellung eines
Ausrufezeichens negiert werden.
ConditionHost= 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 List von (möglicherweise in Anführungszeichen gesetzten) Ausdrücken
sein. Für jeden der Ausdrücke wird, falls er mit einem aus »<«, »<=«, »=«, »!=«, »>=«, »>« beginnt,
ein relativer Vergleich durchgeführt, andernfalls wird die festgelegte Zeichenkette mit Shell-artigen
Globs abgeglichen.
Beachten Sie, dass die Verwendung der Kernelversionszeichenkette eine unzuverlässige Art ist, um zu
bestimmen, welche Funktionalitäten vom Kernel unterstützt werden, da häufig Funktionalitäten eines
Kernels und Korrekturen von neueren Kerneln der Originalautoren in ältere, von Distributionen
bereitgestellte Versionen zurückportiert werden. Daher ist die Prüfung inhärent unportierbar und
sollte nicht für Units verwandt werden, die auf verschiedenen Distributionen verwandt werden könnten.
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«.
ConditionMemory= überprüft, ob die festgelegte Menge an Systemspeicher für das aktuelle System
verfügbar ist. Akzeptiert eine Speichergröße in Byte als Argument, optional kann ein
Vergleichsoperator »<«, »<=«, »=«, »!=«, »>=«, »>« vorangestellt werden. Auf Systemen, die direkt auf
der Hardware laufen, vergleicht es die Menge an physischen Speicher im System mit der festgelegten
Größe unter Berücksichtigung des festgelegten Vergleichsoperators. In Containern wird stattdessen die
Menge des zugewiesenen Speichers verglichen.
ConditionCPUs= überprüft, ob die festgelegte Anzahl an CPUs für das aktuelle System verfügbar ist.
Akzeptiert eine Anzahl an CPUs als Argument, optional kann ein Vergleichsoperator »<«, »<=«, »=«,
»!=«, »>=«, »>« vorangestellt werden. Vergleicht die Anzahl der CPUs in der CPU-Affinitätsmaske, die
im Diensteverwalter selbst konfiguriert ist, mit der festgelegten Zahl unter Berücksichtigung des
festgelegten Vergleichsoperators. Auf physischen Systemen passt die Anzahl der CPUs in der
Affinitätsmaske des Diensteverwalters normalerweise zu der Anzahl der physischen CPUs, aber in
besonderen und virtuellen Umgebungen kann sich das unterscheiden. Insbesondere in Containern passt
die Affinitätsmaske normalerweise zu der dem Container zugewiesenen Anzahl an CPUs und nicht zu der
Anzahl der physisch verfügbaren.
AssertArchitecture=, AssertVirtualization=, AssertHost=, AssertKernelCommandLine=, AssertKernelVersion=,
AssertSecurity=, AssertCapability=, AssertACPower=, AssertNeedsUpdate=, AssertFirstBoot=,
AssertPathExists=, AssertPathExistsGlob=, AssertPathIsDirectory=, AssertPathIsSymbolicLink=,
AssertPathIsMountPoint=, AssertPathIsReadWrite=, AssertDirectoryNotEmpty=, AssertFileNotEmpty=,
AssertFileIsExecutable=, AssertUser=, AssertGroup=, AssertControlGroupController=
Ähnlich zu den oben beschriebenen Bedingungseinstellungen ConditionArchitecture=,
ConditionVirtualization=, … fügen diese Einstellungen Zusicherungsprüfungen zum Hochfahren der Unit
hinzu. Anders als bei den Bedingungseinstellungen führt jede Zusicherungseinstellung, die nicht
erfüllt wird, zu einem Fehlschlag des Startauftrags (das bedeutet, dass es laut protokolliert wird).
Beachten Sie, dass das Erreichen einer konfigurierten Zusicherung nicht dazu führt, dass die Unit in
den Zustand »failed« eintritt (oder tatsächlich zu irgendeiner Zustandsänderung der Unit führt).
Verwenden Sie Zusicherungsausdrücke für Units, die nicht agieren können, falls bestimmte
Anforderungen nicht erfüllt sind und wenn dies etwas ist, was sich der Administrator oder Benutzer
anschauen sollte.
Beachten Sie, dass weder eine Zusicherung noch ein Bedingungsausdruck zu Unit-Zustandsänderungen
führt. Beachten Sie auch, dass beide zum Zeitpunkt geprüft werden, zu dem der Auftrag ausgeführt
werden soll, d.h. lange nachdem abhängige Aufträge und er selbst in die Warteschlange eingereiht
wurden. Daher sind weder die Bedingungs- noch die Zusicherungsausdrücke dazu geeignet,
Unit-Abhängigkeitsbedingungen auszudrücken.
Das Bedingungs-Verb aus systemd-analyze(1) kann zum Testen von Bedingungen und Zusicherungsausdrücken
verwandt werden.
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«-Eigenschaft │ Wo benutzt │
├────────────────────────┼─────────────────────────┼────────────────────────────────────────────┤
│ Before= │ After= │ │
├────────────────────────┼─────────────────────────┤ [Unit]-Abschnitt │
│ After= │ Before= │ │
├────────────────────────┼─────────────────────────┼─────────────────────┬──────────────────────┤
│ Requires= │ RequiredBy= │ [Unit]-Abschnitt │[Install]-Abschnitt │
├────────────────────────┼─────────────────────────┼─────────────────────┼──────────────────────┤
│ Wants= │ WantedBy= │ [Unit]-Abschnitt │[Install]-Abschnitt │
├────────────────────────┼─────────────────────────┼─────────────────────┼──────────────────────┤
│ PartOf= │ ConsistsOf= │ [Unit]-Abschnitt │eine automatische │
│ │ │ │Eigenschaft │
├────────────────────────┼─────────────────────────┼─────────────────────┼──────────────────────┤
│ BindsTo= │ BoundBy= │ [Unit]-Abschnitt │eine automatische │
│ │ │ │Eigenschaft │
├────────────────────────┼─────────────────────────┼─────────────────────┼──────────────────────┤
│ Requisite= │ RequisiteOf= │ [Unit]-Abschnitt │eine automatische │
│ │ │ │Eigenschaft │
├────────────────────────┼─────────────────────────┼─────────────────────┴──────────────────────┤
│ Triggers= │ TriggeredBy= │ automatische Eigenschaften, siehe Hinweise │
│ │ │ unten │
├────────────────────────┼─────────────────────────┼─────────────────────┬──────────────────────┤
│ Conflicts= │ ConflictedBy= │ [Unit]-Abschnitt │eine automatische │
│ │ │ │Eigenschaft │
├────────────────────────┼─────────────────────────┼─────────────────────┴──────────────────────┤
│ PropagatesReloadTo= │ ReloadPropagatedFrom= │ │
├────────────────────────┼─────────────────────────┤ [Unit]-Abschnitt │
│ ReloadPropagatedFrom= │ PropagatesReloadTo= │ │
├────────────────────────┼─────────────────────────┼─────────────────────┬──────────────────────┤
│ Following= │ n.Z. │ eine automatische │ │
│ │ │ Eigenschaft │ │
└────────────────────────┴─────────────────────────┴─────────────────────┴──────────────────────┘
Beachten Sie: WantedBy= und RequiredBy= werden im Abschnitt [Install] verwandt, um Symlinks in .wants/-
und .requires/-Verzeichnissen zu erstellen. Sie können nicht in Unit-Konfigurationseinstellungen direkt
verwandt werden.
Beachten Sie: ConsistsOf=, BoundBy=, RequisiteOf=, ConflictedBy= werden zusammen mit ihren Inversen
implizit erstellt und können nicht direkt festgelegt werden.
Beachten Sie: Triggers= wird implizit zwischen einem Socket, einer Pfad-Unit oder einer Automount-Unit
und der sie aktivierenden Unit erstellt. Standardmäßig wird eine Unit mit dem gleichen Namen ausgelöst,
dies kann aber mit den Einstellungen Sockets=, Service= und Unit= außer Kraft gesetzt werden. Siehe
systemd.service(5), systemd.socket(5), systemd.path(5) und systemd.automount(5) für ihre Details.
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
┌──────────────┬──────────────────────────────┬──────────────────────────────┐
│ Kennzeichner │ Bedeutung │ Details │
├──────────────┼──────────────────────────────┼──────────────────────────────┤
│ "%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 /var/cache │
│ │ Zwischenspeichers │ (für den Systemverwalter) │
│ │ │ oder worauf der Pfad │
│ │ │ »$XDG_CACHE_HOME« zeigt (für │
│ │ │ Benutzerverwalter). │
├──────────────┼──────────────────────────────┼──────────────────────────────┤
│ "%E" │ Wurzelverzeichnis der │ Dies ist entweder /etc (für │
│ │ Konfiguration │ den Systemverwalter) oder │
│ │ │ worauf der Pfad │
│ │ │ »$XDG_CONFIG_HOME« zeigt │
│ │ │ (für Benutzerverwalter). │
├──────────────┼──────────────────────────────┼──────────────────────────────┤
│ "%f" │ Demaskierter Dateiname │ Dies ist entweder der │
│ │ │ demaskierte Instanzenname │
│ │ │ (falls zutreffend), dem / │
│ │ │ vorangestellt wurde (falls │
│ │ │ zutreffend), oder der │
│ │ │ desmaskierte Präfixname, dem │
│ │ │ / vorangestellt wurde. │
│ │ │ Hiermit wird das Demaskieren │
│ │ │ entsprechend den oben │
│ │ │ beschriebenen Regeln des │
│ │ │ Maskierens absoluter │
│ │ │ Dateisystempfade │
│ │ │ implementiert. │
├──────────────┼──────────────────────────────┼──────────────────────────────┤
│ "%h" │ Benutzer-Home-Verzeichnis. │ Dies ist das │
│ │ │ Home-Verzeichnis des │
│ │ │ Benutzers, der die │
│ │ │ Diensteverwalterinstanz │
│ │ │ ausführt. Im Falle des │
│ │ │ Systemverwalters löst sich │
│ │ │ dies auf »/root« auf. │
│ │ │ │
│ │ │ Beachten Sie, dass diese │
│ │ │ Einstellung nicht von der im │
│ │ │ Abschnitt [Service] der │
│ │ │ Dienste-Unit │
│ │ │ konfigurierbaren Einstellung │
│ │ │ User= beeinflusst wird. │
├──────────────┼──────────────────────────────┼──────────────────────────────┤
│ "%H" │ Rechnername │ Der Rechnername des │
│ │ │ laufenden Systems zum │
│ │ │ Zeitpunkt des Ladens der │
│ │ │ Unit-Konfiguration. │
├──────────────┼──────────────────────────────┼──────────────────────────────┤
│ "%i" │ Instanzenname │ Für instanziierte Units ist │
│ │ │ dies die Zeichenkette │
│ │ │ zwischen dem ersten │
│ │ │ »@«-Zeichen und der │
│ │ │ Typendung. Leer für │
│ │ │ nichtinstanziierte Units. │
├──────────────┼──────────────────────────────┼──────────────────────────────┤
│ "%I" │ Demaskierter Instanzenname │ Identisch zu »%i«, aber mit │
│ │ │ zurückgenommener Maskierung. │
├──────────────┼──────────────────────────────┼──────────────────────────────┤
│ "%j" │ Abschließende Komponente des │ Dies ist die Zeichenkette │
│ │ Präfixes │ 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 mit │
│ │ abschließende Komponente des │ zurückgenommener Maskierung. │
│ │ Präfixes │ │
├──────────────┼──────────────────────────────┼──────────────────────────────┤
│ "%L" │ Wurzel des │ Dies ist entweder /var/log │
│ │ Protokollierverzeichnisses │ (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 Präfixname │ Identisch zu »%p«, aber 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 /var/lib │
│ │ Zustandsverzeichnisses │ (für den Systemverwalter) │
│ │ │ oder worauf der Pfad │
│ │ │ »$XDG_CONFIG_HOME« zeigt │
│ │ │ (für Benutzerverwalter). │
├──────────────┼──────────────────────────────┼──────────────────────────────┤
│ "%t" │ Wurzel des │ Dies ist entweder /run (für │
│ │ Laufzeitverzeichnisses │ den Systemverwalter) oder │
│ │ │ worauf der Pfad │
│ │ │ »$XDG_RUNTIME_DIR« zeigt │
│ │ │ (für Benutzerverwalter). │
├──────────────┼──────────────────────────────┼──────────────────────────────┤
│ "%T" │ Verzeichnis für temporäre │ Dies ist entweder /tmp oder │
│ │ Dateien │ der Pfad, auf den »$TMPDIR«, │
│ │ │ »$TEMP« oder »$TMP« gesetzt │
│ │ │ ist. │
├──────────────┼──────────────────────────────┼──────────────────────────────┤
│ "%g" │ Benutzergruppe │ Dies ist der Name der │
│ │ │ Gruppe, die die │
│ │ │ Diensteverwalterinstanz │
│ │ │ ausführt. Im Falle des │
│ │ │ Systemverwalters löst sich │
│ │ │ dies auf »root« auf. │
├──────────────┼──────────────────────────────┼──────────────────────────────┤
│ "%G" │ Benutzer-GID │ Dies ist die numerische GID │
│ │ │ des Benutzers, der die │
│ │ │ Diensteverwalterinstanz │
│ │ │ ausführt. Im Falle des │
│ │ │ Systemverwalters löst sich │
│ │ │ dies auf »0« auf. │
├──────────────┼──────────────────────────────┼──────────────────────────────┤
│ "%u" │ Benutzername │ Dies ist der Name des │
│ │ │ Benutzers, der die │
│ │ │ Diensteverwalterinstanz │
│ │ │ ausführt. Im Falle des │
│ │ │ Systemverwalters löst sich │
│ │ │ dies auf »root« auf. │
│ │ │ │
│ │ │ Beachten Sie, dass diese │
│ │ │ Einstellung nicht von der im │
│ │ │ Abschnitt [Service] der │
│ │ │ Dienste-Unit │
│ │ │ konfigurierbaren Einstellung │
│ │ │ User= beeinflusst wird. │
├──────────────┼──────────────────────────────┼──────────────────────────────┤
│ "%U" │ Benutzer-UID │ Dies ist die numerische UID │
│ │ │ des Benutzers, der die │
│ │ │ Diensteverwalterinstanz │
│ │ │ ausführt. Im Falle des │
│ │ │ Systemverwalters löst sich │
│ │ │ dies auf »0« auf. │
│ │ │ │
│ │ │ Beachten Sie, dass diese │
│ │ │ Einstellung nicht von der im │
│ │ │ Abschnitt [Service] der │
│ │ │ Dienste-Unit │
│ │ │ konfigurierbaren Einstellung │
│ │ │ User= beeinflusst wird. │
├──────────────┼──────────────────────────────┼──────────────────────────────┤
│ "%v" │ Kernelveröffentlichung │ Identisch zur Ausgabe von │
│ │ │ uname -r │
├──────────────┼──────────────────────────────┼──────────────────────────────┤
│ "%V" │ Verzeichnis für größere und │ Dies ist entweder /var/tmp │
│ │ dauerhafte temporäre Dateien │ oder der Pfad, 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>.
systemd 243 SYSTEMD.UNIT(5)