.\" -*- coding: UTF-8 -*-
'\" t
.\"*******************************************************************
.\"
.\" This file was generated with po4a. Translate the source file.
.\"
.\"*******************************************************************
.TH SYSTEMD\&.UNIT 5 "" "systemd 255" systemd.unit
.ie  \n(.g .ds Aq \(aq
.el       .ds Aq '
.\" -----------------------------------------------------------------
.\" * Define some portability stuff
.\" -----------------------------------------------------------------
.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.\" http://bugs.debian.org/507673
.\" http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html
.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.\" -----------------------------------------------------------------
.\" * set default formatting
.\" -----------------------------------------------------------------
.\" disable hyphenation
.nh
.\" disable justification (adjust text to left margin only)
.ad l
.\" -----------------------------------------------------------------
.\" * MAIN CONTENT STARTS HERE *
.\" -----------------------------------------------------------------
.SH BEZEICHNUNG
systemd.unit \- Unit\-Konfiguration
.SH ÜBERSICHT
.PP
\fIDienst\fP\&.service, \fISocket\fP\&.socket, \fIGerät\fP\&.device,
\fIEinhängung\fP\&.mount, \fISelbsteinhängung\fP\&.automount,
\fIAuslagerung\fP\&.swap, \fIZiel\fP\&.target, \fIPfad\fP\&.path, \fITimer\fP\&.timer,
\fIScheibe\fP\&.slice, \fIBereich\fP\&.scope
.SS System\-Unit\-Suchpfad
.PP
.nf
/etc/systemd/system\&.control/*
/run/systemd/system\&.control/*
/run/systemd/transient/*
/run/systemd/generator\&.early/*
/etc/systemd/system/*
/etc/systemd/system\&.attached/*
/run/systemd/system/*
/run/systemd/system\&.attached/*
/run/systemd/generator/*
…
/usr/lib/systemd/system/*
/run/systemd/generator\&.late/*
.fi
.SS Benutzer\-Unit\-Suchpfad
.PP
.nf
~/\&.config/systemd/user\&.control/*
$XDG_RUNTIME_DIR/systemd/user\&.control/*
$XDG_RUNTIME_DIR/systemd/transient/*
$XDG_RUNTIME_DIR/systemd/generator\&.early/*
~/\&.config/systemd/user/*
$XDG_CONFIG_DIRS/systemd/user/*
/etc/systemd/user/*
$XDG_RUNTIME_DIR/systemd/user/*
/run/systemd/user/*
$XDG_RUNTIME_DIR/systemd/generator/*
$XDG_DATA_HOME/systemd/user/*
$XDG_DATA_DIRS/systemd/user/*
…
/usr/lib/systemd/user/*
$XDG_RUNTIME_DIR/systemd/generator\&.late/*
.fi
.SH BESCHREIBUNG
.PP
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 \fBsystemd\fP(1) gesteuerten
und überwachten Timer, eine Ressourcenverwaltungsscheibe oder eine Gruppe
von extern erstellten Prozessen kodiert\&. Siehe \fBsystemd.syntax\fP(7) für
eine allgemeine Beschreibung der Syntax\&.
.PP
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\&.
.PP
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: \fBsystemd.service\fP(5),
\fBsystemd.socket\fP(5), \fBsystemd.device\fP(5), \fBsystemd.mount\fP(5),
\fBsystemd.automount\fP(5), \fBsystemd.swap\fP(5), \fBsystemd.target\fP(5),
\fBsystemd.path\fP(5), \fBsystemd.timer\fP(5), \fBsystemd.slice\fP(5),
\fBsystemd.scope\fP(5)\&.
.PP
Unit\-Dateien werden von einer Reihe von Pfaden, die während der Compilierung
bestimmt werden, geladen\&. Dies wird im nächsten Abschnitt beschrieben\&.
.PP
Gültige Unit\-Namen bestehen aus einen »Unit\-Namensvorsatz« und einer Endung,
die den Unit\-Typ festlegt und mit einem Punkt beginnt\&. Der
»Unit\-Namenvorsatz« muss aus einem oder mehreren gültigen Zeichen
(ASCII\-Buchstaben, Ziffern, »:«, »\-«, »_«, »\&.« und »\e« bestehen)\&. Die
Gesamtlänge des Unit\-Names einschließlich der Endung darf 255 Zeichen nicht
überschreiten\&. Die Unit\-Typ\-Endung muss entweder »\&.service«,
»\&.socket«, »\&.device«, »\&.mount«, »\&.automount«, »\&.swap«,
»\&.target«, »\&.path«, »\&.timer«, »\&.slice« oder »\&.scope« sein\&.
.PP
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
Unit\-Namenvorsatzes 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\&.
.PP
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 \fBX\-\fP
steht, wird diese(r) von Systemd komplett ignoriert\&. Optionen innerhalb
eines ignorierten Abschnittes benötigen die vorangestellte Kennung
nicht\&. Anwendungen können dies dazu verwenden, zusätzliche Informationen
in den Unit\-Dateien aufzunehmen\&. Um auf diese Optionen zuzugreifen, müssen
Anwendungen die Unit\-Dateien selbst auswerten\&.
.PP
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 \fBsystemd\fP auf die Anfrage über
D\-Bus, dbus\-org\&.freedesktop\&.network1\&.service zu laden,
systemd\-networkd\&.service laden wird\&. Als weiteres Beispiel ist
default\&.target \(em das Standard\-Systemziel, was beim Systemstart
gestartet wird \(em oft über einen Alias mit entweder multi\-user\&.target
oder graphical\&.target verbunden, um auszuwählen, was standardmäßig
gestartet wird\&. Aliasnamen können in Befehlen wie \fBdisable\fP, \fBstart\fP,
\fBstop\fP, \fBstatus\fP und ähnlichen und in allen Unit\-Abhängigkeitsanweisungen
einschließlich \fIWants=\fP, \fIRequires=\fP, \fIBefore=\fP, \fIAfter=\fP verwandt
werden\&. Aliase können nicht mit dem Befehl \fBpreset\fP verwandt werden\&.
.PP
Alias unterliegen den folgenden Beschränkungen: Eine Unit eines bestimmten
Typs (»\&.service«, »\&.socket«, …) kann nur ein Alias auf einen Namen mit
der gleichen Typendung werden\&. Eine einfache Unit (keine Vorlage oder
Instanz) darf nur ein Alias auf einen einfachen Namen werden\&. Eine
Vorlageninstanz darf nur durch eine andere Vorlageninstanz einen Alias
erhalten und der Instanzanteil muss identisch sein\&. Eine Vorlage darf
durch eine andere Vorlage einen Alias erhalten (dann gilt der Alias für alle
Instanzen der Vorlage)\&. Eine Vorlageninstanz
(z\&.B\&. »alias@inst\&.service«) darf als Spezialfall ein Symlink auf eine
andere Vorlage sein (z\&.B\&. »template@inst\&.service«)\&. In diesem Fall
wird nur für diese spezielle Instanz ein Alias angelegt, während andere
Instanzen dieser Vorlage (z\&.B\&. »alias@foo\&.service«,
»alias@bar\&.service«) keinen Alias erhalten\&. Diese Regeln erhalten die
Anforderung, dass die Instanz (falls vorhanden) immer eindeutig für eine
gegebene Unit und alle ihre Aliase definiert ist\&. Das Ziel des
Alias\-Symlinks muss auf einen gültigen Unit\-Dateiort zeigen, d\&.h\&. der
Symlink\-Zieldateiname muss wie beschrieben auf den Symlink\-Quellnamen passen
und der Zielpfad muss in einem der Unit\-Suchpfade sein, siehe nachfolgenden
UNIT\-DATEI\-LADEPFAD für weitere Details\&. Beachten Sie, dass die Zieldatei
nicht existieren könnte, d\&.h\&. der Symlink hängen könnte\&.
.PP
Zusätzlich können Unit\-Dateien Aliase mittels der Anweisung \fIAlias=\fP 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
\fIAlias=ctrl\-alt\-del\&.target\fP so fest, dass der Symlink
/etc/systemd/system/ctrl\-alt\-del\&.service auf die Datei reboot\&.target bei
der Aktivierung erstellt wird und wenn Strg\-Alt\-Entf gedrückt wird,
\fBsystemd\fP nach ctrl\-alt\-del\&.service suchen und reboot\&.service ausführen
wird\&. \fBsystemd\fP 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\&.
.PP
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
\fIWants=\fP für die Unit hinzugefügt\&. Eine ähnliche Funktionalität existiert
auch für Abhängigkeiten vom Typ \fIRequires=\fP, 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 \fIWants=\fP und \fIRequires=\fP
siehe unten\&. Die bevorzugte Art, Symlinks in den Verzeichnissen \&.wants/
oder \&.requires/ erfolgt durch die Angabe der Abhängigkeit in dem Abschnitt
[Install] der Ziel\-Unit und Erstellung des Symlinks im Dateisystem mittels
des Befehls \fBenable\fP oder \fBpreset\fP von \fBsystemctl\fP(1)\&. Das Ziel kann
eine normale Unit sein (entweder einfach oder durch eine bestimmte Instanz
einer Vorlagen\-Unit)\&. Falls die Quell\-Unit eine Vorlage ist, kann die
Ziel\-Unit auch eine Vorlage sein, dann wird die Instanz zu der Ziel\-Unit
»weitergeleitet«, um eine gültige Unit\-Instanz zu bilden\&. Das Ziel von
Symlinks in \&.wants/ oder \&.requires/ muss daher auf einen gültigen
Unit\-Dateiort zeigen, d\&.h\&. der Symlink\-Zielname muss die beschriebenen
Anforderungen erfüllen und der Zielpfad muss in einem der Unit\-Suchpfade
liegen, siehe nachfolgenden UNIT\-DATEI\-LADEPFAD für weitere
Details\&. Beachten Sie, dass die Zieldatei nicht existieren könnte,
d\&.h\&. der Symlink hängen könnte\&.
.PP
Zusammen mit einer Unit\-Datei foo\&.service kann ein
»Ergänzungs«\-Verzeichnis foo\&.service\&.d/ existieren\&. Alle Dateien mit
der Endung »\&.conf« aus diesem Verzeichnis in alphanumerischer Reihenfolge
zusammengeführt und ausgewertet, nachdem die Unit\-Datei selbst ausgewertet
wurde\&. Dies ist nützlich, um die Konfigurationseinstellungen für eine Unit
zu verändern oder zu ergänzen, ohne die Unit\-Dateien selbst verändern zu
müssen\&. Jede Ergänzungsdatei muss geeignete Abschnittskopfzeilen
enthalten\&. Für instanziierte Units wird diese Logik zuerst nach dem
Instanzen\-Unterverzeichnis »\&.d/« (z\&.B\&. »foo@bar\&.service\&.d/«)
schauen und dessen »\&.conf«\-Dateien lesen, gefolgt von dem
Vorlagenunterverzeichnis »\&.d/« (z\&.B\&. »foo@\&.service\&.d/«) und den
»\&.conf«\-Dateien dort\&. Für Unit\-Namen, die desweiteren Bindestriche (»\-«)
enthalten, wird die Menge der Verzeichnisse, die durch wiederholtes
Abschneiden des Unit\-Namens nach allen Bindestrichen entsteht, auch
durchsucht\&. Insbesondere wird für einen Unit\-Namen
foo\-bar\-baz\&.service\&.d/ nicht nur der reguläre Ergänzungsverzeichnis
foo\-bar\-baz\&.service\&.d/ durchsucht, sondern auch foo\-bar\-\&.service\&.d/
als auch foo\-\&.service\&.d/ durchsucht\&. Dies ist nützlich, um gemeinsame
Ergänzungen für eine Gruppe von zusammengehörigen Units zu definieren, deren
Namen mit einem gemeinsamen Anfang beginnen\&. Dieses Schema ist
insbesondere für Einhänge\-, Automount\- und Scheiben\-Units, deren
systematische Benennungsstruktur rund um Bindestriche als Komponententrenner
aufgebaut ist, nützlich\&. Beachten Sie, dass gleichbenannte
Ergänzungsdateien weiter unten in der Anfangshierarchie solche weiter oben
außer Kraft setzen, d\&.h\&. foo\-bar\-\&.service\&.d/10\-override\&.conf setzt
foo\-\&.service\&.d/10\-override\&.conf außer Kraft\&.
.PP
Im Falle von (den oben beschriebenen) Unit\-Aliasen, werden die Ergänzungen
für die Aliasnamen und alle Aliasse geladen\&. Falls beispielsweise
default\&.target ein Alias für graphical\&.target ist, würden
default\&.target\&.d/, default\&.target\&.wants/,
default\&.target\&.requires/, graphical\&.target\&.d/,
graphical\&.target\&.wants/, graphical\&.target\&.requires/ alle
gelesen\&. Für Vorlagen werden die Ergänzungen für die Vorlage, alle
Vorlagen\-Aliasse, die Vorlageninstanz und alle Alias\-Instanzen
gelesen\&. Wird nur für eine bestimmte Vorlageninstanz ein Alias angelegt,
dann werden die Ergänzungen für die Zielvorlage, die Zielvorlageninstanz und
die Alias\-Vorlageninstanz gelesen\&.
.PP
Zusätzlich zu /etc/systemd/system können Ergänzungs\-»\&.d/«\-Verzeichnisse in
die Verzeichnisse /usr/lib/systemd/system oder /run/systemd/system abgelegt
werden\&. Ergänzungsdateien in /etc/ haben Vorrang vor denen in /run/, die
wiederum Vorrang vor denen in /usr/lib/ haben\&. Ergänzungsdateien unter all
diesen Verzeichnissen haben Vorrang vor der Haupt\-Netdev\-Datei, wo auch
immer sich diese befindet\&. Mehrere Ergänzungsdateien mit verschiedenen
Namen werden in lexikographischer Reihenfolge angewandt, unabhängig von dem
Verzeichnis, in dem sie sich befinden\&.
.PP
Units unterstützen auch ein Ergänzungs\-\fITyp\fP\&.d/\-Verzeichnis auf oberster
Ebene, wobei \fITyp\fP z\&.B\&. »service« oder »socket« sein darf\&. Dies
erlaubt es, die Einstellungen aller entsprechenden Unit\-Dateien auf dem
System zu verändern oder zu ergänzen\&. Die Formatierung und die
Vorrangregeln bei der Anwendung von Ergänzungskonfigurationen folgen dem
oben definiertem\&. Dateien in \fITyp\fP\&.d/ haben niedrigeren Vorrang im
Vergleich zu Dateien in namensspezifischen
Außerkraftsetzungsverzeichnissen\&. Es gelten die normalen Regeln: mehrere
Ergänzungsdateien mit verschiedenen Namen werden in lexikographischer
Reihenfolge angewandt, unabhängig davon, in welchem Verzeichnis sie sich
befinden, daher gilt eine Datei in \fITyp\fP\&.d/ für eine Unit nur, falls es
keine Ergänzung oder Maskierung mit diesem Namen in Verzeichnissen mit
höherem Vorrang gibt\&. Siehe Beispiele\&.
.PP
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\&.
.PP
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\&.
.PP
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\&.
.PP
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\&.
.PP
Das Unit\-Dateiformat wird durch die \m[blue]\fBSchnittstellenportabilitäts\- und \-stabilitätszusage\fP\m[]\&\s-2\u[1]\d\s+2 abgedeckt\&.
.SH "ZEICHENKETTENMASKIERUNG FÜR DIE AUFNAHME IN UNIT\-NAMEN"
.PP
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 \fBNUL\fP) 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\&.
.PP
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 »\ex2d«\-Maskierung ersetzt\&. Wenn »\&.« als erstes Zeichen in der
maskierten Zeichenkette auftauchen würde, wird es zusätzlich mit seiner
C\-artigen Maskierung ersetzt\&.
.PP
Wenn die Eingabe als absoluter Systempfad geeignet ist, wird dieser
Algorithmus leicht erweitert: der Pfad zum Wurzelverzeichnis »/« wird als
einzelner Bindestrich »\-« kodiert\&. Zusätzlich werden alle führenden,
abschließenden oder doppelten »/« Zeichen vor der Umwandlung aus der
Zeichenkette entfernt\&. Beispiel: /foo//bar/baz/ wird »foo\-bar\-baz«\&.
.PP
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
\fBsystemd\-escape \-\-path\fP, um Pfade zu maskieren und andernfalls
\fBsystemd\-escape\fP ohne \fB\-\-path\fP\&.
.SH "AUTOMATISCHE ABHÄNGIGKEITEN"
.SS "Implizite Abhängigkeiten"
.PP
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\&.
.PP
Beispielsweise erlangen Dienste\-Units mit \fIType=dbus\fP automatisch
Abhängigkeiten vom Typ \fIRequires=\fP und \fIAfter=\fP von dbus\&.socket\&. Siehe
\fBsystemd.service\fP(5) für Details\&.
.SS Standardabhängigkeiten
.PP
Standardabhängigkeiten sind ähnlich impliziten Abhängigkeiten, können aber
durch Setzen von \fIDefaultDependencies=\fP auf \fIyes\fP (die Vorgabe) und \fIno\fP
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 \fIDefaultDependencies=\fP in
jedem Unit\-Typ\&.
.PP
Beispielsweise werden Ziel\-Units alle konfigurierten Abhängigkeiten des Typs
\fIWants=\fP oder \fIRequires=\fP mit Abhängigkeiten vom Typ \fIAfter=\fP
ergänzen\&. Siehe \fBsystemd.target\fP(5) für Details\&. Beachten Sie, dass
dieses Verhalten durch Setzen von \fIDefaultDependencies=no\fP in den
festgelegten Units abgewählt werden kann\&. Es kann auch gezielt über eine
explizite Abhängigkeit \fIBefore=\fP außer Kraft gesetzt werden\&.
.SH UNIT\-DATEI\-LADEPFAD
.PP
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\&.
.PP
Wenn die Variable \fI$SYSTEMD_UNIT_PATH\fP gesetzt ist, setzt der Inhalt dieser
Variable den Unit\-Ladepfad außer Kraft\&. Falls \fI$SYSTEMD_UNIT_PATH\fP mit
einer leeren Komponente (»:«) endet, wird der normale Unit\-Ladepfad an den
Inhalt der Variablen angehängt\&.
.sp
.it 1 an-trap
.nr an-no-space-flag 1
.nr an-break-flag 1
.br
\fBTabelle\ \&1.\ \& Ladepfad beim Betrieb im Systemmodus (\-\-system)\&.\fP
.TS
allbox tab(:);
lB lB.
T{
Pfad
T}:T{
Beschreibung
T}
.T&
l l
l ^
l l
l l
l l
l l
l l
l l
l l
l l.
T{
/etc/systemd/system\&.control
T}:T{
Mittels Dbus\-API erstellte dauerhafte und flüchtige Konfiguration
T}
T{
/run/systemd/system\&.control
T}:
T{
/run/systemd/transient
T}:T{
Dynamische Konfiguration für flüchtige Units
T}
T{
/run/systemd/generator\&.early
T}:T{
Erstellte Units mit hoher Priorität (siehe \fIearly\-dir\fP in \fBsystemd.generator\fP(7))
T}
T{
/etc/systemd/system
T}:T{
System\-Units, die vom Administrator erstellt wurden
T}
T{
/run/systemd/system
T}:T{
Laufzeit\-Units
T}
T{
/run/systemd/generator
T}:T{
Erstellte Units mit mittlerer Priorität (siehe \fInormal\-dir\fP in \fBsystemd.generator\fP(7))
T}
T{
/usr/local/lib/systemd/system
T}:T{
System\-Units, die vom Administrator installiert wurden
T}
T{
/usr/lib/systemd/system
T}:T{
System\-Units, die durch den Paketverwalter der Distribution installiert wurden
T}
T{
/run/systemd/generator\&.late
T}:T{
Erstellte Units mit niedriger Priorität (siehe \fIlate\-dir\fP in \fBsystemd.generator\fP(7))
T}
.TE
.sp 1
.sp
.it 1 an-trap
.nr an-no-space-flag 1
.nr an-break-flag 1
.br
\fBTabelle\ \&2.\ \& Ladepfad bei der Ausführung im Benutzermodus (\-\-user)\&.\fP
.TS
allbox tab(:);
lB lB.
T{
Pfad
T}:T{
Beschreibung
T}
.T&
l l
l ^
l l
l l
l l
l l
l l
l l
l l
l l
l l
l l
l l
l l
l l
l l.
T{
$XDG_CONFIG_HOME/systemd/user\&.control oder ~/\&.config/systemd/user\&.control
T}:T{
Dauerhafte und flüchtige Konfiguration, die mittels des DBus\-APIs erstellt wird ((\fI$XDG_CONFIG_HOME\fP wird verwandt, falls gesetzt, andernfalls ~/\&.config)
T}
T{
$XDG_RUNTIME_DIR/systemd/user\&.control
T}:
T{
$XDG_RUNTIME_DIR/systemd/transient
T}:T{
Dynamische Konfiguration für flüchtige Units
T}
T{
$XDG_RUNTIME_DIR/systemd/generator\&.early
T}:T{
Erstellte Units mit hoher Priorität (siehe \fIearly\-dir\fP in \fBsystemd.generator\fP(7))
T}
T{
$XDG_CONFIG_HOME/systemd/user oder $HOME/\&.config/systemd/user
T}:T{
Benutzerkonfiguration (\fI$XDG_CONFIG_HOME\fP wird verwandt, falls gesetzt, andernfalls ~/\&.config)
T}
T{
$XDG_CONFIG_DIRS/systemd/user oder /etc/xdg/systemd/user
T}:T{
Zusätzliche Konfigurationsverzeichnisse, wie diese durch die XDG\-Basisverzeichnis\-Spezifikation festgelegt werden (\fI$XDG_CONFIG_DIRS\fP wird verwandt, falls gesetzt, andernfalls /etc/xdg)
T}
T{
/etc/systemd/user
T}:T{
Benutzer\-Units, die vom Administrator erstellt wurden
T}
T{
$XDG_RUNTIME_DIR/systemd/user
T}:T{
Laufzeit\-Units (nur verwandt, falls $XDG_RUNTIME_DIR gesetzt ist)
T}
T{
/run/systemd/user
T}:T{
Laufzeit\-Units
T}
T{
$XDG_RUNTIME_DIR/systemd/generator
T}:T{
Erstellte Units mit mittlerer Priorität (siehe \fInormal\-dir\fP in \fBsystemd.generator\fP(7))
T}
T{
$XDG_DATA_HOME/systemd/user oder $HOME/\&.local/share/systemd/user
T}:T{
Units von Paketen, die im Home\-Verzeichnis installiert wurden (\fI$XDG_DATA_HOME\fP wird verwandt, falls gesetzt, andernfalls ~/\&.local/share)
T}
T{
$XDG_DATA_DIRS/systemd/user oder /usr/local/share/systemd/user und /usr/share/systemd/user
T}:T{
Zusätzliche Datenverzeichnisse, wie diese durch die XDG\-Basisverzeichnis\-Spezifikation festgelegt werden (\fI$XDG_DATA_DIRS\fP wird verwandt, falls gesetzt, andernfalls /usr/local/share und /usr/share)
T}
T{
$dir/systemd/user für jedes \fI$dir\fP in \fI$XDG_DATA_DIRS\fP
T}:T{
Zusätzliche Orte für installierte Benutzer\-Units, einen für jeden Eintrag in \fI$XDG_DATA_DIRS\fP
T}
T{
/usr/local/lib/systemd/user
T}:T{
Benutzer\-Units, die durch den Administrator installiert wurden
T}
T{
/usr/lib/systemd/user
T}:T{
Benutzer\-Units, die durch den Paketverwalter der Distribution installiert wurden
T}
T{
$XDG_RUNTIME_DIR/systemd/generator\&.late
T}:T{
Erstellte Units mit niedriger Priorität (siehe \fIlate\-dir\fP in \fBsystemd.generator\fP(7))
T}
.TE
.sp 1
.PP
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 \fBsystemd.environment\-generator\fP(7)\&. Insbesondere
\fI$XDG_DATA_HOME\fP und \fI$XDG_DATA_DIRS\fP können leicht mittels
\fBsystemd\-environment\-d\-generator\fP(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
.sp
.if  n \{\
.RS 4
.\}
.nf
systemd\-analyze \-\-user unit\-paths
.fi
.if  n \{\
.RE
.\}
.PP
Desweiteren können zusätzliche Units aus Verzeichnissen, die nicht im
Unit\-Ladepfad sind, in Systemd hereingeladen werden, indem ein Symlink
erstellt wird, der auf eine Unit\-Datei im Verzeichnis zeigt\&. Sie können
\fBsystemctl link\fP für diese Aktion verwenden; siehe \fBsystemctl\fP(1)\&. Das
Dateisystem, in dem sich die verlinkten Dateien befinden, muss beim Start
von Systemd zugreifbar sein (d\&.h\&. alles unterhalb von /home/ oder /var/
ist nicht erlaubt, außer diese Verzeichnisse befinden sich auf dem
Wurzeldateisystem)\&.
.PP
Es ist wichtig, »verlinkte Unit\-Dateien« von »Unit\-Dateien mit Alias« zu
unterscheiden: Jeder Symlink, dessen Symlink\-\fIZiel\fP sich innerhalb des
Unit\-Ladepfades befindet, wird ein Alias: der Quellname und der Zielname
müssen den bestimmten, oben bei der Besprechung von Aliasen aufgeführten
Einschränkungen genügen, aber das Symlink\-Ziel muss nicht
existieren\&. Tatsächlich wird der Pfad zum Symlink\-Ziel nicht verwandt,
außer zu prüfen, ob das Ziel sich innerhalb des Unit\-Ladepfades
befindet\&. Im Gegensatz dazu bedeutet ein Symlink, der außerhalb des
Unit\-Ladepfades führt, eine verlinkete Unit\-Datei\&. Beim Laden der Datei
wird dem Symlink gefolgt, aber der Zielname wird ansonsten nicht verwandt
(und braucht noch nicht mal ein gültiger Unit\-Dateiname zu
sein)\&. Beispielsweise sind /etc/systemd/system/alias1\&.service →
Dienst1\&.service, /etc/systemd/system/alias2\&.service →
/usr/lib/systemd/Dienst1\&.service, /etc/systemd/system/alias3\&.service →
/etc/systemd/system/Dienst1\&.service alle gültige Aliase und
Dienst1\&.service wird vier Namen haben, selbst falls sich die Unit\-Datei
unter /run/systemd/system/Dienst1\&.service befindet\&. Im Gegensatz dazu
bedeutet ein Symlink /etc/systemd/system/link1\&.service →
\&.\&./link1_Dienstedatei, dass link1\&.service eine »verlinkte Unit« ist
und der Inhalt von /etc/systemd/link1_Dienstedatei seine Konfiguration
bereitstellt\&.
.SH UNIT\-MÜLLABFUHR
.PP
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:
.sp
.RS 4
.ie  n \{\
\h'-04' 1.\h'+01'\c
.\}
.el \{\
.sp -1
.IP "  1." 4.2
.\}
Eine andere geladene Unit referenziert sie mit einer Abhängigkeit wie
\fIAfter=\fP, \fIWants=\fP, …
.RE
.sp
.RS 4
.ie  n \{\
\h'-04' 2.\h'+01'\c
.\}
.el \{\
.sp -1
.IP "  2." 4.2
.\}
Die Unit startet, läuft, startet sich neu oder stoppt derzeit\&.
.RE
.sp
.RS 4
.ie  n \{\
\h'-04' 3.\h'+01'\c
.\}
.el \{\
.sp -1
.IP "  3." 4.2
.\}
Die Unit ist derzeit im Zustand \fBfailed\fP\&. (Siehe aber unten\&.)
.RE
.sp
.RS 4
.ie  n \{\
\h'-04' 4.\h'+01'\c
.\}
.el \{\
.sp -1
.IP "  4." 4.2
.\}
Ein Auftrag für die Unit ist anhängig\&.
.RE
.sp
.RS 4
.ie  n \{\
\h'-04' 5.\h'+01'\c
.\}
.el \{\
.sp -1
.IP "  5." 4.2
.\}
Die Unit ist durch ein aktives IPC\-Client\-Programm verankert\&.
.RE
.sp
.RS 4
.ie  n \{\
\h'-04' 6.\h'+01'\c
.\}
.el \{\
.sp -1
.IP "  6." 4.2
.\}
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\&.
.RE
.sp
.RS 4
.ie  n \{\
\h'-04' 7.\h'+01'\c
.\}
.el \{\
.sp -1
.IP "  7." 4.2
.\}
Die Unit hat ihr zugeordnete laufende Prozesse\&.
.RE
.PP
Die Müllabfuhrlogik kann mit der Option \fICollectMode=\fP verändert
werden\&. Diese Option erlaubt die Konfiguration, ob automatisches Entladen
von Units, die im Zustand \fBfailed\fP sind, erlaubt ist, siehe unten\&.
.PP
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\&.
.PP
Verwenden Sie \fBsystemctl daemon\-reload\fP 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\&.
.SH [UNIT]\-ABSCHNITT\-OPTIONEN
.PP
Die Unit\-Datei kann einen Abschnitt [Unit] enthalten, der generische
Informationen über die Unit transportiert, der nicht vom Unit\-Typ abhängt:
.PP
\fIDescription=\fP
.RS 4
Ein kurzer menschenlesbarer Titel für die Unit\&. Dieser kann von \fBsystemd\fP
(und anderen Benutzeroberflächen) als eine für den Benutzer sichtbare
Bezeichnung für die Unit verwandt werden, daher sollte diese Zeichenkette
die Unit identifizieren, statt sie zu beschreiben, trotz des Namens\&. Diese
Zeichenkette sollte auch nicht nur einfach den Unit\-Namen
wiederholen\&. »Apache2 Webserver« ist ein gutes Beispiel\&. Schlechte
Beispiele sind »leichtgewichtiger Hochleistungs\-HTTP\-Server« (zu generisch)
oder »Apache2« (für Leute, die Apache nicht kennen, bedeutungslos,
wiederholt den Namen der Unit)\&. \fBsystemd\fP kann dies als Substantiv in
Statusnachrichten (»Starting \fIdescription\fP\&.\&.\&.«, »Started
\fIdescription\fP\&.«, »Reached target \fIdescription\fP\&.«, »Failed to start
\fIdescription\fP\&.«) 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\&.«\&.
.sp
Hinzugefügt in Version 201\&.
.RE
.PP
\fIDocumentation=\fP
.RS 4
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 \fBuri\fP(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\&.
.sp
Hinzugefügt in Version 201\&.
.RE
.PP
\fIWants=\fP
.RS 4
Konfiguriert (schwache) Anforderungsabhängigkeiten auf andere Units\&. Diese
Option darf mehr als einmal angegeben werden oder mehrere, durch Leerraum
getrennte Units können in einer Option angegeben werden, in diesem Fall
werden Abhängigkeiten für alle aufgeführten Namen erstellt. Abhängigkeiten
dieses Typs können auch außerhalb von Unit\-Konfigurationsdateien hinzugefügt
werden, indem ein Symlink auf ein die Unit\-Datei begleitendes
\&.wants/\-Verzeichnis hinzugefügt wird\&. Siehe oben für Details\&.
.sp
In dieser Option aufgeführte Units werden gestartet, wenn die
konfigurierende Unit es wird\&. Falls allerdings die aufgeführte Unit nicht
startet oder der Transaktion nicht hinzugefügt werden kann, hat dies keine
Auswirkungen auf die Gültigkeit der Transaktion als Ganzes und diese Unit
wird dennoch gestartet\&. Dies ist die empfohlene Art, das Starten einer
Unit in den Start einer anderen Unit einzuhängen\&.
.sp
Beachten Sie, dass Anforderungsabhängigkeiten nicht die Reihenfolge
beeinflussen, in der Dienste gestartet oder gestoppt werden\&. Dies muss
unabhängig davon mit den Optionen \fIAfter=\fP oder \fIBefore=\fP konfiguriert
werden\&. Falls die Unit foo\&.service die Unit bar\&.service wie mit
\fIWants=\fP konfiguriert hereinzieht und mit \fIAfter=\fP oder \fIBefore=\fP keine
Ordnung konfiguriert ist, dann werden beide Units gleichzeitig und ohne
Verzögerung untereinander gestartet, wenn foo\&.service aktiviert wird\&.
.sp
Hinzugefügt in Version 201\&.
.RE
.PP
\fIRequires=\fP
.RS 4
Ähnlich \fIWants=\fP, erklärt aber eine stärkerere
Anforderungsabhängigkeit\&. Abhängigkeiten dieser Art können auch außerhalb
der Unit\-Konfigurationsdatei konfiguriert werden, indem ein Symlink auf ein
die Unit\-Datei begleitendes \&.requires/\-Verzeichnis hinzugefügt wird\&.
.sp
Falls diese Unit aktiviert wird, werden die aufgeführten Units ebenfalls
aktiviert\&. Falls die Aktivierung einer der anderen Units fehlschlägt und
eine Ordnungsabhängigkeit \fIAfter=\fP auf die fehlgeschlagene Unit gesetzt
ist, dann wird diese Unit nicht gestartet\&. Darüberhinaus wird diese Unit
gestoppt (oder neu gestartet), falls eine der anderen Units explizit
gestoppt (oder neu gestartet) wird, unahängig davon, ob \fIAfter=\fP gesetzt
ist oder nicht\&.
.sp
Oft ist es eine bessere Wahl, \fIWants=\fP statt \fIRequires=\fP zu verwenden, um
ein System zu erreichen, das im Umgang mit fehlschlagenden Diensten robuster
ist\&.
.sp
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
\fIConditionPathExists=\fP, \fIConditionPathIsSymbolicLink=\fP, … \(em siehe
unten) führen nicht dazu, dass der Start einer Unit mit einer
\fIRequires=\fP\-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
\fIRequires=\fP\-Abhängigkeit übertragen wird\&. Verwenden Sie den
Abhängigkeitstyp \fIBindsTo=\fP zusammen mit \fIAfter=\fP, 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)\&.
.sp
Hinzugefügt in Version 201\&.
.RE
.PP
\fIRequisite=\fP
.RS 4
Ähnlich zu \fIRequires=\fP\&. Falls die hier aufgeführten Units noch nicht
gestartet wurden, werden sie nicht gestartet und der Start dieser Unit wird
sofort fehlschlagen\&. \fIRequisite=\fP impliziert keine Ordnungsabhängigkeit,
selbst falls beide Units in der gleichen Transaktion gestartet
werden\&. Daher sollte diese Einstellung normalerweise mit \fIAfter=\fP
kombiniert werden, um sicherzustellen, dass diese Unit nicht vor der anderen
Unit gestartet wird\&.
.sp
Wenn \fIRequisite=b\&.service\fP auf a\&.service benutzt wird, wird diese
Abhängigkeit als \fIRequisiteOf=a\&.service\fP in der Eigenschaftsliste von
b\&.service angezeigt\&. \fIRequisiteOf=\fP\-Abhängigkeiten können nicht direkt
festgelegt werden\&.
.sp
Hinzugefügt in Version 201\&.
.RE
.PP
\fIBindsTo=\fP
.RS 4
Konfiguriert Anforderungsabhängigkeiten, im Stil sehr ähnlich zu
\fIRequires=\fP\&. Allerdings ist dieser Abhängigkeitstyp stärker: Zusätzlich
zu dem Effekt von \fIRequires=\fP 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\&.
.sp
Bei der Verwendung in Verbindung mit \fIAfter=\fP auf die gleiche Unit ist das
Verhalten von \fIBindsTo=\fP 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 nicht erfüllten Bedingungsprüfung (wie \fIConditionPathExists=\fP,
\fIConditionPathIsSymbolicLink=\fP, … \en siehe unten) übersprungen wird,
gestoppt wird, sollte sie laufen\&. Daher ist es in vielen Fällen am besten,
\fIBindsTo=\fP mit \fIAfter=\fP zu kombinieren\&.
.sp
Wenn \fIBindsTo=b\&.service\fP auf a\&.service  benutzt wird, wird diese
Abhängigkeit als \fIBoundBy=a\&.service\fP in der Eigenschaftsliste von
b\&.service angezeigt\&. \fIBoundBy=\fP\-Abhängigkeiten können nicht direkt
festgelegt werden\&.
.sp
Hinzugefügt in Version 201\&.
.RE
.PP
\fIPartOf=\fP
.RS 4
Konfiguriert Abhängigkeiten ähnlich zu \fIRequires=\fP, 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 \(em
Änderungen an dieser Unit betreffen nicht die aufgeführten Units\&.
.sp
Wenn \fIPartOf=b\&.service\fP auf a\&.service  benutzt wird, wird diese
Abhängigkeit als \fIConsistsOf=a\&.service\fP in der Eigenschaftsliste von
b\&.service angezeigt\&. \fIConsistsOf=\fP\-Abhängigkeiten können nicht direkt
festgelegt werden\&.
.sp
Hinzugefügt in Version 201\&.
.RE
.PP
\fIUpholds=\fP
.RS 4
Konfiguriert Abhängigkeiten ähnlich wie \fIWants=\fP, aber alle in \fIUpholds=\fP
aufgeführten Units starten immer, wenn sie als inaktiv oder fehlgeschlagen
erkannt werden und für sie kein Auftrag in der Warteschlange ist so lange
diese Unit aktiv ist\&. Während eine Abhängigkeit \fIWants=\fP auf eine andere
Unit eine einmalige Auswirkung hat, wenn diese Unit gestartet wird, hat eine
Abhängigkeit \fIUpholds=\fP eine dauerhafte Auswirkung, fortwährend die Unit
neustartend, falls notwendig\&. Dies ist eine Alternative zu der Einstellung
\fIRestart=\fP von Dienste\-Units, um sicherzustellen, dass sie am Laufen
gehalten werden, was auch immer passiert\&. Der Neustart passiert ohne
Verzögerung und die gewöhnlichen Unit\-abhängigen Ratenbegrenzungen gelten\&.
.sp
Wenn \fIUpholds=b\&.service\fP auf a\&.service  benutzt wird, wird diese
Abhängigkeit als \fIUpheldBy=a\&.service\fP in der Eigenschaftsliste von
b\&.service angezeigt\&.
.sp
Hinzugefügt in Version 249\&.
.RE
.PP
\fIConflicts=\fP
.RS 4
Eine Leerraum\-getrennte Liste von Unit\-Namen\&. Konfiguriert negative
Anforderungsabhängigkeiten\&. Falls eine Unit eine Einstellung \fIConflicts=\fP
auf eine andere Unit hat, wird das Starten ersterer die letzere stoppen und
umgekehrt\&.
.sp
Beachten Sie, dass diese Einstellung keine Ordnungsabhängigkeit impliziert,
ähnlich der vorher beschriebenen Abhängigkeiten \fIWants=\fP und
\fIRequires=\fP\&. Das bedeutet, dass eine Abhängigkeit \fIAfter=\fP oder
\fIBefore=\fP erklärt werden muss, um sicherzustellen, dass die in Konflikt
stehende Unit gestoppt wird, bevor die andere Unit gestartet wird\&. Es
spielt keine Rolle, welche der Ordnungsabhängigkeiten verwandt wird, da
Stopp\-Aufträge immer vor Start\-Aufträgen sortiert werden, siehe die
nachfolgende Diskussion von \fIBefore=\fP/\fIAfter=\fP\&.
.sp
Falls Unit A, die in Konflikt zu Unit B steht, zum gleichzeitigen Start mit
B eingeplant ist, wird die Transaktion entweder fehlschlagen (falls beide
benötigte Teile der Transaktion sind) oder so verändert, dass dies behoben
wird (falls eine oder beide Aufträge ein nicht benötigter Teil der
Transaktion sind)\&. In letzterem Fall wird der Auftrag, der nicht benötigt
ist, entfernt, oder falls beide nicht benötigt werden, wird die den Konflikt
auslösende Unit gestartet und die in Konflikt stehende gestoppt\&.
.sp
Hinzugefügt in Version 201\&.
.RE
.PP
\fIBefore=\fP, \fIAfter=\fP
.RS 4
Diese beiden Einstellungen erwarten eine Leerraum\-getrennte Liste von
Unit\-Namen\&. Sie können mehrfach angegeben werden, wodurch Abhängigkeiten
für alle aufgeführten Namen erstellt werden\&.
.sp
Diese zwei Einstellungen konfigurieren Ordnungsabhängigkeiten zwischen
Units\&. Falls Unit foo\&.service die Einstellung \fBBefore=bar\&.service\fP
enthält und beide Units gestartet werden, wird das Starten von bar\&.service
verzögert, bis der Start von foo\&.service abgeschlossen ist\&.\fIAfter=\fP ist
das Inverse von \fIBefore=\fP, d\&.h\&. während \fIBefore=\fP sicherstellt, dass
die konfigurierte Unit gestartet wird, bevor die aufgeführten Unit mit dem
Starten beginnt, stellt \fIAfter=\fP das Gegenteil sicher, dass die aufgeführte
Unit vollständig gestartet ist, bevor die konfigurierte Unit gestartet
wird\&.
.sp
Beim Herunterfahren von zwei Units, zwischen denen eine Ordnungsabhängigkeit
besteht, das Inverse der Start\-Reihenfolge angewandt wird\&. Dies bedeutet,
falls eine Unit mit \fIAfter=\fP 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 \fIAfter=\fP oder \fIBefore=\fP 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
\fIBefore=\fP/\fIAfter=\fP als abgeschlossen betrachtet wird, wenn alle ihre
konfigurierten Startbefehle aufgerufen wurden und entweder fehlschlugen oder
Erfolg meldeten\&. Beachten Sie, dass dies \fIExecStartPost\fP einschließt
(oder \fIExecStopPost\fP für den Herunterfahr\-Fall)\&.
.sp
Beachten Sie, dass diese Einstellungen unabhängig von und orthogonal zu den
mit \fIRequires=\fP, \fIWants=\fP, \fIRequisite=\fP oder \fIBindsTo=\fP konfigurierten
Anforderungsabhängigkeit sind\&. Es ist ein häufiges Muster, einen
Unit\-Namen sowohl in die Optionen \fIAfter=\fP als auch in \fIWantWants=\fP
aufzunehmen; in diesem Fall wird die aufgeführte Unit vor der Unit, die mit
diesen Optionen konfiguriert ist, gestartet\&.
.sp
Beachten Sie, dass \fIBefore=\fP\-Abhängigkeiten für Geräte\-Units nicht wirksam
sind und nicht unterstützt werden\&. Geräte werden im Allgemeinen aufgrund
externer Einsteck\-Ereignisse verfügbar und Systemd erstellt die
entsprechende Geräte\-Unit unverzüglich\&.
.sp
Hinzugefügt in Version 201\&.
.RE
.PP
\fIOnFailure=\fP
.RS 4
Eine Leerraum\-getrennte Liste einer oder mehrerer Units, die aktiviert
werden, wenn diese Unit den Zustand »failed« einnimmt\&.
.sp
Hinzugefügt in Version 201\&.
.RE
.PP
\fIOnSuccess=\fP
.RS 4
Eine Leerraum\-getrennte Liste einer oder mehrerer Units, die aktiviert
werden, wenn diese Unit den Zustand »inactive« einnimmt\&.
.sp
Hinzugefügt in Version 249\&.
.RE
.PP
\fIPropagatesReloadTo=\fP, \fIReloadPropagatedFrom=\fP
.RS 4
Eine Leerraum\-getrennte Liste einer oder mehrerer Units, an die
Neuladeanforderungen ausgebreitet werden sollen bzw. Units, von denen
Neuladeanforderungen an diese Unit ausgebereitet werden sollen\&. Erteilen
einer Neuladeanforderung an eine Unit, wird auch eine Neuladeanforderungen
an alle Units, die mittels dieser zwei Einstellungen damit verlinkt sind, in
die Warteschlange einstellen\&.
.sp
Hinzugefügt in Version 201\&.
.RE
.PP
\fIPropagatesStopTo=\fP, \fIStopPropagatedFrom=\fP
.RS 4
Eine Leerraum\-getrennte Liste einer oder mehrerer Units, an die
Stop\-Aufforderungen ausgebreitet werden sollen bzw. Units, von denen
Stop\-Aufforderungen an diese Unit ausgebereitet werden sollen\&. Erteilen
einer Stop\-Aufforderungen an eine Unit, wird auch eine Stop\-Aufforderungen
an alle Units, die mittels dieser zwei Einstellungen damit verlinkt sind, in
die Warteschlange einstellen\&.
.sp
Hinzugefügt in Version 249\&.
.RE
.PP
\fIJoinsNamespaceOf=\fP
.RS 4
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\&. Falls dies für eine Unit festgelegt ist
(beispielsweise enthält a\&.service \fIJoinsNamespaceOf=b\&.service\fP), dann
wird die inverse Abhängigkeit (\fIJoinsNamespaceOf=a\&.service\fP für
b\&.service) impliziert\&. Dies gilt nur für Unit\-Typen, die die Anweisungen
\fIPrivateNetwork=\fP, \fINetworkNamespacePath=\fP\fIPrivateIPC=\fP,
\fIIPCNamespacePath=\fP und \fIPrivateTmp=\fP unterstützen (siehe
\fBsystemd.exec\fP(5) für Details)\&. Falls eine Unit, die diese Einstellung
hat, gestartet wird, werden deren Prozesse die gleichen /tmp/\-, /var/tmp/\-,
IPC\- und Netzwerk\-Namensräume wie die aufgeführte gestartete Unit
haben\&. Falls mehrere aufgeführte Units bereits gestartet sind und sie sich
keinen Namensraum teilen, ist nicht definiert, welchem Namensraum
beigetreten wird\&. Beachten Sie, dass diese Einstellung nur Wirkung zeigt,
falls \fIPrivateNetwork=\fP/\fINetworkNamespacePath=\fP,
\fIPrivateIPC=\fP/\fIIPCNamespacePath=\fP und/oder \fIPrivateTmp=\fP für sowohl die
Unit, die dem Namensraum beitritt, als auch die Unit, deren Namensraum
beigetreten wird, aktiviert ist\&.
.sp
Hinzugefügt in Version 209\&.
.RE
.PP
\fIRequiresMountsFor=\fP
.RS 4
Akzeptiert eine Leerraum\-getrennte Liste absoluter Pfade\&. Fügt automatisch
Abhängigkeiten vom Typ \fIRequires=\fP und \fIAfter=\fP für alle für den Zugriff
auf den angegebenen Pfad benötigten Einhänge\-Units hinzu\&.
.sp
Mit \fBnoauto\fP 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\&.
.sp
Hinzugefügt in Version 201\&.
.RE
.PP
\fIOnSuccessJobMode=\fP, \fIOnFailureJobMode=\fP
.RS 4
Akzeptiert einen Wert aus »fail«, »replace«, »replace\-irreversibly«,
»isolate«, »flush«, »ignore\-dependencies«,
»ignore\-requirements«\&. Standardmäßig »replace«\&. Gibt an, wie die in
\fIOnSuccess=\fP/\fIOnFailure=\fP aufgeführten Units in die Warteschlange
eingestellt werden\&. Siehe die Option \fB\-\-job\-mode=\fP von \fBsystemctl\fP(1)
für Details über die möglichen Werte\&. Falls dies auf »isolate« gesetzt
ist, darf in \fIOnSuccess=\fP/\fIOnFailure=\fP nur eine einzelne Unit aufgeführt
werden\&.
.sp
Hinzugefügt in Version 209\&.
.RE
.PP
\fIIgnoreOnIsolate=\fP
.RS 4
Akzeptiert ein logisches Argument\&. Falls \fBtrue\fP, wird die Unit nicht
gestoppt, wenn eine andere Unit isoliert wird\&. Standardmäßig \fBfalse\fP für
Dienste\-, Ziel\-, Socket\-, Timer\- und Pfad\-Units und \fBtrue\fP für Scheiben\-,
Bereichs\-, Geräte\-, Swap\-, Einhänge\- und Automount\-Units\&.
.sp
Hinzugefügt in Version 201\&.
.RE
.PP
\fIStopWhenUnneeded=\fP
.RS 4
Akzeptiert ein logisches Argument\&. Falls \fBtrue\fP, 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 \fBfalse\fP\&.
.sp
Hinzugefügt in Version 201\&.
.RE
.PP
\fIRefuseManualStart=\fP, \fIRefuseManualStop=\fP
.RS 4
Akzeptiert ein logisches Argument\&. Falls \fBtrue\fP, 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 \fBfalse\fP\&.
.sp
Hinzugefügt in Version 201\&.
.RE
.PP
\fIAllowIsolate=\fP
.RS 4
Akzeptiert ein logisches Argument\&. Falls \fBtrue\fP, darf diese Unit mit dem
Befehl \fBsystemctl isolate\fP 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 \fBfalse\fP\&.
.sp
Hinzugefügt in Version 201\&.
.RE
.PP
\fIDefaultDependencies=\fP
.RS 4
Akzeptiert ein logisches Argument\&. Falls \fByes\fP (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 \fBno\fP setzen\&. Es wird
nachdrücklich empfohlen, diese Option für den Großteil der häufigen Units
aktiviert zu lassen\&. Falls auf \fBno\fP gesetzt, deaktiviert diese Option
nicht alle impliziten Abhängigkeiten, sondern nur nicht essenzielle\&.
.sp
Hinzugefügt in Version 201\&.
.RE
.PP
\fISurviveFinalKillSignal=\fP
.RS 4
Akzeptiert ein logisches Argument\&. Standardmäßig \fBno\fP\&. Falls \fByes\fP,
werden Prozessen, die zu dieser Unit gehören, nicht die abschließende
Signale »SIGTERM« und »SIGKILL« während der abschließenden Herunterfahrphase
des Systems gesandt\&. Diese Funktionalität ersetzt den älteren Mechanismus,
der es einem Programm erlaubte, wie in \m[blue]\fBSystemd\- und Speicher\-Daemons für das Wurzeldateisystem\fP\m[]\&\s-2\u[2]\d\s+2 beschrieben
»argv[0][0] = \*(Aq@\*(Aq« zu setzen\&. Letzerer Mechanismus wird allerdings
weiterhin unterstützt\&.
.sp
Hinzugefügt in Version 255\&.
.RE
.PP
\fICollectMode=\fP
.RS 4
Optimiert den Algorithmus der »Müllabfuhr« für diese Unit\&. Akzeptiert
entweder \fBinactive\fP oder \fBinactive\-or\-failed\fP\&. Falls auf \fBinactive\fP
gesetzt, wird die Unit entladen, falls sie im Zustand \fBinactive\fP ist und
von keinen Clients, Aufträgen oder anderen Units referenziert wird;
allerdings wird sie nicht entladen, wenn sie im Modus \fBfailed\fP ist\&. Im
Modus \fBfailed\fP werden fehlgeschlagene Units nicht entladen, bis der
Benutzer \fBsystemctl reset\-failed\fP oder einen äquivalenten Befehl auf ihnen
aufruft, um den Zustand \fBfailed\fP zurückzusetzen\&. Dieses Verhalten wird
geändert, falls die Option auf \fBinactive\-or\-failed\fP gesetzt wird: in diesem
Fall wird die Unit entladen, selbst falls die Unit im Zustand \fBfailed\fP ist
und daher ist ein explizites Zurücksetzen des Zustands \fBfailed\fP 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
\fBinactive\fP\&.
.sp
Hinzugefügt in Version 236\&.
.RE
.PP
\fIFailureAction=\fP, \fISuccessAction=\fP
.RS 4
Konfiguriert die durchzuführende Aktion, wenn die Unit stoppt und in einen
Fehlzustand oder inaktiven Zustand eintritt\&. Akzeptiert entweder \fBnone\fP,
\fBreboot\fP, \fBreboot\-force\fP, \fBreboot\-immediate\fP, \fBpoweroff\fP,
\fBpoweroff\-force\fP, \fBpoweroff\-immediate\fP, \fBexit\fP, \fBexit\-force\fP,
\fBsoft\-reboot\fP, \fBsoft\-reboot\-force\fP, \fBkexec\fP, \fBkexec\-force\fP, \fBhalt\fP,
\fBhalt\-force\fP und \fBhalt\-immediate\fP\&. Im Systemmodus sind alle Optionen
erlaubt\&. Im Benutzermodus sind nur \fBnone\fP, \fBexit\fP, \fBexit\-force\fP,
\fBsoft\-reboot\fP und \fBsoft\-reboot\-force\fP erlaubt\&. Beide Optionen sind
standardmäßig \fBnone\fP\&.
.sp
Falls \fBnone\fP gesetzt ist, wird keine Aktion ausgelöst\&. \fBreboot\fP
verursacht einen Neustart nach der normalen Herunterfahrprozedur
(d\&.h\&. äquivalent zu \fBsystemctl reboot\fP)\&. \fBreboot\-force\fP führt zu
einem erzwungenen Neustart, der alle Prozesse zwangsweise beenden wird, aber
beim Neustart kein unsauberes Dateisystem erzeugen sollte
(d\&.h\&. äquivalent zu \fBsystemctl reboot \-f\fP) und \fBreboot\-immediate\fP
führt zu einer sofortigen Ausführung des Systemaufrufs \fBreboot\fP(2), was zu
Datenverlust führen kann (d\&.h\&. äquivalent zu \fBsystemctl reboot \-ff\fP)\&. Ähnlich haben \fBpoweroff\fP, \fBpoweroff\-force\fP,
\fBpoweroff\-immediate\fP, \fBkexec\fP, \fBkexec\-force\fP, \fBhalt\fP, \fBhalt\-force\fP und
\fBhalt\-immediate\fP die Wirkung des Herunterfahrens des Systems bzw. der
Ausführung von Kexec und Anhalten des Systems mit ähnlichen
Semantiken\&. \fBexit\fP führt dazu, dass sich der Verwalter beendet, wobei er
der normalen Herunterfahrprozedur folgt, und \fBexit\-force\fP führt dazu, dass
er sich ohne Herunterfahren der Dienste beendet\&. Wenn \fBexit\fP oder
\fBexit\-force\fP verwandt werden, wird standardmäßig der Exit\-Status des
Hauptprozesses der Unit (falls dies zutrifft) vom Diensteverwalter
zurückgeliefert\&. Dies kann allerdings mit
\fIFailureActionExitStatus=\fP/\fISuccessActionExitStatus=\fP außer Kraft gesetzt
werden, siehe unten\&. \fBsoft\-reboot\fP wird eine Neustartkaktion im
Anwendungsraum auslösen\&. \fBsoft\-reboot\-force\fP macht dies auch, aber
durchläuft vorher die Herunterfahrtransaktion nicht\&.
.sp
Hinzugefügt in Version 236\&.
.RE
.PP
\fIFailureActionExitStatus=\fP, \fISuccessActionExitStatus=\fP
.RS 4
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
\fIFailureAction=\fP/\fISuccessAction=\fP auf \fBexit\fP oder \fBexit\-force\fP 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\&.
.sp
Hinzugefügt in Version 240\&.
.RE
.PP
\fIJobTimeoutSec=\fP, \fIJobRunningTimeoutSec=\fP
.RS 4
\fIJobTimeoutSec=\fP legt eine Zeitüberschreitung für den gesamten Auftrag
fest, dessen Ausführung beginnt, wenn der Auftrag in die Warteschlange
eingereiht wird\&. \fIJobRunningTimeoutSec=\fP legt eine Zeitüberschreitung
fest, dessen Ausführung beginnt, wenn der Auftrag in der Warteschlange
tatsächlich gestartet wird\&. Falls eine der beiden Begrenzungen erreicht
wird, wird der Auftrag abgebrochen, die Unit wird allerdings ihren Zustand
weder ändern noch in den Modus »failed« eintreten\&.
.sp
Beide Einstellungen akzeptieren eine Zeitdauer mit der Vorgabeeinheit
Sekunden, aber andere Einheiten können angegeben werden, siehe
\fBsystemd.time\fP(5)\&. Die Vorgabe ist »infinity«
(Auftragszeitüberschreitungen sind deaktiviert), außer für Geräte\-Units, bei
denen standardmäßig \fIJobRunningTimeoutSec=\fP auf \fIDefaultDeviceTimeoutSec=\fP
gesetzt ist\&.
.sp
Hinweis: Diese Zeitüberschreitungen sind unabhängig von allen
Unit\-spezifischen Zeitüberschreitungen (beispielsweise den mit
\fITimeoutStartSec=\fP in Dienste\-Units gesetzten Zeitüberschreitungen)\&. Die
Auftragszeitüberschreitung hat keine Wirkung für die Unit selbst\&. Oder mit
anderen Worten: Unit\-spezifische Zeitüberschreitungen sind nützlich, um
Zustandsänderungen von Units abzubrechen und sie zurückzunehmen\&. Die mit
dieser Option gesetzten Auftrags\-Zeitüberschreitungen sind allerdings nur
nützlich, um den Auftrag abzubrechen, der darauf wartet, dass die Unit den
Zustand ändert\&.
.sp
Hinzugefügt in Version 201\&.
.RE
.PP
\fIJobTimeoutAction=\fP, \fIJobTimeoutRebootArgument=\fP
.RS 4
\fIJobTimeoutAction=\fP konfiguriert optional eine zusätzliche Aktion, die beim
Erreichen der Zeitüberschreitung unternommen werden soll, siehe die
Beschreibung von \fIJobTimeoutSec=\fP und \fIJobRunningTimeoutSec=\fP oben\&. Es
akzeptiert die gleichen Werte wie \fIStartLimitAction=\fP\&. Standardmäßig
\fBnone\fP\&.
.sp
\fIJobTimeoutRebootArgument=\fP konfiguriert eine optionale
Neustartzeichenkette, die an den Systemaufruf \fBreboot\fP(2) übergeben wird\&.
.sp
Hinzugefügt in Version 240\&.
.RE
.PP
\fIStartLimitIntervalSec=\fP\fIIntervall\fP, \fIStartLimitBurst=\fP\fIHäufung\fP
.RS 4
Konfiguriert die Unit\-Startraten\-Begrenzung\&. Units, die häufiger als
\fIHäufung\fP innherhalb der Zeitdauer \fIIntervall\fP gestartet werden, wird kein
weiterer Start erlaubt\&. Verwenden Sie \fIStartLimitIntervalSec=\fP, um das
Überprüfungsintervall zu konfigurieren und \fIStartLimitBurst=\fP, um zu
konfigurieren, wie viele Starts pro Intervall erlaubt sind\&.
.sp
\fIIntervall\fP ist eine Zeitdauer in der Standardeinheit Sekunden, aber andere
Einheiten können angegeben werden, siehe \fBsystemd.time\fP(5)\&. Der besondere
Wert »infinity« kann zur Begrenzung der Gesamtanzahl an Startversuchen
verwandt werden, selbst wenn diese in großen Zeitintervallen
passieren\&. Standardmäßig \fIDefaultStartLimitIntervalSec=\fP in der
Verwalterkonfigurationsdatei und kann auf 0 gesetzt werden, um jegliche Art
von Ratenbegrenzung zu deaktivieren\&. \fIHäufung\fP ist eine Zahl, die in der
Verwalterkonfigurationsdatei standardmäßig \fIDefaultStartLimitBurst=\fP ist\&.
.sp
Diese Konfigurationsoptionen sind insbesondere im Zusammenspiel mit der
Diensteeinstellung \fIRestart=\fP nützlich (siehe \fBsystemd.service\fP(5));
allerdings gelten sie für alle Arten von Starts (einschließlich manueller),
nicht nur denen, die von der \fIRestart=\fP\-Logik ausgelöst werden\&.
.sp
Beachten Sie, dass nicht versucht wird, Units, die für \fIRestart=\fP
konfiguriert ist und die die Startbegrenzung erreichen, weiterhin zu
starten; allerdings können sie zu einem späteren Zeitpunkt noch manuell oder
von einem Timer oder Socket gestartet werden, nachdem das \fIIntervall\fP
abgelaufen ist\&. Von diesem Zeitpunkt an ist die Neustartlogik wieder
aktiviert\&. \fBsystemctl reset\-failed\fP führt dazu, dass der
Neustartratenzähler für einen Dienst gelöscht wird, was nützlich ist, wenn
der Administrator eine Unit manuell starten möchte und die Startbegrenzung
damit in die Quere kommt\&. Ratenbegrenzung wird durchgesetzt, nachdem alle
Unit\-Bedingungsprüfungen ausgeführt wurden\&. Daher zählen für die
Ratenbegrenzung Unit\-Aktivierungen mit fehlgeschlagenen Bedingungen nicht
mit\&.
.sp
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\&.
.sp
Diese Einstellung gilt nicht für Scheiben\-, Ziel\-, Geräte\- und
Bereichs\-Units, da dies Unit\-Typen sind, deren Aktivierung entweder nie
fehlschlagen oder nur ein einziges Mal erfolgreich sein darf\&.
.sp
Hinzugefügt in Version 229\&.
.RE
.PP
\fIStartLimitAction=\fP
.RS 4
Konfiguriert eine zusätzliche Aktion, die ergriffen werden soll, falls die
mit \fIStartLimitIntervalSec=\fP und \fIStartLimitBurst=\fP konfigurierte
Ratenbegrenzung erreicht wird\&. Akzeptiert die gleichen Werte wie die
Einstellungen \fIFailureAction=\fP/\fISuccessAction=\fP\&. Falls \fBnone\fP gesetzt
ist, wird das Erreichen der Ratenbegrenzung keine Aktion auslösen, außer das
der Start nicht erlaubt wird\&. Standardmäßig \fBnone\fP\&.
.sp
Hinzugefügt in Version 229\&.
.RE
.PP
\fIRebootArgument=\fP
.RS 4
Konfiguriert das globale Argument für den Systemaufruf \fBreboot\fP(2), falls
\fIStartLimitAction=\fP oder \fIFailureAction=\fP eine Neustartaktion ist\&. Dies
funktioniert genauso wie das optionale Argument für den Befehl \fBsystemctl reboot\fP\&.
.sp
Hinzugefügt in Version 229\&.
.RE
.PP
\fISourcePath=\fP
.RS 4
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\&.
.sp
Hinzugefügt in Version 201\&.
.RE
.SS "Bedingungen und Zusicherungen"
.PP
Unit\-Dateien können auch eine Reihe von \fIBedingung…=\fP\- und
\fIZusicherung…=\fP\-Einstellungen enthalten\&. Bevor die Unit gestartet wird,
wird Systemd nachweisen, dass die festgelegten Bedingungen und Zusicherungen
wahr sind\&. Falls nicht, wird das Starten der Unit (fast ohne Ausgabe)
übersprungen (im Falle von Bedingungen) oder mit einer Fehlermeldung
abgebrochen (im Falle von Zusicherungen)\&. Fehlschlagende Bedingungen oder
Zusicherungen führen nicht dazu, dass die Unit in den Zustand »failed«
überführt wird\&. Die Bedingungen und Zusicherungen werden zum Zeitpunkt
überprüft, zu dem der Start\-Auftrag in der Warteschlange ausgeführt
wird\&. Die Ordnungsabhängigkeiten werden weiterhin berücksichtigt, so dass
andere Units weiterhin hereingezogen und einsortiert werden, als ob die Unit
erfolgreich aktiviert worden wäre und die Bedingungen und Zusicherungen
werden zu dem genauen Moment ausgeführt, zu dem die Unit normalerweise
starten würde und kann daher den Systemzustand nach den einsortierten Units
und vor Abschluss der Initialisierung validieren\&. Verwenden Sie
Bedingungsausdrücke, um Units zu überspringen, die auf dem lokalen System
nicht zutreffen, beispielsweise da der Kernel oder die Laufzeitumgebung ihre
Funktionalität nicht benötigt\&.
.PP
Falls mehrere Bedingungen festgelegt sind, wird die Unit ausgeführt, falls
alle von ihnen zutreffen (d\&.h\&. es wird ein logisches UND
angewandt)\&. Den Bedingungsprüfungen kann ein Pipe\-Symbol (|) nach dem
Gleichheitszeichen verwendet (»Bedingung…=!…«) werden, was dazu führt, dass
die Bedingung eine \fIauslösende\fP Bedingung wird\&. Falls für eine Unit
mindestens eine auslösende Bedingung definiert ist, dann wird die Unit
gestartet, falls mindestens eine der auslösenden Bedingungen und alle der
regulären (d\&.h\&. nicht auslösenden) Bedingungen zutreffen\&. Falls Sie
einem Argument das Pipe\-Symbol und ein Ausrufezeichen voranstellen, muss das
Pipe\-Symbol zuerst und das Ausrufezeichen als zweites übergeben
werden\&. Falls einer der Optionen die leere Zeichenkette zugewiesen wird,
wird die Liste der Bedingungen komplett zurückgesetzt und alle
vorhergehenden Bedingungseinstellungen (jeder Art) werden keine Wirkung
haben\&.
.PP
Die Optionen \fIAssertArchitecture=\fP, \fIAssertVirtualization=\fP, … sind zu
Bedingungen ähnlich, führen aber dazu, dass Aufträge fehlschlagen (statt
übersprungen zu werden)\&. Die fehlgeschlagene Prüfung wird
protokolliert\&. Units mit nicht zutreffenden Bedingungen werden als in
einem sauberen Zustand betrachtet und der Speicher wird aufgeräumt, falls
sie nicht referenziert werden\&. Dies bedeutet, dass bei Abfragen die
Fehlerbedingung im Zustand der Unit angezeigt werden könnte oder auch
nicht\&.
.PP
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\&.
.PP
Der Unterbefehl \fBcondition\fP aus \fBsystemd\-analyze\fP(1) kann zum Testen von
Bedingungen und Zusicherungsausdrücken verwandt werden\&.
.PP
Außer für \fIConditionPathIsSymbolicLink=\fP folgen alle Pfadprüfungen
Symlinks\&.
.PP
\fIConditionArchitecture=\fP
.RS 4
Prüft, ob das System auf einer bestimmten Architektur läuft\&. Akzeptiert
einen aus »x86«, »x86\-64«, »ppc«, »ppc\-le«, »ppc64«, »ppc64\-le«, »ia64«,
»parisc«, »parisc64«, »s390«, »s390x«, »sparc«, »sparc64«, »mips«,
»mips\-le«, »mips64«, »mips64\-le«, »alpha«, »arm«, »arm\-be«, »arm64«,
»arm64\-be«, »sh«, »sh64«, »m68k«, »tilegx«, »cris«, »arc«, »arc\-be« oder
»native«\&.
.sp
Die Architektur wird aus der durch \fBuname\fP(2) zurückgelieferten Information
bestimmt und unterliegt daher \fBpersonality\fP(2)\&. Beachten Sie, dass eine
Einstellung \fIPersonality=\fP 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\&.
.sp
Hinzugefügt in Version 201\&.
.RE
.PP
\fIConditionFirmware=\fP
.RS 4
Prüft, ob die Firmware des Systems von einem bestimmten Typ ist\&. Die
folgenden Werte sind möglich:
.sp
.RS 4
.ie  n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
»uefi« passt auf Systeme mit EFI\&.
.RE
.sp
.RS 4
.ie  n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
»device\-tree« passt auf Systeme mit einem Devicetree\&.
.RE
.sp
.RS 4
.ie  n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
»device\-tree\-compatible(\fIWert\fP)« passt auf Systeme mit einem Devicetree,
die kompatibel mit »Wert« sind\&.
.RE
.sp
.RS 4
.ie  n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
»smbios\-field(\fIFeld\fP \fIOperator\fP \fIWert\fP)« passt auf Systeme mit einem
SMBIOS\-Feld, das einen bestimmten Wert enthält\&. \fIFeld\fP ist der Name eines
SMBIOS\-Feldes, das als »sysfs«\-Attributsdatei unterhalb von
/sys/class/dmi/id/ offengelegt wird\&. \fIOperator\fP ist einer aus »<«,
»<=«, »>=«, »>«, »==«, »<>« zum Versionsvergleich, »=«
und »!=« für wörtlichen Zeichenkettenvergleich oder »$=«, »!$=« für
Shell\-artigen Glob\-Vergleich\&. \fIWert\fP ist der erwartete Wert des
SMBIOS\-Feldes (möglicherweise enthält er Shell\-artige Globs, falls
»$="/"!$=« verwandt wird\&.
.RE
.sp
Hinzugefügt in Version 249\&.
.RE
.PP
\fIConditionVirtualization=\fP
.RS 4
Prüft, ob das System in einer virtualisierten Umgebung ausgeführt wird und
testet optional, ob es eine bestimmte Implementierung ist\&. Akzeptiert
entweder einen logischen Wert, um zu prüfen, ob es in einer virtualisierten
Umgebung ausgeführt wird oder entweder »vm« oder »container«, um gegen eine
generische Art von Virtualisierungslösung zu prüfen oder einen aus »qemu«,
»kvm«, »amazon«, »zvm«, »vmware«, »microsoft«, »oracle«, »powervm«, »xen«,
»bochs«, »uml«, »bhyve«, »qnx«, »apple«, »sre«, »openvz«, »lxc«,
»lxc\-libvirt«, »systemd\-nspawn«, »docker«, »podman«, »rkt«, »wsl«, »proot«,
»pouch«, »acrn«, um gegen eine bestimmte Implementierung zu prüfen oder
»private\-users«, um zu prüfen, ob das System in einem Benutzernamensraum
läuft\&. Siehe \fBsystemd\-detect\-virt\fP(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\&.
.sp
Hinzugefügt in Version 244\&.
.RE
.PP
\fIConditionHost=\fP
.RS 4
\fIConditionHost=\fP 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 \fBgethostname\fP(2)
zurückgeliefert wird, geprüft wird oder eine als Zeichenkette formatierte
Maschinenkennung (siehe \fBmachine\-id\fP(5))\&. Der Test kann durch
Voranstellung eines Ausrufezeichens negiert werden\&.
.sp
Hinzugefügt in Version 244\&.
.RE
.PP
\fIConditionKernelCommandLine=\fP
.RS 4
\fIConditionKernelCommandLine=\fP kann zur Prüfung, ob eine bestimmte
Kernelbefehlszeilenoption gesetzt ist (oder falls ein Ausrufezeichen
vorangestellt ist, nicht gesetzt ist) verwandt werden\&. Das Argument muss
entweder ein einzelnes Wort oder eine Zuweisung (d\&.h\&. zwei Worte,
getrennt durch »=«) sein\&. Im ersten Fall wird die Kernelbefehlszeile nach
Auftauchen des Wortes wie es ist oder als linke Seite einer Zuweisung
durchsucht\&. Im zweitem Fall wird nach der genauen Zuweisung geschaut,
wobei die rechte und die linke Seite passen müssen\&. Dies agiert auf der
Kernelbefehlszeile, die an die Anwendungsebene mittels /proc/cmdline
kommuniziert wird, außer wenn der Diensteverwalter als Nutzlast eines
Container\-Verwalters gestartet wird \- dann wird stattdessen die Befehlszeile
von PID 1 verwandt (d\&.h\&. /proc/1/cmdline)\&.
.sp
Hinzugefügt in Version 244\&.
.RE
.PP
\fIConditionKernelVersion=\fP
.RS 4
\fIConditionKernelVersion=\fP kann zur Prüfung, ob die Kernelversion (wie sie
durch \fBuname \-r\fP 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\&. Jeder Ausdruck beginnt mit einem aus »=« oder »!=« für
Zeichenkettenvergleiche, »<«, »<=«, »==«, »<>«, »>=«,
»>« für Versionsvergleiche oder »$=«, »!$=« für Shell\-artige
Glob\-Abgleiche\&. Falls kein Operator festgelegt ist, wird »$=«
impliziert\&.
.sp
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\&.
.sp
Hinzugefügt in Version 244\&.
.RE
.PP
\fIConditionCredential=\fP
.RS 4
\fIConditionCredential=\fP kann zum Prüfen, ob eine Zugangsberechtigung mit dem
festgelegten Namen in den Diensteverwalter übergeben wurde\&. Siehe
\m[blue]\fBSystem\- und Dienste\-Zugangsberechtigungen\fP\m[]\&\s-2\u[3]\d\s+2
für Details über Zugangsberechtigungen\&. Falls dies in Diensten für den
Systemdiensteverwalter verwandt wird, kann dies dazu verwendet werden,
Dienste abhängig von den hereingegebenen Zugangsberechtigungen zu
machen\&. Falls dies in Diensten für den benutzerbezogenen Diensteverwalter
verwandt wird, kann dies dazu verwendet werden, Dienste abhängig von den in
unit@\&.service\-Diensten, die zu dem Benutzer gehören, gegebenen
Zugangsberechtigungen zu machen\&. Das Argument muss ein gültiger
Zugangsberechtigungsname sein\&.
.sp
Hinzugefügt in Version 252\&.
.RE
.PP
\fIConditionEnvironment=\fP
.RS 4
\fIConditionEnvironment=\fP kann zur Überprüfung, ob eine bestimmte
Umgebungsvariable im Umgebungsblock des Diensteverwalters gesetzt
(bzw. nicht gesetzt, falls ein Ausführungszeichen vorangestellt wird)
ist\&. Das Argument kann ein einzelnes Wort sein, um zu prüfen, ob die
Variable mit diesem Namen im Umgebungsblock definiert ist, oder eine
Zuweisung (»\fIName\fP=\fIWert\fP«), um zu prüfen, ob die Variable mit genau
diesem Wert definiert ist\&. Beachten Sie, dass der Umgebungsblock des
Diensteverwalters selbst geprüft wird, d\&.h\&. keine mit (wie oben
beschrieben) \fIEnvironment=\fP oder \fIEnvironmentFile=\fP definierte
Variablen\&. Dies ist besonders nützlich, wenn der Diensteverwalter
innerhalb einer Container\-Umgebung oder als benutzerbezogener
Diensteverwalter läuft, um auf Variablen zu prüfen, die durch den
einschließenden Container\-Verwalter oder PAM übergeben wurden\&.
.sp
Hinzugefügt in Version 246\&.
.RE
.PP
\fIConditionSecurity=\fP
.RS 4
\fIConditionSecurity=\fP kann zur Prüfung, ob die übergebene Sicherheitstechnik
auf dem System aktiviert ist, verwandt werden\&. Derzeit werden die
folgenden Werte erkannten:
.sp
.it 1 an-trap
.nr an-no-space-flag 1
.nr an-break-flag 1
.br
\fBTabelle\ \&3.\ \& Erkannte Sicherheitstechniken\fP
.TS
allbox tab(:);
lB lB.
T{
Wert
T}:T{
Beschreibung
T}
.T&
l l
l l
l l
l l
l l
l l
l l
l l
l l
l l.
T{
selinux
T}:T{
SELinux MAC
T}
T{
apparmor
T}:T{
AppArmor MAC
T}
T{
tomoyo
T}:T{
Tomoyo MAC
T}
T{
smack
T}:T{
SMACK MAC
T}
T{
ima
T}:T{
Integritätsmessungsarchitektur (IMA)
T}
T{
audit
T}:T{
Linux\-Audit\-Rahmenwerk
T}
T{
uefi\-secureboot
T}:T{
Sicherer UEFI\-Systemstart
T}
T{
tpm2
T}:T{
Trusted Platform Module 2\&.0 (TPM2)
T}
T{
cvm
T}:T{
Vertrauenswürdige virtuelle Maschine (SEV/TDX)
T}
T{
measured\-uki
T}:T{
Vereinigtes Kernelabbild mit PCR\-11\-Messung, gemäß \fBsystemd\-stub\fP(7)\&. Hinzugefügt in Version 255\&.
T}
.TE
.sp 1
Der Test kann durch Voranstellung eines Ausrufezeichens negiert werden\&.
.sp
Hinzugefügt in Version 244\&.
.RE
.PP
\fIConditionCapability=\fP
.RS 4
Prüft, ob die übergebene Capability in der Capability\-Begrenzungsmenge des
Diensteverwalters existiert (d\&.h\&. dies prüft nicht, ob die Capability
tatsächlich in der erlaubten oder effektiven Menge verfügbar ist, siehe
\fBcapabilities\fP(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\&.
.sp
Hinzugefügt in Version 244\&.
.RE
.PP
\fIConditionACPower=\fP
.RS 4
Prüft, ob das System zum Zeitpunkt der Aktivierung der Unit am Netz hängt
oder ausschließlich über Akku läuft\&. Dies akzeptiert ein logisches
Argument\&. Falls auf »true« gesetzt, wird die Bedingung nur gelten, wenn
mindestens ein Netzstecker an einer Wechselstromquelle hängt oder falls
keine Wechselstromstecker bekannt sind\&. Umgekehrt, wenn auf »false«
gesetzt, wird die Bedingung nur gelten, falls mindestens ein
Wechselstromstecker bekannt ist und alle Wechselstromstecker von einer
Stromquelle abgetrennt sind\&.
.sp
Hinzugefügt in Version 244\&.
.RE
.PP
\fIConditionNeedsUpdate=\fP
.RS 4
Akzeptiert entweder /var/ oder /etc/ als Argument, möglicherweise mit
vorangestelltem »!« (zur Invertierung der Bedingung)\&. Diese Bedingung kann
eingesetzt werden, um Units davon abhängig zu machen, ob das angegebene
Verzeichnis einer Aktualisierung bedarf, da die Änderungszeit von /usr/
neuer als die Stempeldatei \&.updated in dem angegebenen Verzeichnis
ist\&. Dies ist nützlich, um Offline\-Aktualisierungen der
Betriebssystemressourcen des Lieferanten in /usr/ zu implementieren, die
Aktualisierungen von /etc/ oder /var/ beim nachfolgenden Systemstart
benötigen\&. Units, die von dieser Bedingung Gebrauch machen, sollten sich
vor \fBsystemd\-update\-done.service\fP(8) einordnen, um sicherzustellen, dass
sie ausgeführt werden, bevor die Änderungszeit der Stempeldatei
zurückgesetzt wird, wodurch eine abgeschlossene Aktualisierung angezeigt
wird\&.
.sp
Falls die Option \fIsystemd\&.condition\-needs\-update=\fP auf der
Kernelbefehlszeile angegeben ist (sie akzeptiert einen logischen Wert), wird
sie das Ergebnis dieser Zustandsüberprüfung außer Kraft setzen und Vorrang
vor allen Dateiänderungsprüfungen haben\&. Falls die
Kernelbefehlszeilenoption verwandt wird, wird systemd\-update\-done\&.service
keine direkte Auswirkung auf die nachfolgenden
\fIConditionNeedsUpdate=\fP\-Überprüfungen haben, bis das System neu gestartet
und dabei die Kernelbefehlszeilenoption nicht mehr angegeben wird\&.
.sp
Beachten Sie, dass der Zeitstempel von /usr/ ausdrücklich aktualisiert
werden sollte, nachdem die Inhalte verändert wurden, damit dieses Schema
wirksam wird\&. Der Kernel wird den Veränderungszeitstempel eines
Verzeichnisses nur automatisch aktualisieren, wenn direkt darunter liegende
Einträge eines Verzeichnisses verändert werden; eine Veränderung von
verschachtelten Dateien wird nicht automatisch dazu führen, dass die mtime
von /usr/ aktualisiert wird\&.
.sp
Beachten Sie auch, dass die Aktualisierungsmethode nicht den Zeitstempel von
/usr/ verändern sollte, wenn sie einen Aufruf enthält, nach der
Aktualisierung selbst geeignete Schritte auszuführen\&. In einem typischen
Paketierungsschema einer Distribution werden Pakete alle benötigten
Aktualisierungsschritte als Teil der Installation oder des Upgrades
durchführen, um die Paketinhalte sofort nutzbar zu
machen\&. \fIConditionNeedsUpdate=\fP sollte mit anderen
Aktualisierungsmechanismen verwandt werden, bei denen eine solche direkte
Aktualisierung nicht passiert\&.
.sp
Hinzugefügt in Version 244\&.
.RE
.PP
\fIConditionFirstBoot=\fP
.RS 4
Akzeptiert ein logisches Argument\&. Diese Bedingung kann eingesetzt werden,
um Units davon abhängig zu machen, ob das System erstmalig startet\&. Dies
bedeutet grob, dass /etc/ nicht bestückt war, als das System den Systemstart
begann (für Details, siehe »SEMANTIK BEIM ERSTEN SYSTEMSTART« in
\fBmachine\-id\fP(5))\&. Der erste Systemstart gilt als abgeschlassen (diese
Bedingung wird als falsch ausgewertet), nachdem der Verwalter die Startphase
abgeschlossen hat\&.
.sp
Diese Bedingung kann zum Befüllen von /etc/ beim ersten Systemstart nach
Rücksetzen auf Werkseinstellungen oder wenn eine neue Systeminstanz das
erste Mal einen Systemstart durchführt, verwandt werden\&.
.sp
Zur Robustheit sollten sich Units mit \fIConditionFirstBoot=yes\fP vor
first\-boot\-complete\&.target anordnen und dieses passive Ziel mit \fIWants=\fP
hereinziehen\&. Dies stellt sicher, dass bei einem abgebrochenen ersten
Systemstart die Units erneut beim nächsten Systemstart ausgeführt werden\&.
.sp
Falls die Option \fIsystemd\&.condition\-first\-boot=\fP auf der
Kernelbefehlszeile angegeben ist (sie akzeptiert einen logischen Wert), wird
sie das Ergebnis dieser Zustandsüberprüfung außer Kraft setzen und Vorrang
vor /etc/machine\-id\-Existenzprüfungen haben\&.
.sp
Hinzugefügt in Version 244\&.
.RE
.PP
\fIConditionPathExists=\fP
.RS 4
Prüft auf die Existenz einer Datei\&. Falls der angegebene absolute Pfadname
nicht existiert, wird die Bedingung fehlschlagen\&. Falls dem an
\fIConditionPathExists=\fP übergebenen absoluten Pfadnamen ein Ausrufezeichen
(»!«) vorangestellt wird, wird der Test negiert und die Unit nur gestartet,
falls der Pfadname nicht existiert\&.
.sp
Hinzugefügt in Version 244\&.
.RE
.PP
\fIConditionPathExistsGlob=\fP
.RS 4
\fIConditionPathExistsGlob=\fP ist zu \fIConditionPathExists=\fP ähnlich, prüft
aber auf die Existenz von mindestens einer Datei oder einem Verzeichnis, das
auf das angegebene Globbing\-Muster passt\&.
.sp
Hinzugefügt in Version 244\&.
.RE
.PP
\fIConditionPathIsDirectory=\fP
.RS 4
\fIConditionPathIsDirectory=\fP ist zu \fIConditionPathExists=\fP ähnlich,
überprüft aber, dass ein bestimmter Pfad existiert und ein Verzeichnis
ist\&.
.sp
Hinzugefügt in Version 244\&.
.RE
.PP
\fIConditionPathIsSymbolicLink=\fP
.RS 4
\fIConditionPathIsSymbolicLink=\fP ist zu \fIConditionPathExists=\fP ähnlich,
überprüft aber, dass ein bestimmter Pfad existiert und ein symbolischer Link
ist\&.
.sp
Hinzugefügt in Version 244\&.
.RE
.PP
\fIConditionPathIsMountPoint=\fP
.RS 4
\fIConditionPathIsMountPoint=\fP ist zu \fIConditionPathExists=\fP ähnlich,
überprüft aber, dass ein bestimmter Pfad existiert und ein Einhängepunkt
ist\&.
.sp
Hinzugefügt in Version 244\&.
.RE
.PP
\fIConditionPathIsReadWrite=\fP
.RS 4
\fIConditionPathIsReadWrite=\fP ist zu \fIConditionPathExists=\fP ähnlich,
überprüft aber, dass das zugrundeliegende Dateisystem les\- und schreibbar
ist (d\&.h\. nicht rein\-lesbar eingehängt ist)\&.
.sp
Hinzugefügt in Version 244\&.
.RE
.PP
\fIConditionPathIsEncrypted=\fP
.RS 4
\fIConditionPathIsEncrypted=\fP ist ähnlich zu \fIConditionPathExists=\fP,
überprüft aber, dass das dem Dateisystem zugrundeliegende Blockgerät mittels
dm\-crypt/LUKS verschlüsselt ist\&. Beachten Sie, dass diese Prüfung keine
verzeichnisbezogene Verschlüsselung bei Ext4 berücksichtigt und nur
Verschlüsselung auf Blockebene erkennt\&. Desweiteren wird nur die
Verschlüsselung oberhalb des Loopback\-Gerätes erkannt, falls der angegebene
Pfad sich auf einem Dateisystem oberhalb eines per Looback eingehängten
Gerätes befindet\&. Es wird nicht erkannt, ob das dem Loopback
zugrundeliegende Blockgerät verschlüsselt ist\&.
.sp
Hinzugefügt in Version 246\&.
.RE
.PP
\fIConditionDirectoryNotEmpty=\fP
.RS 4
\fIConditionDirectoryNotEmpty=\fP ist zu \fIConditionPathExists=\fP ähnlich,
überprüft aber, dass ein bestimmter Pfad existiert und ein nicht leeres
Verzeichnis ist\&.
.sp
Hinzugefügt in Version 244\&.
.RE
.PP
\fIConditionFileNotEmpty=\fP
.RS 4
\fIConditionFileNotEmpty=\fP ist zu \fIConditionPathExists=\fP ähnlich, überprüft
aber, dass ein bestimmter Pfad existiert und sich auf eine normale Datei mit
einer von Null verschiedenen Größe bezieht\&.
.sp
Hinzugefügt in Version 244\&.
.RE
.PP
\fIConditionFileIsExecutable=\fP
.RS 4
\fIConditionFileIsExecutable=\fP ist zu \fIConditionPathExists=\fP ähnlich,
überprüft aber, dass ein bestimmter Pfad existiert und sich auf eine
normale, als ausführbar gekennzeichnete Datei bezieht\&.
.sp
Hinzugefügt in Version 244\&.
.RE
.PP
\fIConditionUser=\fP
.RS 4
\fIConditionUser=\fP 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\&.
.sp
Hinzugefügt in Version 244\&.
.RE
.PP
\fIConditionGroup=\fP
.RS 4
\fIConditionGroup=\fP ist zu \fIConditionUser=\fP ähnlich, überprüft aber, ob die
reale oder effektive Gruppe des Diensteverwalters oder jeder seiner
Hilfsgruppen auf die angegebene Gruppe oder GID passt\&. Diese Einstellung
unterstützt den besonderen Wert »@system« nicht\&.
.sp
Hinzugefügt in Version 244\&.
.RE
.PP
\fIConditionControlGroupController=\fP
.RS 4
Prüft, ob übergebene Cgroup\-Controller (z\.B\&. »cpu«) für die Verwendung
auf dem System verfügbar sind oder ob die veraltete V1\-Cgroup\- oder die
moderne V2\-Cgroup\-Hierarchie verwandt wird\&.
.sp
Durch Leerzeichen getrennt können mehrere Controller übergeben werden; in
diesem Fall wird die Bedingung nur zutreffen, falls alle aufgeführten
Controller zur Verwendung verfügbar sind\&. Dem System unbekannte Controller
werden ignoriert\&. Gültige Controller sind »cpu«, »io«, »memory« und
»pids«\&. Selbst falls er im Kernel verfügbar ist, kann ein bestimmter
Controller nicht verfügbar sein, falls er auf der Kernel\-Befehlszeile wie
folgt deaktiviert wurde:
.sp
Alternativ können die zwei besonderen Zeichenketten »v1« und »v2« (ohne
irgendwelche Controller\-Namen) angegeben werden\&. »v2« wird zutreffen,
falls die vereinigte v2\-Cgroup\-Hierarchie verwandt wird und »v1« wird
zutreffen, falls die veraltete v1\-Hierarchie oder die hybride Hierarchie
verwandt wird\&. Beachten Sie, dass die veraltete und hybride Hierarchie als
veraltet markiert wurden\&. Siehe \fBsystemd\fP(1) für weitere Informationen\&.
.sp
Hinzugefügt in Version 244\&.
.RE
.PP
\fIConditionMemory=\fP
.RS 4
Überprüft, ob die angegebene Menge an Systemspeicher für das aktuelle System
verfügbar ist\&. Akzeptiert eine Speichergröße in Byte als Argument,
optional kann ein Vergleichsoperator »<«, »<=«, »=« (oder »==«),
»!=« (oder »<>«), »>=«, »>« vorangestellt werden\&. Auf
Systemen, die direkt auf der Hardware laufen, vergleicht es die Menge an
physischen Speicher im System mit der angegebenen Größe unter
Berücksichtigung des angegebenen Vergleichsoperators\&. In Containern wird
stattdessen die Menge des zugewiesenen Speichers verglichen\&.
.sp
Hinzugefügt in Version 244\&.
.RE
.PP
\fIConditionCPUs=\fP
.RS 4
Überprüft, dass die angegebene Anzahl an CPUs für das aktuelle System
verfügbar ist\&. Akzeptiert eine Anzahl an CPUs als Argument, optional kann
ein Vergleichsoperator »<«, »<=«, »=« (oder »==«), »!=«, »>=«
(oder »<>«), »>« vorangestellt werden\&. Vergleicht die Anzahl
der CPUs in der CPU\-Affinitätsmaske, die im Diensteverwalter selbst
konfiguriert ist, mit der angegebenen Zahl unter Berücksichtigung des
angegebenen Vergleichsoperators\&. Auf physischen Systemen passt die Anzahl
der CPUs in der Affinitätsmaske des Diensteverwalters normalerweise zu der
Anzahl der physischen CPUs, aber in besonderen und virtuellen Umgebungen
kann sich das unterscheiden\&. Insbesondere in Containern passt die
Affinitätsmaske normalerweise zu der dem Container zugewiesenen Anzahl an
CPUs und nicht zu der Anzahl der physisch verfügbaren\&.
.sp
Hinzugefügt in Version 244\&.
.RE
.PP
\fIConditionCPUFeature=\fP
.RS 4
Prüft nach, ob die angegebene CPU\-Funktionalität mittels der
»CPUID«\-Anweisung verfügbar ist\&. Diese Bedingung macht nur auf i386\- und
x86\-64\-Prozessoren etwas\&. Auf anderen Prozessoren wird angenommen, dass
die CPU die angegebene Funktionalität nicht unterstützt\&. Es prüft die
Erlaubnisse »1«, »7«, »0x80000001« und »0x80000007«\&. Gültige Werte sind:
»fpu«, »vme«, »de«, »pse«, »tsc«, »msr«, »pae«, »mce«, »cx8«, »apic«, »sep«,
»mtrr«, »pge«, »mca«, »cmov«, »pat«, »pse36«, »clflush«, »mmx«, »fxsr«,
»sse«, »sse2«, »ht«, »pni«, »pclmul«, »monitor«, »ssse3«, »fma3«, »cx16«,
»sse4_1«, »sse4_2«, »movbe«, »popcnt«, »aes«, »xsave«, »osxsave«, »avx«,
»f16c«, »rdrand«, »bmi1«, »avx2«, »bmi2«, »rdseed«, »adx«, »sha_ni«,
»syscall«, »rdtscp«, »lm«, »lahf_lm«, »abm«, »constant_tsc«\&.
.sp
Hinzugefügt in Version 248\&.
.RE
.PP
\fIConditionOSRelease=\fP
.RS 4
Bestätigt, dass ein bestimmtes »Schlüssel\-Wert«\-Paar in der \fBos\-release\fP(5)
des Rechners gesetzt ist\&.
.sp
Neben der genauen Zeichenkettenübereinstimmung (mit »=« und »!=«) werden
relative Vergleiche für versionierte Parameter unterstützt
(z\&.B\&. »VERSION_ID«; mit »<«, »<=«, »==«, »<>«, »>=«,
»>«) und Shell\-artige Joker\-Vergleiche (»*«, »?«, »[]«) werden mit »$=«
(Treffer) und »!$=« (nicht Treffer) unterstützt\&.
.sp
Hinzugefügt in Version 249\&.
.RE
.PP
\fIConditionMemoryPressure=\fP, \fIConditionCPUPressure=\fP,
\fIConditionIOPressure=\fP
.RS 4
Verifiziert, dass der gesamte Systemdruck (Speicher, CPU oder E/A) unterhalb
von oder identisch zu einem Schwellwert ist\&. Diese Einstellung akzeptiert
einen Schwellwert als Argument\&. Sie kann als einfacher Prozentwert, dem
»%« angehängt wird, festgelegt werden; in diesem Fall wird der Druck als
Durchschnitt über die letzten fünf Minuten gemessen, bevor der Versuch, die
Unit zu starten, durchgeführt wird\&. Alternativ kann eine durchschnittliche
Zeitdauer auch mit »/« als Trenner festgelegt werden, beispielsweise
»10%/1min«\&. Die unterstützten Zeitdauern passen auf das Angebot des
Kernels und sind auf »10sec«, »1min« und »5min« beschränkt\&. Zuerst wird
der vollständige PSI geprüft, und falls dieser nicht gefunden wird, werden
»einige« geprüft\&. Für weitere Details lesen Sie die Dokumentation unter
\m[blue]\fBPSI (Pressure Stall Information)\fP\m[]\&\s-2\u[4]\d\s+2\&.
.sp
Optional kann dem Schwellwert die Scheiben\-Unit, unter der der Druck
überprüft wird, vorangestellt werden, gefolgt von »:«\&. Falls die
Scheiben\-Unit nicht festgelegt ist, wird der Gesamtsystemdruck statt dem
einer bestimmten Cgroup gemessen\&.
.sp
Hinzugefügt in Version 250\&.
.RE
.PP
\fIAssertArchitecture=\fP, \fIAssertVirtualization=\fP, \fIAssertHost=\fP,
\fIAssertKernelCommandLine=\fP, \fIAssertKernelVersion=\fP, \fIAssertCredential=\fP,
\fIAssertEnvironment=\fP, \fIAssertSecurity=\fP, \fIAssertCapability=\fP,
\fIAssertACPower=\fP, \fIAssertNeedsUpdate=\fP, \fIAssertFirstBoot=\fP,
\fIAssertPathExists=\fP, \fIAssertPathExistsGlob=\fP, \fIAssertPathIsDirectory=\fP,
\fIAssertPathIsSymbolicLink=\fP, \fIAssertPathIsMountPoint=\fP,
\fIAssertPathIsReadWrite=\fP, \fIAssertPathIsEncrypted=\fP,
\fIAssertDirectoryNotEmpty=\fP, \fIAssertFileNotEmpty=\fP,
\fIAssertFileIsExecutable=\fP, \fIAssertUser=\fP, \fIAssertGroup=\fP,
\fIAssertControlGroupController=\fP, \fIAssertMemory=\fP, \fIAssertCPUs=\fP,
\fIAssertCPUFeature=\fP, \fIAssertOSRelease=\fP, \fIAssertMemoryPressure=\fP,
\fIAssertCPUPressure=\fP, \fIAssertIOPressure=\fP
.RS 4
Ähnlich zu den oben beschriebenen Bedingungseinstellungen
\fIConditionArchitecture=\fP, \fIConditionVirtualization=\fP, … 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\&.
.sp
Hinzugefügt in Version 218\&.
.RE
.SH "ABBILDUNG VON UNIT\-EIGENSCHAFTEN AUF IHR INVERSES"
.PP
Unit\-Einstellungen, die eine Beziehung zu einer zweiten Unit erstellen,
zeigen sich normalerweise als Eigenschaften in beiden Units, beispielsweise
in der Ausgabe von \fBsystemctl show\fP\&. 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\&.
.sp
.it 1 an-trap
.nr an-no-space-flag 1
.nr an-break-flag 1
.br
\fBTabelle\ \&4.\ \& Vorwärts\- und Rückwärts\-Unit\-Eigenschaften\fP
.TS
allbox tab(:);
lB lB lB s.
T{
»Vorwärts«\-Eigenschaft
T}:T{
»Rückwärts«\-Eigenschaft
T}:T{
Wo benutzt
T}
.T&
l l l s
l l ^ ^
l l l l
l l l l
l l l l
l l l l
l l l l
l l l l
l l l l
l l l s
l l l s
l l ^ ^
l l l s
l l ^ ^
l l l l.
T{
\fIBefore=\fP
T}:T{
\fIAfter=\fP
T}:T{
[Unit]\-Abschnitt
T}
T{
\fIAfter=\fP
T}:T{
\fIBefore=\fP
T}::
T{
\fIRequires=\fP
T}:T{
\fIRequiredBy=\fP
T}:T{
[Unit]\-Abschnitt
T}:T{
[Install]\-Abschnitt
T}
T{
\fIWants=\fP
T}:T{
\fIWantedBy=\fP
T}:T{
[Unit]\-Abschnitt
T}:T{
[Install]\-Abschnitt
T}
T{
\fIUpholds=\fP
T}:T{
\fIUpheldBy=\fP
T}:T{
[Unit]\-Abschnitt
T}:T{
[Install]\-Abschnitt
T}
T{
\fIPartOf=\fP
T}:T{
\fIConsistsOf=\fP
T}:T{
[Unit]\-Abschnitt
T}:T{
eine automatische Eigenschaft
T}
T{
\fIBindsTo=\fP
T}:T{
\fIBoundBy=\fP
T}:T{
[Unit]\-Abschnitt
T}:T{
eine automatische Eigenschaft
T}
T{
\fIRequisite=\fP
T}:T{
\fIRequisiteOf=\fP
T}:T{
[Unit]\-Abschnitt
T}:T{
eine automatische Eigenschaft
T}
T{
\fIConflicts=\fP
T}:T{
\fIConflictedBy=\fP
T}:T{
[Unit]\-Abschnitt
T}:T{
eine automatische Eigenschaft
T}
T{
\fITriggers=\fP
T}:T{
\fITriggeredBy=\fP
T}:T{
automatische Eigenschaften, siehe Hinweise unten
T}
T{
\fIPropagatesReloadTo=\fP
T}:T{
\fIReloadPropagatedFrom=\fP
T}:T{
[Unit]\-Abschnitt
T}
T{
\fIReloadPropagatedFrom=\fP
T}:T{
\fIPropagatesReloadTo=\fP
T}::
T{
\fIPropagatesStopTo=\fP
T}:T{
\fIStopPropagatedFrom=\fP
T}:T{
[Unit]\-Abschnitt
T}
T{
\fIStopPropagatedFrom=\fP
T}:T{
\fIPropagatesStopTo=\fP
T}::
T{
\fIFollowing=\fP
T}:T{
n.Z.
T}:T{
eine automatische Eigenschaft
T}:T{
\ \&
T}
.TE
.sp 1
.PP
Beachten Sie: \fIWantedBy=\fP, \fIRequiredBy=\fP und \fIUpheldBy=\fP werden im
Abschnitt [Install] verwandt, um Symlinks in \&.wants/\-, \&.requires/\- und
upholds/\-Verzeichnissen zu erstellen\&. Sie können nicht in
Unit\-Konfigurationseinstellungen direkt verwandt werden\&.
.PP
Beachten Sie: \fIConsistsOf=\fP, \fIBoundBy=\fP, \fIRequisiteOf=\fP, \fIConflictedBy=\fP
werden zusammen mit ihren Inversen implizit erstellt und können nicht direkt
festgelegt werden\&.
.PP
Beachten Sie: \fITriggers=\fP 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 \fISockets=\fP, \fIService=\fP und \fIUnit=\fP
außer Kraft gesetzt werden\&. Siehe \fBsystemd.service\fP(5),
\fBsystemd.socket\fP(5), \fBsystemd.path\fP(5) und \fBsystemd.automount\fP(5) für
ihre Details\&. \fITriggeredBy=\fP wird implizit von der ausgelösten Unit
erstellt\&.
.PP
Beachten Sie: \fIFollowing=\fP 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\&.
.SH [INSTALL]\-ABSCHNITT\-OPTIONEN
.PP
Unit\-Dateien können einen Abschnitt »[Install]« enthalten, der
Installationsinformationen für die Unit transportiert\&. Dieser Abschnitt
wird von \fBsystemd\fP(1) während der Laufzeit nicht interpretiert; er wird von
den Befehlen \fBenable\fP und \fBdisable\fP des Werkzeugs \fBsystemctl\fP(1) während
der Installation einer Unit verwandt\&.
.PP
\fIAlias=\fP
.RS 4
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 \fBsystemctl enable\fP 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\&.
.sp
Hinzugefügt in Version 201\&.
.RE
.PP
\fIWantedBy=\fP, \fIRequiredBy=\fP, \fIUpheldBy=\fP
.RS 4
Diese Option kann mehr als einmal verwendet werden oder eine durch
Leerzeichen getrennte Liste von Unit\-Namen kann übergeben werden\&. Im
\&.wants/\-, \&.requires/\- oder \&.upholds/\-Verzeichnis jeder der
aufgeführten Units wird bei der Installation mit \fBsystemctl enable\fP ein
symbolischer Link erstellt\&. Dadurch wird eine Abhängigkeit vom Typ
\fIWants=\fP, \fIRequires=\fP oder \fIUpholds=\fP von der aufgeführten Unit zu der
aktuellen Unit hinzugefügt\&. Siehe die Beschreibung der erwähnten
Abhängigkeitstypen in dem Abschnitt [Unit] für Details\&.
.sp
Falls Vorlagen\-Units nicht\-Vorlagen\-Units aufführen, muss in der
aufführenden Unit \fIDefaultInstance=\fP gesetzt sein oder \fBsystemctl enable\fP
muss mit einem Instanzennamen aufgerufen werden\&. Die Instanz (entweder die
Vorgabe oder die angegebene) wird zu der Liste der \&.wants/, \&.requires/
oder \&.upholds/ der aufgeführten Unit hinzugefügt\&. Zum Beispiel führt
\fBWantedBy=getty\&.target\fP in einem Dienst getty@\&.service dazuz, dass
\fBsystemctl enable getty@tty2\&.service\fP einen Link
getty\&.target\&.wants/getty@tty2\&.service auf getty@\&.service
erstellt\&. Dies gilt auch für das Aufführen bestimmter Instanzen aus einer
Vorlagen\-Unit: diese bestimmte Instanz wird die Abhängigkeit
erhalten\&. Eine Vorlagen\-Unit kann auch eine Vorlagen\-Unit
aufführen\&. Dann wird eine generische Abhängigkeit hinzugefügt, bei der
jede Instanz der aufführenden Unit eine Abhängigkeit auf eine Instanz der
aufgeführten Vorlagen\-Unit mit dem gleichen Instanzwert haben
wird\&. Beispielsweise wird \fBWantedBy=container@\&.target\fP dazu führen,
dass \fBsystemctl enable monitor@\&.service\fP einen Dienste\-Link
container@\&.target\&.wants/monitor@\&.service auf monitor@\&.service
erstellt, der für alle Instanzen von container@\&.target gilt\&.
.sp
Hinzugefügt in Version 201\&.
.RE
.PP
\fIAlso=\fP
.RS 4
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 \fBsystemctl enable\fP und \fBsystemctl disable\fP automatisch
auch die in dieser Option aufgeführten Units installieren/deinstallieren\&.
.sp
Diese Option kann mehr als einmal verwandt werden oder eine
Lerraum\-getrennte Liste von Unit\-Namen kann übergeben werden\&.
.sp
Hinzugefügt in Version 201\&.
.RE
.PP
\fIDefaultInstance=\fP
.RS 4
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\&.
.sp
Hinzugefügt in Version 215\&.
.RE
.PP
Die folgenden Kennzeicher werden in dem Abschnitt Install interpretiert: %a,
%b, %B, %g, %G, %H, %i, %j, %l, %m, %n, %N, %o, %p, %u, %U, %v, %w, %W, %%
\&. Ihre Bedeutung ist im nächsten Abschnitt beschrieben\&.
.SH KENNZEICHNER
.PP
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:
.sp
.it 1 an-trap
.nr an-no-space-flag 1
.nr an-break-flag 1
.br
\fBTabelle\ \&5.\ \&In Unit\-Dateien verfügbare Kennzeichner\fP
.TS
allbox tab(:);
lB lB lB.
T{
Kennzeichner
T}:T{
Bedeutung
T}:T{
Details
T}
.T&
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l.
T{
"%a"
T}:T{
Architektur
T}:T{
Eine kurze Zeichenkette, die die Architektur des lokalen Systems identifiziert\&. Eine Zeichenkette wie \fBx86\fP, \fBx86\-64\fP oder \fBarm64\fP\&. Siehe die für \fIConditionArchitecture=\fP weiter oben definierten Architekturen für die vollständige Liste\&.
T}
T{
"%A"
T}:T{
Betriebssystemabbildversion
T}:T{
Die Betriebssystemabbildversionskennzeichnung des laufenden Systems, wie aus dem Feld \fIIMAGE_VERSION=\fP in /etc/os\-release ausgelesen\&. Falls nicht gesetzt, wird es die leere Zeichenkette\&. Siehe \fBos\-release\fP(5) für weitere Informationen\&.
T}
T{
"%b"
T}:T{
Boot\-Kennung
T}:T{
Die Boot\-Kennung des laufenden Systems, formatiert als Zeichenkette\&. Siehe \fBrandom\fP(4) für weitere Informationen\&.
T}
T{
"%B"
T}:T{
Betriebssystembaukennung
T}:T{
Die Betriebssystembaukennung des laufenden Systems, wie aus dem Feld \fIBUILD_ID=\fP in /etc/os\-release ausgelesen\&. Falls nicht gesetzt, wird es zur leeren Zeichenkette aufgelöst\&. Siehe \fBos\-release\fP(5) für weitere Informationen\&.
T}
T{
"%C"
T}:T{
Wurzelverzeichnis des Zwischenspeichers
T}:T{
Dies ist entweder /var/cache (für den Systemverwalter) oder worauf der Pfad »$XDG_CACHE_HOME« zeigt (für Benutzerverwalter)\&.
T}
T{
"%d"
T}:T{
Zugangsdaten\-Verzeichnis
T}:T{
Dies ist der Wert der Umgebungsvariablen »$CREDENTIALS_DIRECTORY«, falls verfügbar\&. Siehe den Abschnitt »Zugangsdaten« in \fBsystemd.exec\fP(5) für weitere Informationen\&.
T}
T{
"%E"
T}:T{
Wurzelverzeichnis der Konfiguration
T}:T{
Dies ist entweder /etc/ (für den Systemverwalter) oder worauf der Pfad »$XDG_CONFIG_HOME« zeigt (für Benutzerverwalter)\&.
T}
T{
"%f"
T}:T{
Demaskierter Dateiname
T}:T{
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\&.
T}
T{
"%g"
T}:T{
Benutzergruppe
T}:T{
Dies ist der Name der Gruppe, die die Diensteverwalterinstanz ausführt\&. Im Falle des Systemverwalters löst sich dies auf »root« auf\&.
T}
T{
"%G"
T}:T{
Benutzer\-GID
T}:T{
Dies ist die numerische GID des Benutzers, der die Diensteverwalterinstanz ausführt\&. Im Falle des Systemverwalters löst sich dies auf »0« auf\&.
T}
T{
"%h"
T}:T{
Benutzer\-Home\-Verzeichnis
T}:T{
Dies ist das Home\-Verzeichnis des \fIBenutzers, der die Diensteverwalterinstanz ausführt\fP\&. Im Falle des Systemverwalters löst sich dies auf »/root« auf\&.

Beachten Sie, dass diese Einstellung \fInicht\fP von der im Abschnitt [Service] der Dienste\-Unit konfigurierbaren Einstellung \fIUser=\fP beeinflusst wird\&.
T}
T{
"%H"
T}:T{
Rechnername
T}:T{
Der Rechnername des laufenden Systems zum Zeitpunkt des Ladens der Unit\-Konfiguration\&.
T}
T{
"%i"
T}:T{
Instanzenname
T}:T{
Für instanziierte Units ist dies die Zeichenkette zwischen dem ersten »@«\-Zeichen und der Typendung\&. Leer für nichtinstanziierte Units\&.
T}
T{
"%I"
T}:T{
Demaskierter Instanzenname
T}:T{
Identisch zu »%i«, aber mit zurückgenommener Maskierung\&.
T}
T{
"%j"
T}:T{
Abschließende Komponente des Präfixes
T}:T{
Dies ist die Zeichenkette zwischen dem letzten »\-« und dem Ende des Präfixnamens\&. Falls es kein »\-« gibt, ist dies zu »%p« identisch\&.
T}
T{
"%J"
T}:T{
Nicht maskierte abschließende Komponente des Präfixes
T}:T{
Identisch zu »%j«, aber mit zurückgenommener Maskierung\&.
T}
T{
"%l"
T}:T{
Kurzer Rechnername
T}:T{
Der Rechnername des laufenden Systems zum Zeitpunkt des Ladens der Unit\-Konfiguration, abgeschnitten am ersten Punkt, um alle Domain\-Komponenten zu entfernen\&.
T}
T{
"%L"
T}:T{
Wurzel des Protokollierverzeichnisses
T}:T{
Dies ist entweder /var/log (für den Systemverwalter) oder worauf der Pfad \fI$XDG_CONFIG_HOME\fP zeigt, mit angehängtem /log (für Benutzerverwalter)\&.
T}
T{
"%m"
T}:T{
Maschinenkennung
T}:T{
Die Maschinenkennung des laufenden Systems, formatiert als Zeichenkette\&. Siehe \fBmachine\-id\fP(5) für weitere Informationen\&.
T}
T{
"%M"
T}:T{
Betriebssystemabbildkennung
T}:T{
Die Betriebssystemabbildkennung des laufenden Systems, wie aus dem Feld \fIIMAGE_ID=\fP in /etc/os\-release ausgelesen\&. Falls nicht gesetzt, wird es die leere Zeichenkette\&. Siehe \fBos\-release\fP(5) für weitere Informationen\&.
T}
T{
"%n"
T}:T{
Vollständiger Unit\-Name
T}:T{
\ \&
T}
T{
"%N"
T}:T{
Vollständiger Unit\-Name
T}:T{
Identisch zu »%n«, aber mit entfernter Typendung\&.
T}
T{
"%o"
T}:T{
Betriebssystemkennung
T}:T{
Die Betriebssystemkennung des laufenden Systems, wie aus dem Feld \fIID=\fP in /etc/os\-release ausgelesen\&. Siehe \fBos\-release\fP(5) für weitere Informationen\&.
T}
T{
"%p"
T}:T{
Präfixname
T}:T{
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«\&.
T}
T{
"%P"
T}:T{
Nicht maskierter Präfixname
T}:T{
Identisch zu »%p«, aber mit zurückgenommener Maskierung\&.
T}
T{
"%q"
T}:T{
Schöner Rechnername
T}:T{
Der schöne Rechnername des laufenden Systems zum Zeitpunkt des Ladens der Unit\-Konfiguration, wie aus dem Feld \fIPRETTY_HOSTNAME=\fP in /etc/machine\-info ausgelesen\&. Falls nicht gesetzt, wird es auf den kurzen Rechnernamen gesetzt\&. Siehe \fBmachine\-info\fP(5) für weitere Informationen\&.
T}
T{
"%s"
T}:T{
Benutzer\-Shell
T}:T{
Dies ist die Shell des Benutzers, der die Diensteverwalterinstanz ausführt\&.
T}
T{
"%S"
T}:T{
Wurzel des Zustandsverzeichnisses
T}:T{
Dies ist entweder /var/lib (für den Systemverwalter) oder worauf der Pfad \fI$XDG_CONFIG_HOME\fP zeigt (für Benutzerverwalter)\&.
T}
T{
"%t"
T}:T{
Wurzel des Laufzeitverzeichnisses
T}:T{
Dies ist entweder /run/ (für den Systemverwalter) oder worauf der Pfad »$XDG_RUNTIME_DIR« zeigt (für Benutzerverwalter)\&.
T}
T{
"%T"
T}:T{
Verzeichnis für temporäre Dateien
T}:T{
Dies ist entweder /tmp oder der Pfad, auf den »$TMPDIR«, »$TEMP« oder »$TMP« gesetzt ist\&. (Beachten Sie, dass das Verzeichnis ohne abschließenden Schrägstrich angegeben werden kann\&.)
T}
T{
"%u"
T}:T{
Benutzername
T}:T{
Dies ist der Name des \fIBenutzers, der die Diensteverwalterinstanz ausführt\fP\&. Im Falle des Systemverwalters löst sich dies auf »root« auf\&.

Beachten Sie, dass diese Einstellung \fInicht\fP von der im Abschnitt [Service] der Dienste\-Unit konfigurierbaren Einstellung \fIUser=\fP beeinflusst wird\&.
T}
T{
"%U"
T}:T{
Benutzer\-UID
T}:T{
Dies ist die numerische UID des \fIBenutzers, der die Diensteverwalterinstanz ausführt\fP\&. Im Falle des Systemverwalters löst sich dies auf »0« auf\&.

Beachten Sie, dass diese Einstellung \fInicht\fP von der im Abschnitt [Service] der Dienste\-Unit konfigurierbaren Einstellung \fIUser=\fP beeinflusst wird\&.
T}
T{
"%v"
T}:T{
Kernelveröffentlichung
T}:T{
Identisch zur Ausgabe von \fBuname \-r\fP\&.
T}
T{
"%V"
T}:T{
Verzeichnis für größere und dauerhafte temporäre Dateien
T}:T{
Dies ist entweder /var/tmp oder der Pfad, auf den »$TMPDIR«, »$TEMP« oder »$TMP« gesetzt ist\&. (Beachten Sie, dass das Verzeichnis ohne abschließenden Schrägstrich angegeben werden kann\&.)
T}
T{
"%w"
T}:T{
Betriebssystemversionskennung
T}:T{
Die Betriebssystemversionskennzeichnung des laufenden Systems, wie aus dem Feld \fIVERSION_ID=\fP in /etc/os\-release ausgelesen\&. Falls nicht gesetzt, wird es die leere Zeichenkette\&. Siehe \fBos\-release\fP(5) für weitere Informationen\&.
T}
T{
"%W"
T}:T{
Betriebssystemvariantenkennung
T}:T{
Die Betriebssystemvariantenkennung des laufenden Systems, wie aus dem Feld \fIVARIANT_ID=\fP in /etc/os\-release ausgelesen\&. Falls nicht gesetzt, wird es die leere Zeichenkette\&. Siehe \fBos\-release\fP(5) für weitere Informationen\&.
T}
T{
"%y"
T}:T{
Der Pfad zum Fragment\&.
T}:T{
Dies ist der Pfad dorthin, wo sich der Hauptteil der Unit\-Datei befindet\&. Für verlinkte Unit\-Dateien wird der echte Pfad außerhalb der Unit\-Suchverzeichnisse verwandt\&. Für Units ohne Fragementdateien wird der Kennzeichner einen Fehler hervorrufen\&.
T}
T{
"%Y"
T}:T{
Das Verzeichnis des Fragement\&.
T}:T{
Dies ist der Verzeichnisanteil von »%y«\&.
T}
T{
"%%"
T}:T{
Einzelnes Prozentzeichen
T}:T{
Verwenden Sie »%%« anstelle von »%«, um ein einzelnes Prozentzeichen anzugeben\&.
T}
.TE
.sp 1
.SH BEISPIELE
.PP
\fBBeispiel\ \&1.\ \&Units erlauben, freigegeben zu werden\fP
.PP
Der nachfolgende Schnipsel (hervorgehoben) erlaubt es einer Unit
(z\&.B\&. foo\&.service), mittels \fBsystemctl enable\fP freigegeben zu werden:
.sp
.if  n \{\
.RS 4
.\}
.nf
[Unit]
Description=Foo

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

\fI[Install]\fP
\fIWantedBy=multi\-user\&.target\fP
.fi
.if  n \{\
.RE
.\}
.PP
Nach der Ausführung von \fBsystemctl enable\fP 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 \fBsystemctl disable\fP wird diesen Symlink wieder entfernen\&.
.PP
\fBBeispiel\ \&2.\ \&Lieferanteneinstellungen außer Kraft setzen\fP
.PP
Es gibt zwei Methoden, die Lieferanteneinstellungen in Unit\-Dateien außer
Kraft zu setzen: Kopieren der Unit\-Datei aus /usr/lib/systemd/system nach
/etc/systemd/system und Anpassen der gewählten Einstellungen oder alternativ
durch Anlage eines Verzeichnisses namens \fIUnit\fP\&.d/ innerhalb von
/etc/systemd/system und darin einer Ergänzungsdatei \fIName\fP\&.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\&.
.PP
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\&.
.PP
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\&.
.PP
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\&.
.PP
Lassen Sie uns annehmen, dass es eine vom Lieferanten bereitgestellte Unit
/usr/lib/systemd/system/httpd\&.service mit dem folgenden Inhalt gibt:
.sp
.if  n \{\
.RS 4
.\}
.nf
[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
.fi
.if  n \{\
.RE
.\}
.PP
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
\fIRequires=\fP) hereingezogen und auch entsprechend angeordnet (mittels
\fIAfter=\fP) werden soll\&. Drittens möchte der Administrator zur weiteren
Härtung des Dienstes die Einstellung \fIPrivateTmp=\fP (siehe
\fBsystemd.exec\fP(5) für Details) setzen\&. Schließlich möchte der
Administrator die Einstellung des Nice\-Wertes des Dienstes auf den
Vorgabewert 0 zurücksetzen\&.
.PP
Die erste Möglichkeit besteht darin, die Unit\-Datei nach
/etc/systemd/system/httpd\&.service zu kopieren und die ausgewählten
Einstellungen zu ändern:
.sp
.if  n \{\
.RS 4
.\}
.nf
[Unit]
Description=Ein HTTP\-Server
After=remote\-fs\&.target sqldb\&.service \fImemcached\&.service\fP
Requires=sqldb\&.service \fImemcached\&.service\fP
AssertPathExists=\fI/srv/www\fP

[Service]
Type=notify
ExecStart=/usr/sbin/some\-fancy\-httpd\-server
\fINice=0\fP
\fIPrivateTmp=yes\fP

[Install]
WantedBy=multi\-user\&.target
.fi
.if  n \{\
.RE
.\}
.PP
Alternativ könnte der Administrator eine Ergänzungsdatei in
/etc/systemd/system/httpd\&.service\&.d/local\&.conf mit folgendem Inhalt
erstellen:
.sp
.if  n \{\
.RS 4
.\}
.nf
[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
.fi
.if  n \{\
.RE
.\}
.PP
Beachten Sie bei Ergänzungsdateien, dass bei Einstellungen, die als Liste
ausgewertet werden (und die keine Abhängigkeit sind), wie
\fIAssertPathExists=\fP (oder z\&.B\&. \fIExecStart=\fP 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 (\fIAfter=\fP, 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\&.
.PP
\fBBeispiel\ \&3.\ \&Ergänzungen auf oberster Ebene mit Vorlagen\-Units\fP
.PP
Typbezogene Ergänzungen auf oberster Stufe können zum Ändern einiger Aspekte
aller Units eines bestimmten Typs verwandt werden\&. Wird beispielsweise das
Verzeichnis /etc/systemd/system/service\&.d/ mit einer Ergänzungsdatei
erstellt, können die Inhalte der Ergänzungsdatei auf alle Dienste\-Units
angewandt werden\&. Dies kann weitergetrieben werden, indem die Ergänzung
auf oberster Stufe eine sekundäre Hilfs\-Unit realisiert\&. Betrachten Sie
beispielsweise die folgende Gruppe von Units und Ergänzungsdateien, bei
denen eine Abhängigkeit \fIOnFailure=\fP für alle Dienste\-Units installiert
wird\&.
.PP
/etc/systemd/system/failure\-handler@\&.service:
.sp
.if  n \{\
.RS 4
.\}
.nf
[Unit]
Description=Mein Fehler\-Handler für %i

[Service]
Type=oneshot
# Ausführung einiger besonderer Aktionen, wenn sich %i unerwartet beendet\&.
ExecStart=/usr/sbin/myfailurehandler %i
     
.fi
.if  n \{\
.RE
.\}
.PP
Eine Instanz von failure\-handler@\&.service kann als eine Abhängigkeit
\fIOnFailure=\fP für alle Dienste\-Units hinzugefügt werden\&.
.PP
/etc/systemd/system/service\&.d/10\-all\&.conf:
.sp
.if  n \{\
.RS 4
.\}
.nf
[Unit]
OnFailure=failure\-handler@%N\&.service
    
.fi
.if  n \{\
.RE
.\}
.PP
Nach der Ausführung von \fBsystemctl daemon\-reload\fP werden jetzt alle Dienste
ein Abhängigkeit \fIOnFailure=\fP auf failure\-handler@%N\&.service erlangt
haben\&. Die Vorlage\-Instanz\-Units werden auch die Abhängigkeit erlangt
haben, die zu der Erstellung einer rekursiven Abhängigkeitskette geführt
hat\&. Systemd wird versuchen, diese rekursiven Abhängigkeitsketten zu
erkennen, bei der eine Vorlagen\-Unit direkt und rekursiv von sich selbst
abhängt und wird solche Abhängigkeiten automatisch entfernen, falls es sie
findet\&. Falls Systemd die rekursive Abhängigkeitskette nicht selbst
erkennt, kann die Kette manuell unterbrochen werden, indem die Ergänzung für
die Vorlagen\-Instanz\-Units mittels Symlinks auf /dev/null unterbrochen wird:
.sp
.if  n \{\
.RS 4
.\}
.nf
\fBmkdir /etc/systemd/system/failure\-handler@\&.service\&.d/\fP
\fBln \-s /dev/null /etc/systemd/system/failure\-handler@\&.service\&.d/10\-all\&.conf\fP
\fBsystemctl daemon\-reload\fP
    
.fi
.if  n \{\
.RE
.\}
.PP
Dies stellt sicher, dass eine Instanz von failure\-handler@\&.service
fehlschlägt, falls sie keine Instanz namens
failure\-handler@failure\-handler\&.service auslöst\&.
.SH "SIEHE AUCH"
.PP
\fBsystemd\fP(1), \fBsystemctl\fP(1), \fBsystemd\-system.conf\fP(5),
\fBsystemd.special\fP(7), \fBsystemd.service\fP(5), \fBsystemd.socket\fP(5),
\fBsystemd.device\fP(5), \fBsystemd.mount\fP(5), \fBsystemd.automount\fP(5),
\fBsystemd.swap\fP(5), \fBsystemd.target\fP(5), \fBsystemd.path\fP(5),
\fBsystemd.timer\fP(5), \fBsystemd.scope\fP(5), \fBsystemd.slice\fP(5),
\fBsystemd.time\fP(7), \fBsystemd\-analyze\fP(1), \fBcapabilities\fP(7),
\fBsystemd.directives\fP(7), \fBuname\fP(1)
.SH ANMERKUNGEN
.IP " 1." 4
Schnittstellenportabilitäts\- und \-stabilitätszusage
.RS 4
\%https://systemd.io/PORTABILITY_AND_STABILITY/
.RE
.IP " 2." 4
Systemd\- und Speicher\-Daemons für das Wurzeldateisystem
.RS 4
\%https://systemd.io/ROOT_STORAGE_DAEMONS
.RE
.IP " 3." 4
System\- und Dienste\-Zugangsberechtigungen
.RS 4
\%https://systemd.io/CREDENTIALS
.RE
.IP " 4." 4
PSI (Pressure Stall Information)
.RS 4
\%https://docs.kernel.org/accounting/psi.html
.RE
.PP
.SH ÜBERSETZUNG
Die deutsche Übersetzung dieser Handbuchseite wurde von
Helge Kreutzmann <debian@helgefjell.de>
erstellt.
.PP
Diese Übersetzung ist Freie Dokumentation; lesen Sie die
.UR https://www.gnu.org/licenses/gpl-3.0.html
GNU General Public License Version 3
.UE
oder neuer bezüglich der
Copyright-Bedingungen. Es wird KEINE HAFTUNG übernommen.
.PP
Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden,
schicken Sie bitte eine E-Mail an die
.MT debian-l10n-german@lists.debian.org
Mailingliste der Übersetzer
.ME .