BEZEICHNUNG
systemd.unit - Unit-KonfigurationÜBERSICHT
Dienst.service, Socket.socket, Gerät.device, Einhängung.mount, Selbsteinhängung.automount, Auslagerung.swap, Ziel.target, Pfad.path, Timer.timer, Scheibe.slice, Bereich.scopeSystem-Unit-Suchpfad
/etc/systemd/system.control/* /run/systemd/system.control/* /run/systemd/transient/* /run/systemd/generator.early/* /etc/systemd/system/* /etc/systemd/system.attached/* /run/systemd/system/* /run/systemd/system.attached/* /run/systemd/generator/* … /lib/systemd/system/* /run/systemd/generator.late/*
Benutzer-Unit-Suchpfad
~/.config/systemd/user.control/* $XDG_RUNTIME_DIR/systemd/user.control/* $XDG_RUNTIME_DIR/systemd/transient/* $XDG_RUNTIME_DIR/systemd/generator.early/* ~/.config/systemd/user/* $XDG_CONFIG_DIRS/systemd/user/* /etc/systemd/user/* $XDG_RUNTIME_DIR/systemd/user/* /run/systemd/user/* $XDG_RUNTIME_DIR/systemd/generator/* $XDG_DATA_HOME/systemd/user/* $XDG_DATA_DIRS/systemd/user/* … /usr/lib/systemd/user/* $XDG_RUNTIME_DIR/systemd/generator.late/*
BESCHREIBUNG
Eine Unit-Konfigurationsdatei ist eine reine Textdatei im Ini-Format, die Informationen über einen Dienst, ein Socket, ein Gerät, einen Einhängepunkt, einen Selbsteinhängepunkt, eine Auslagerungsdatei oder -partition, ein Startziel, einen überwachten Dateipfad, einen von systemd(1) gesteuerten und überwachten Timer, eine Ressourcenverwaltungsscheibe oder eine Gruppe von extern erstellten Prozessen kodiert. Siehe systemd.syntax(7) für eine allgemeine Beschreibung der Syntax. Diese Handbuchseite führt die gemeinsamen Konfigurationsoptionen aller Unit-Typen auf. Diese Optionen müssen in den Abschnitten [Unit] oder [Install] der Unit-Dateien konfiguriert werden. Zusätzlich zu den hier beschriebenen generischen Abschnitten [Unit] und [Install] kann jede Unit einen typspezifischen Abschnitt haben, z.B. [Service] für eine Dienste-Unit. Siehe die respektiven Handbuchseiten für weitere Informationen: systemd.service(5), systemd.socket(5), systemd.device(5), systemd.mount(5), systemd.automount(5), systemd.swap(5), systemd.target(5), systemd.path(5), systemd.timer(5), systemd.slice(5), systemd.scope(5). Unit-Dateien werden von einer Reihe von Pfaden, die während der Compilierung bestimmt werden, geladen. Dies wird im nächsten Abschnitt beschrieben. Gültige Unit-Namen bestehen aus einen »Namensvorsatz« und einem Punkt und einer Endung, die den Unit-Typ festlegt. Der »Unit-Vorsatz« muss aus einem oder mehreren gültigen Zeichen (ASCII-Buchstaben, Ziffern, »:«, »-«, »_«, ».« und »\« bestehen). Die Gesamtlänge des Unit-Names einschließlich der Endung darf 256 Zeichen nicht überschreiten. Die Typ-Endung muss entweder ».service«, ».socket«, ».device«, ».mount«, ».automount«, ».swap«, ».target«, ».path«, ».timer«, ».slice« oder ».scope« sein. Unit-Namen können durch einen einzelnen Parameter, genannt »Instanzenname«, parametrisiert werden. Die Unit wird dann, basierend auf einer »Vorlagendatei«, die als Definition mehrerer Dienste oder anderer Units dient, konstruiert. Eine Vorlagendatei muss ein einzelnes »@« am Ende des Namens haben (direkt vor der Typendung). Der Name der kompletten Unit wird durch Einfügung des Instanzennamens zwischen dem @ und der Unit-Typendung gebildet. In der Unit-Datei selbst kann auf den Instanzenparameter mittels »%i« und anderen Kennzeichnern Bezug genommen werden, siehe unten. Unit-Dateien dürfen zusätzliche zu den hier aufgeführten Optionen enthalten. Falls Systemd auf eine unbekannte Option stößt, wird es eine Warnprotokollnachricht schreiben, aber mit dem Laden der Unit fortfahren. Falls vor einer Option oder einem Abschnittnamen ein X- steht, wird diese(r) von Systemd komplett ignoriert. Optionen innerhalb eines ignorierten Abschnittes benötigen die vorangestellte Kennung nicht. Anwendungen können dies dazu verwenden, zusätzliche Informationen in den Unit-Dateien aufzunehmen. Um auf diese Optionen zuzugreifen, müssen Anwendungen die Unit-Dateien selbst auswerten. Aliase (alternative Namen) können für Units angelegt werden, indem ein Symlink vom neuen Namen auf den alten Namen in einem der Unit-Suchpfade angelegt wird Beispielsweise hat systemd-networkd.service den Alias dbus-org.freedesktop.network1.service, der während der Installation als ein Symlink erstellt wird, so dass systemd auf die Anfrage über D-Bus, dbus-org.freedesktop.network1.service zu laden, systemd-networkd.service laden wird. Als weiteres Beispiel ist default.target — das Standard-Systemziel, was beim Systemstart gestartet wird — oft über einen Alias mit entweder multi-user.target oder graphical.target verbunden, um auszuwählen, was standardmäßig gestartet wird. Aliasnamen können in Befehlen wie disable, start, stop, status und ähnlichen und in allen Unit-Abhängigkeitsanweisungen einschließlich Wants=, Requires=, Before=, After= verwandt werden. Aliase können nicht mit dem Befehl preset verwandt werden. Alias unterliegen den folgenden Beschränkungen: Eine Unit eines bestimmten Typs (».service«, ».socket«, …) kann nur ein Alias auf einen Namen mit der gleichen Typendung werden. Eine einfache Unit (keine Vorlage oder Instanz) darf nur ein Alias auf einen einfachen Namen werden. Eine Vorlageninstanz darf nur durch eine andere Vorlageninstanz einen Alias erhalten und der Instanzanteil muss identisch sein. Eine Vorlage darf durch eine andere Vorlage einen Alias erhalten (dann gilt der Alias für alle Instanzen der Vorlage). Eine Vorlageninstanz (z.B. »[email protected]«) darf als Spezialfall ein Symlink auf eine andere Vorlage sein (z.B. »[email protected]«). In diesem Fall wird nur für diese spezielle Instanz ein Alias angelegt, während andere Instanzen dieser Vorlage (z.B. »[email protected]«, »[email protected]«) keinen Alias erhalten. Diese Regeln erhalten die Anforderung, dass die Instanz (falls vorhanden) immer eindeutig für eine gegebene Unit und alle ihre Aliase definiert ist. Das Ziel des Alias-Symlinks muss auf einen gültigen Unit-Dateiort zeigen, d.h. der Symlink-Zieldateiname muss wie beschrieben auf den Symlink-Quellnamen passen und der Zielpfad muss in einem der Unit-Suchpfade sein, siehe nachfolgenden UNIT-DATEI-LADEPFAD für weitere Details. Beachten Sie, dass die Zieldatei nicht existieren könnte, d.h. der Symlink hängen könnte. Zusätzlich können Unit-Dateien Aliase mittels der Anweisung Alias= im Abschnitt [Install] festlegen. Wenn die Unit aktiviert ist, werden Symlinks für diese Namen erstellt und wieder entfernt, wenn die Unit deaktiviert wird. Beispielsweise legt reboot.target Alias=ctrl-alt-del.target so fest, dass der Symlink /etc/systemd/system/ctrl-alt-del.service auf die Datei reboot.target bei der Aktivierung erstellt wird und wenn Strg-Alt-Entf gedrückt wird, systemd nach ctrl-alt-del.service suchen und reboot.service ausführen wird. systemd schaut während des normalen Betriebs überhaupt nicht in den Abschnitt [Install], daher haben sämtliche Direktiven in diesem Abschnitt nur durch während der Aktivierung erstellte Symlinks eine Wirkung. Das Verzeichnis foo.service.wants/ kann zusammen mit der Unit-Datei foo.service existieren. Alle Unit-Dateien, die von so einem Verzeichnis mittels Symlink verknüpft sind, werden implizit als Abhängigkeiten vom Typ Wants= für die Unit hinzugefügt. Eine ähnliche Funktionalität existiert auch für Abhängigkeiten vom Typ Requires=, die Verzeichnisendung ist in diesem Fall .requires/. Diese Funktionalität ist nützlich, um Units in den Start von anderen Units einzuhängen, ohne ihre Unit-Dateien zu verändern. Für Details über die Semantik von Wants= und Requires= siehe unten. Die bevorzugte Art, Symlinks in den Verzeichnissen .wants/ oder .requires/ erfolgt durch die Angabe der Abhängigkeit in dem Abschnitt [Install] der Ziel-Unit und Erstellung des Symlinks im Dateisystem mittels des Befehls enable oder preset von systemctl(1). Das Ziel kann eine normale Unit sein (entweder einfach oder durch eine bestimmte Instanz einer Vorlagen-Unit). Falls die Quell-Unit eine Vorlage ist, kann die Ziel-Unit auch eine Vorlage sein, dann wird die Instanz zu der Ziel-Unit »weitergeleitet«, um eine gültige Unit-Instanz zu bilden. Das Ziel von Symlinks in .wants/ oder .requires/ muss daher auf einen gültigen Unit-Dateiort zeigen, d.h. der Symlink-Zielname muss die beschriebenen Anforderungen erfüllen und der Zielpfad muss in einem der Unit-Suchpfade liegen, siehe nachfolgenden UNIT-DATEI-LADEPFAD für weitere Details. Beachten Sie, dass die Zieldatei nicht existieren könnte, d.h. der Symlink hängen könnte. Zusammen mit einer Unit-Datei foo.service kann ein »Ergänzungs«-Verzeichnis foo.service.d/ existieren. Alle Dateien mit der Endung ».conf« aus diesem Verzeichnis in alphanumerischer Reihenfolge zusammengeführt und ausgewertet, nachdem die Unit-Datei selbst ausgewertet wurde. Dies ist nützlich, um die Konfigurationseinstellungen für eine Unit zu verändern oder zu ergänzen, ohne die Unit-Dateien selbst verändern zu müssen. Jede Ergänzungsdatei muss geeignete Abschnittskopfzeilen enthalten. Für instanziierte Units wird diese Logik zuerst nach dem Instanzen-Unterverzeichnis ».d/« (z.B. »[email protected]/«) schauen und dessen ».conf«-Dateien lesen, gefolgt von dem Vorlagenunterverzeichnis ».d/« (z.B. »[email protected]/«) und den ».conf«-Dateien dort. Für Unit-Namen, die desweiteren Bindestriche (»-«) enthalten, wird die Menge der Verzeichnisse, die durch wiederholtes Abschneiden des Unit-Namens nach allen Bindestrichen entsteht, auch durchsucht. Insbesondere wird für einen Unit-Namen foo-bar-baz.service.d/ sowohl foo-bar-.service.d/ als auch foo-.service.d/ durchsucht. Dies ist nützlich, um gemeinsame Ergänzungen für eine Gruppe von zusammengehörigen Units zu definieren, deren Namen mit einem gemeinsamen Anfang beginnen. Dieses Schema ist insbesondere für Einhänge-, Automount- und Scheiben-Units, deren systematische Benennungsstruktur rund um Bindestriche als Komponententrenner aufgebaut ist, nützlich. Beachten Sie, dass gleichbenannte Ergänzungsdateien weiter unten in der Anfangshierarchie solche weiter oben außer Kraft setzen, d.h. foo-bar-.service.d/10-override.conf setzt foo-.service.d/10-override.conf außer Kraft. Im Falle von (den oben beschriebenen) Unit-Aliasen, werden die Ergänzungen für die Aliasnamen und alle Aliasse geladen. Falls beispielsweise default.target ein Alias für graphical.target ist, würden default.target.d/, default.target.wants/, default.target.requires/, graphical.target.d/, graphical.target.wants/, graphical.target.requires/ alle gelesen. Für Vorlagen werden die Ergänzungen für die Vorlage, alle Vorlagen-Aliasse, die Vorlageninstanz und alle Alias-Instanzen gelesen. Wird nur für eine bestimmte Vorlageninstanz ein Alias angelegt, dann werden die Ergänzungen für die Zielvorlage, die Zielvorlageninstanz und die Alias-Vorlageninstanz gelesen. Zusätzlich zu /etc/systemd/system können Ergänzungs-».d/«-Verzeichnisse in die Verzeichnisse /lib/systemd/system oder /run/systemd/system abgelegt werden. Ergänzungsdateien in /etc/ haben Vorrang vor denen in /run/, die wiederum Vorrang vor denen in /lib/ haben. Ergänzungsdateien unter all diesen Verzeichnissen haben Vorrang vor der Haupt-Netdev-Datei, wo auch immer sich diese befindet. Mehrere Ergänzungsdateien mit verschiedenen Namen werden in lexikographischer Reihenfolge angewandt, unabhängig von dem Verzeichnis, in dem sie sich befinden. Units unterstützen auch ein Ergänzungs- Typ.d/-Verzeichnis auf oberster Ebene, wobei Typ z.B. »service« oder »socket« sein darf. Dies erlaubt es, die Einstellungen aller entsprechenden Unit-Dateien auf dem System zu verändern oder zu ergänzen. Die Formatierung und die Vorrangregeln bei der Anwendung von Ergänzungskonfigurationen folgen dem oben definiertem. Dateien in Typ.d/ haben niedrigeren Vorrang im Vergleich zu Dateien in namensspezifischen Außerkraftsetzungsverzeichnissen. Es gelten die normalen Regeln: mehrere Ergänzungsdateien mit verschiedenen Namen werden in lexikographischer Reihenfolge angewandt, unabhängig davon, in welchem Verzeichnis sie sich befinden, daher gilt eine Datei in Typ.d/ für eine Unit nur, falls es keine Ergänzung oder Maskierung mit diesem Namen in Verzeichnissen mit höherem Vorrang gibt. Siehe Beispiele. Beachten Sie, dass Systemd zwar ein flexibles Abhängigkeitssystem zwischen Units bereitstellt, es aber empfohlen wird, diese Funktionalität nur sparsam zu verwenden und stattdessen auf Techniken wie Bus-basierte oder Socket-basierte Aktivierung zu setzen, wodurch Abhängigkeiten implizit werden und damit sowohl ein einfacheres als auch flexibleres System entsteht. Wie oben erwähnt können Units von Vorlagendateien instanziiert werden. Dies erlaubt die Erstellung mehrere Units aus einer einzelnen Konfigurationsdatei. Falls Systemd nach einer Unit-Konfigurationsdatei schaut, wird es zuerst nach dem wörtlichen Dateinamen in dem Dateisystem suchen. Falls das zu keinem Erfolg führt und der Unit-Name das Zeichen »@« enthält, wird Systemd nach einer Unit-Vorlage suchen, die auch den gleichen Namen hat, aber mit einer entfernten Instanzzeichenkette (d.h. der Teil zwischen dem »@«-Zeichen und der Endung entfernt). Beispiel: Falls ein Dienst [email protected] angefragt wird und keine Datei mit diesem Namen gefunden wird, dann wird Systemd nach [email protected] suchen und einen Dienst aus dieser Konfigurationsdatei instanziieren, falls sie gefunden wurde. Um sich innerhalb der Konfigurationsdatei auf die Instanziierungszeichenkette zu beziehen, können Sie den speziellen Kennzeichner »%i« in vielen Konfigurationsoptionen verwenden. Siehe unten für Details. Falls eine Unit-Datei leer ist (d.h. die Größe 0 hat) oder ein Symlink ist, der auf /dev/null zeigt, wird seine Konfiguration nicht geladen und sie erscheint mit einem Ladezustand »masked« und kann nicht aktiviert werden. Verwenden Sie dies als wirksame Methode, um eine Unit komplett zu deaktivieren und es somit unmöglich zu machen, sie sogar manuell zu starten. Das Unit-Dateiformat wird durch die Schnittstellenportabilitäts- und -stabilitätszusage[1] abgedeckt.ZEICHENKETTENMASKIERUNG FÜR DIE AUFNAHME IN UNIT-NAMEN
Manchmal ist es nützlich, eine beliebige Zeichenkette in Unit-Namen umzuwandeln. Um dies zu unterstützen, wird eine Zeichenkettenmaskierungsmethode verwandt, um Zeichenketten, die beliebige Byte-Werte (außer NUL) enthalten, in gültige Namen und ihren begrenzten Zeichensatz umzuwandeln. Ein häufiger Spezialfall sind Unit-Namen, die Pfade zu Objekten in der Dateisystemhierarchie widerspiegeln. Beispiel: eine Geräte-Unit dev-sda.device bezieht sich auf ein Gerät mit dem Geräteknoten /dev/sda in dem Dateisystem. Der Maskieralgorithmus funktioniert wie folgt: in einer gegebenen Zeichenkette wird jedes »/«-Zeichen durch »-« und alle anderen Zeichen außer den alphanumerischen ASCII-Zeichen, »:«, »_« oder ».« werden durch ihr C-artige »\x2d«-Maskierung ersetzt. Wenn ».« als erstes Zeichen in der maskierten Zeichenkette auftauchen würde, wird es zusätzlich mit seiner C-artigen Maskierung ersetzt. Wenn die Eingabe als absoluter Systempfad geeignet ist, wird dieser Algorithmus leicht erweitert: der Pfad zum Wurzelverzeichnis »/« wird als einzelner Bindestrich »-« kodiert. Zusätzlich werden alle führenden, abschließenden oder doppelten »/« Zeichen vor der Umwandlung aus der Zeichenkette entfernt. Beispiel: /foo//bar/baz/ wird »foo-bar-baz«. Diese Maskierung ist komplett umkehrbar, solange bekannt ist, ob die maskierte Zeichenkette ein Pfad war (die demaskierten Ergebnisse unterscheiden sich für Pfad- und Nichtpfadzeichenketten). Verwenden Sie systemd-escape --path, um Pfade zu maskieren und andernfalls systemd-escape ohne --path.AUTOMATISCHE ABHÄNGIGKEITEN
Implizite Abhängigkeiten
Eine Reihe von Unit-Abhängigkeiten werden implizit aufgebaut, abhängig vom Unit-Typ und der Unit-Konfiguration. Diese impliziten Abhängigkeiten können die Unit-Konfiguration erleichtern. Bitte lesen Sie den Abschnitt »Implizite Abhängigkeiten« in der Handbuchseite des jeweiligen Unit-Typs. Beispielsweise erlangen Dienste-Units mit Type=dbus automatisch Abhängigkeiten vom Typ Requires= und After= von dbus.socket. Siehe systemd.service(5) für Details.Standardabhängigkeiten
Standardabhängigkeiten sind ähnlich impliziten Abhängigkeiten, können aber durch Setzen von DefaultDependencies= auf yes (die Vorgabe) und no an- und abgeschaltet werden, während implizite Abhängigkeiten immer wirksam sind. Siehe Abschnitt »Standard-Abhängigkeiten« in den jeweiligen Handbuchseiten für den Effekt der Aktivierung von DefaultDependencies= in jedem Unit-Typ. Beispielsweise werden Ziel-Units alle konfigurierten Abhängigkeiten des Typs Wants= oder Requires= mit Abhängigkeiten vom Typ After= ergänzen. Siehe systemd.target(5) für Details. Beachten Sie, dass dieses Verhalten durch Setzen von DefaultDependencies=no in den festgelegten Units abgewählt werden kann. Es kann auch gezielt über eine explizite Abhängigkeit Before= außer Kraft gesetzt werden.UNIT-DATEI-LADEPFAD
Unit-Dateien werden von einer Reihe von Pfaden geladen, die während der Kompilierung bestimmt werden, wie dies in den zwei Tabellen unten beschrieben ist. Unit-Dateien, die in früher aufgeführten Verzeichnissen gefunden werden, setzen Dateien mit dem gleichen Namen in Verzeichnissen, die weiter unten in der Liste aufgeführt sind, außer Kraft. Wenn die Variable $SYSTEMD_UNIT_PATH gesetzt ist, setzt der Inhalt dieser Variable den Unit-Ladepfad außer Kraft. Falls $SYSTEMD_UNIT_PATH mit einer leeren Komponente (»:«) endet, wird der normale Unit-Ladepfad an den Inhalt der Variablen angehängt.| Pfad | Beschreibung |
| /etc/systemd/system.control | Mittels Dbus-API erstellte dauerhafte und flüchtige Konfiguration |
| /run/systemd/system.control | |
| /run/systemd/transient | Dynamische Konfiguration für flüchtige Units |
| /run/systemd/generator.early | Erstellte Units mit hoher Priorität (siehe early-dir in systemd.generator(7)) |
| /etc/systemd/system | System-Units, die vom Administrator erstellt wurden |
| /run/systemd/system | Laufzeit-Units |
| /run/systemd/generator | Erstellte Units mit mittlerer Priorität (siehe normal-dir in systemd.generator(7)) |
| /usr/local/lib/systemd/system | System-Units, die vom Administrator installiert wurden |
| /lib/systemd/system | System-Units, die durch den Paketverwalter der Distribution installiert wurden |
| /run/systemd/generator.late | Erstellte Units mit niedriger Priorität (siehe late-dir in systemd.generator(7)) |
| Pfad | Beschreibung |
| $XDG_CONFIG_HOME/systemd/user.control oder ~/.config/systemd/user.control | Dauerhafte und flüchtige Konfiguration, die mittels des DBus-APIs erstellt wird (( $XDG_CONFIG_HOME wird verwandt, falls gesetzt, andernfalls ~/.config) |
| $XDG_RUNTIME_DIR/systemd/user.control | |
| $XDG_RUNTIME_DIR/systemd/transient | Dynamische Konfiguration für flüchtige Units |
| $XDG_RUNTIME_DIR/systemd/generator.early | Erstellte Units mit hoher Priorität (siehe early-dir in systemd.generator(7)) |
| $XDG_CONFIG_HOME/systemd/user oder $HOME/.config/systemd/user | Benutzerkonfiguration ($XDG_CONFIG_HOME wird verwandt, falls gesetzt, andernfalls ~/.config) |
| $XDG_CONFIG_DIRS/systemd/user oder /etc/xdg/systemd/user | Zusätzliche Konfigurationsverzeichnisse, wie diese durch die XDG-Basisverzeichnis-Spezifikation festgelegt werden ( $XDG_CONFIG_DIRS wird verwandt, falls gesetzt, andernfalls /etc/xdg) |
| /etc/systemd/user | Benutzer-Units, die vom Administrator erstellt wurden |
| $XDG_RUNTIME_DIR/systemd/user | Laufzeit-Units (nur verwandt, falls $XDG_RUNTIME_DIR gesetzt ist) |
| /run/systemd/user | Laufzeit-Units |
| $XDG_RUNTIME_DIR/systemd/generator | Erstellte Units mit mittlerer Priorität (siehe normal-dir in systemd.generator(7)) |
| $XDG_DATA_HOME/systemd/user oder $HOME/.local/share/systemd/user | Units von Paketen, die im Home-Verzeichnis installiert wurden ($XDG_DATA_HOME wird verwandt, falls gesetzt, andernfalls ~/.local/share) |
| $XDG_DATA_DIRS/systemd/user oder /usr/local/share/systemd/user und /usr/share/systemd/user | Zusätzliche Datenverzeichnisse, wie diese durch die XDG-Basisverzeichnis-Spezifikation festgelegt werden ( $XDG_DATA_DIRS wird verwandt, falls gesetzt, andernfalls /usr/local/share und /usr/share) |
| $dir/systemd/user für jedes $dir in $XDG_DATA_DIRS | Zusätzliche Orte für installierte Benutzer-Units, einen für jeden Eintrag in $XDG_DATA_DIRS |
| /usr/local/lib/systemd/user | Benutzer-Units, die durch den Administrator installiert wurden |
| /usr/lib/systemd/user | Benutzer-Units, die durch den Paketverwalter der Distribution installiert wurden |
| $XDG_RUNTIME_DIR/systemd/generator.late | Erstellte Units mit niedriger Priorität (siehe late-dir in systemd.generator(7)) |
systemd-analyze --user unit-paths
UNIT-MÜLLABFUHR
Der System- und Diensteverwalter lädt die Konfiguration einer Unit automatisch, wenn die Unit das erste Mal referenziert wird. Er wird die Unit-Konfiguration und den Zustand wieder entladen, wenn die Unit nicht mehr benötigt wird (»Müllabfuhr«). Eine Unit kann über eine Reihe von Mechanismen referenziert werden: 1.Eine andere geladene Unit referenziert sie
mit einer Abhängigkeit wie After=, Wants=, …
2.Die Unit startet, läuft, startet
sich neu oder stoppt derzeit.
3.Die Unit ist derzeit im Zustand
failed. (Siehe aber unten.)
4.Ein Auftrag für die Unit ist
anhängig.
5.Die Unit ist durch ein aktives
IPC-Client-Programm verankert.
6.Die Unit ist eine besondere
»ewige« Unit, die immer aktiv und geladen ist. Beispiele
für ewige Units sind die Wurzeleinhänge-Unit -.mount und die
Bereichs-Unit init.scope, in der der Diensteverwalter selbst lebt.
7.Die Unit hat ihr zugeordnete laufende
Prozesse.
Die Müllabfuhrlogik kann mit der Option CollectMode=
verändert werden. Diese Option erlaubt die Konfiguration, ob
automatisches Entladen von Units, die im Zustand failed sind, erlaubt
ist, siehe unten.
Beachten Sie, dass beim Entladen der Konfiguration und des Zustandes einer Unit
alle Ausführungsergebnisse, wie Exit-Codes, Exit-Signale und
Resourcenverbrauch- und andere Statistiken, verloren gehen, außer
für den Anteil, der im Protokolluntersystem gespeichert ist.
Verwenden Sie systemctl daemon-reload oder einen äquivalenten
Befehl, um die Unit-Konfiguration neu zu laden, während die Unit
bereits geladen ist. In diesem Fall werden alle Konfigurationseinstellungen
rausgeschoben und durch die neue Konfiguration ersetzt (die allerdings nicht
sofort in Kraft sein muss), allerdings wird sämtlicher Laufzeitzustand
gespeichert/wiederhergestellt.
[UNIT]-ABSCHNITT-OPTIONEN
Die Unit-Datei kann einen Abschnitt [Unit] enthalten, der generische Informationen über die Unit transportiert, der nicht vom Unit-Typ abhängt: Description=Ein kurzer menschenlesbarer Titel für
die Unit. Dieser kann von systemd (und anderen
Benutzeroberflächen) als eine für den Benutzer sichtbare
Bezeichnung für die Unit verwandt werden, daher sollte diese
Zeichenkette die Unit identifizieren, statt sie zu beschreiben, trotz des
Namens. Diese Zeichenkette sollte auch nicht nur einfach den Unit-Namen
wiederholen. »Apache2 Webserver« ist ein gutes Beispiel.
Schlechte Beispiele sind »leichtgewichtiger
Hochleistungs-HTTP-Server« (zu generisch) oder »Apache2«
(für Leute, die Apache nicht kennen, bedeutungslos, wiederholt den
Namen der Unit). systemd kann dies als Substantiv in Statusnachrichten
(»Starting description...«, »Started
description.«, »Reached target
description.«, »Failed to start
description.«) verwenden, daher sollte er groß
geschrieben werden und kein vollständiger Satz oder eine Phrase mit
einem kontinuierlichen Verb sein. Schlechte Beispiele sind auch
»exiting the container« oder »updating the database once
per day.«.
Documentation=
Eine Leerraum-getrennte Liste von URIs, die
Dokumentation für diese Unit oder ihre Konfiguration referenzieren. Es
werden nur URIs von den Typen »http://«,
»https://«, »file:«, »info:«,
»man:« akzeptiert. Für weitere Informationen über
die Syntax dieser URIs siehe uri(7). Die URIs sollten in der
Reihenfolge der Bedeutung aufgeführt werden, beginnend mit der
relevantesten. Es ist eine gute Idee, zuerst Dokumentation zu referenzieren,
die erklärt, was der Zweck der Unit ist, gefolgt von solcher
über seine Konfiguration, gefolgt von anderer relevanter Dokumentation.
Diese Option kann mehr als einmal angegeben werden, in diesem Fall werden die
festgelegten Listen von URIs zusammengeführt. Falls dieser Option die
leere Zeichenkette zugewiesen wird, wird die Liste zurückgesetzt und
alle vorherigen Zuweisungen werden keinen Effekt haben.
Wants=
Konfiguriert (schwache)
Anforderungsabhängigkeiten auf andere Units. Diese Option darf mehr als
einmal angegeben werden oder mehrere, durch Leerraum getrennte Units
können in einer Option angegeben werden, in diesem Fall werden
Abhängigkeiten für alle aufgeführten Namen erstellt.
Abhängigkeiten dieses Typs können auch außerhalb von
Unit-Konfigurationsdateien hinzugefügt werden, indem ein Symlink auf
ein die Unit-Datei begleitendes .wants/-Verzeichnis hinzugefügt wird.
Siehe oben für Details.
In dieser Option aufgeführte Units werden gestartet, wenn die
konfigurierende Unit es wird. Falls allerdings die aufgeführte Unit
nicht startet oder der Transaktion nicht hinzugefügt werden kann, hat
dies keine Auswirkungen auf die Gültigkeit der Transaktion als Ganzes
und diese Unit wird dennoch gestartet. Dies ist die empfohlene Art, das
Starten einer Unit in den Start einer anderen Unit einzuhängen.
Beachten Sie, dass Anforderungsabhängigkeiten nicht die Reihenfolge
beeinflussen, in der Dienste gestartet oder gestoppt werden. Dies muss
unabhängig davon mit den Optionen After= oder Before=
konfiguriert werden. Falls die Unit foo.service die Unit bar.service wie mit
Wants= konfiguriert hereinzieht und mit After= oder
Before= keine Ordnung konfiguriert ist, dann werden beide Units
gleichzeitig und ohne Verzögerung untereinander gestartet, wenn
foo.service aktiviert wird.
Requires=
Ähnlich Wants=, erklärt
aber eine stärkerere Anforderungsabhängigkeit.
Abhängigkeiten dieser Art können auch außerhalb der
Unit-Konfigurationsdatei konfiguriert werden, indem ein Symlink auf ein die
Unit-Datei begleitendes .requires/-Verzeichnis hinzugefügt wird.
Falls diese Unit aktiviert wird, werden die aufgeführten Units ebenfalls
aktiviert. Falls die Aktivierung einer der anderen Units fehlschlägt
und eine Ordnungsabhängigkeit After= auf die fehlgeschlagene
Unit gesetzt ist, dann wird diese Unit nicht gestartet. Darüberhinaus
wird diese Unit gestoppt (oder neu gestartet), falls eine der anderen Units
explizit gestoppt (oder neu gestartet) wird, unahängig davon, ob
After= gesetzt ist oder nicht.
Oft ist es eine bessere Wahl, Wants= statt Requires= zu verwenden,
um ein System zu erreichen, das im Umgang mit fehlschlagenden Diensten
robuster ist.
Beachten Sie, dass dieser Abhängigkeitstyp nicht impliziert, dass andere
Units immer im aktiven Zustand sein müssen, wenn diese Unit
läuft. Insbesondere: Fehlschlagende
Bedingungsüberprüfungen (wie ConditionPathExists=,
ConditionPathIsSymbolicLink=, … — siehe unten)
führen nicht dazu, dass der Start einer Unit mit einer
Requires=-Abhängigkeit darauf fehlschlägt. Auch
können sich einige Unit-Typen von selbst deaktivieren (beispielsweise
kann sich ein Diensteprozess entscheiden, sich sauber zu beenden, oder ein
Gerät könnte von einem Benutzer ausgesteckt werden), was nicht
an die Units mit einer Requires=-Abhängigkeit übertragen
wird. Verwenden Sie den Abhängigkeitstyp BindsTo= zusammen mit
After=, um sicherzustellen, dass sich eine Unit niemals im aktiven
Zustand befindet, ohne dass eine andere Unit sich auch in einem aktiven
Zustand befindet (siehe unten).
Requisite=
Ähnlich zu Requires=. Falls die
hier aufgeführten Units noch nicht gestartet wurden, werden sie nicht
gestartet und der Start dieser Unit wird sofort fehlschlagen.
Requisite= impliziert keine Ordnungsabhängigkeit, selbst falls
beide Units in der gleichen Transaktion gestartet werden. Daher sollte diese
Einstellung normalerweise mit After= kombiniert werden, um
sicherzustellen, dass diese Unit nicht vor der anderen Unit gestartet wird.
Wenn Requisite=b.service auf a.service benutzt wird, wird diese
Abhängigkeit als RequisiteOf=a.service in der Eigenschaftsliste
von b.service angezeigt. RequisiteOf=-Abhängigkeiten
können nicht direkt festgelegt werden.
BindsTo=
Konfiguriert
Anforderungsabhängigkeiten, im Stil sehr ähnlich zu
Requires=. Allerdings ist dieser Abhängigkeitstyp
stärker: Zusätzlich zu dem Effekt von Requires=
deklariert er, dass beim Stoppen der gebundenen Unit auch diese Unit gestoppt
wird. Das bedeutet, dass eine Unit, die an eine andere Unit gebunden ist, die
plötzlich in einen inaktiven Zustand eintritt, auch gestoppt wird.
Units können plötzlich und unerwartet aus verschiedenen
Gründen in inaktive Zustände eintreten: Der Hauptprozess einer
Dienste-Unit könnte sich aus eigenem Antrieb beenden, das
zugrundeliegende Gerät einer Geräte-Unit könnte
ausgesteckt werden oder der Einhängepunkt einer Einhänge-Unit
könnte ohne Beteiligung des System- und Diensteverwalters
ausgehängt werden.
Bei der Verwendung in Verbindung mit After= auf die gleiche Unit ist das
Verhalten von BindsTo= sogar noch stärker. In diesem Falle muss
die angebundene Unit sogar in einem aktiven Zustand sein, damit diese Unit
auch in einem aktiven Zustand ist. Dies bedeutet nicht nur, dass eine Unit,
die an eine andere Unit angebunden ist, die plötzlich in einen
inaktiven Zustand eintritt, sondern auch, die an eine andere Unit angebunden
ist, die aufgrund einer nicht erfüllten Bedingungsprüfung (wie
ConditionPathExists=, ConditionPathIsSymbolicLink=, … \n
siehe unten) übersprungen wird, gestoppt wird, sollte sie laufen. Daher
ist es in vielen Fällen am besten, BindsTo= mit After= zu
kombinieren.
Wenn BindsTo=b.service auf a.service benutzt wird, wird diese
Abhängigkeit als BoundBy=a.service in der Eigenschaftsliste von
b.service angezeigt. BoundBy=-Abhängigkeiten können nicht
direkt festgelegt werden.
PartOf=
Konfiguriert Abhängigkeiten
ähnlich zu Requires=, aber begrenzt auf das Stoppen und
Neustarten von Units. Wenn Systemd die hier aufgeführten Units stoppt
oder neustartet, wird die Aktion zu dieser Unit weitergeleitet. Beachten Sie,
dass dies eine Einwegeabhängigkeit ist — Änderungen an
dieser Unit betreffen nicht die aufgeführten Units.
Wenn PartOf=b.service auf a.service benutzt wird, wird diese
Abhängigkeit als ConsistsOf=a.service in der Eigenschaftsliste
von b.service angezeigt. ConsistsOf=-Abhängigkeiten
können nicht direkt festgelegt werden.
Upholds=
Konfiguriert Abhängigkeiten
ähnlich wie Wants=, aber alle in Upholds=
aufgeführten Units starten immer, wenn sie als inaktiv oder
fehlgeschlagen erkannt werden und für sie kein Auftrag in der
Warteschlange ist so lange diese Unit aktiv ist. Während eine
Abhängigkeit Wants= auf eine andere Unit eine einmalige
Auswirkung hat, wenn diese Unit gestartet wird, hat eine Abhängigkeit
Upholds= eine dauerhafte Auswirkung, fortwährend die Unit
neustartend, falls notwendig. Dies ist eine Alternative zu der Einstellung
Restart= von Dienste-Units, um sicherzustellen, dass sie am Laufen
gehalten werden, was auch immer passiert.
Wenn Upholds=b.service auf a.service benutzt wird, wird diese
Abhängigkeit als UpheldBy=a.service in der Eigenschaftsliste von
b.service angezeigt. Die UpheldBy=-Abhängigkeit kann nicht
direkt festgelegt werden.
Conflicts=
Eine Leerraum-getrennte Liste von Unit-Namen.
Konfiguriert negative Anforderungsabhängigkeiten. Falls eine Unit eine
Einstellung Conflicts= auf eine andere Unit hat, wird das Starten
ersterer die letzere stoppen und umgekehrt.
Beachten Sie, dass diese Einstellung keine Ordnungsabhängigkeit
impliziert, ähnlich der vorher beschriebenen Abhängigkeiten
Wants= und Requires=. Das bedeutet, dass eine
Abhängigkeit After= oder Before= erklärt werden
muss, um sicherzustellen, dass die in Konflikt stehende Unit gestoppt wird,
bevor die andere Unit gestartet wird. Es spielt keine Rolle, welche der
Ordnungsabhängigkeiten verwandt wird, da Stopp-Aufträge immer
vor Start-Aufträgen sortiert werden, siehe die nachfolgende Diskussion
von Before=/After=.
Falls Unit A, die in Konflikt zu Unit B steht, zum gleichzeitigen Start mit B
eingeplant ist, wird die Transaktion entweder fehlschlagen (falls beide
benötigte Teile der Transaktion sind) oder so verändert, dass
dies behoben wird (falls eine oder beide Aufträge ein nicht
benötigter Teil der Transaktion sind). In letzterem Fall wird der
Auftrag, der nicht benötigt ist, entfernt, oder falls beide nicht
benötigt werden, wird die den Konflikt auslösende Unit gestartet
und die in Konflikt stehende gestoppt.
Before=, After=
Diese beiden Einstellungen erwarten eine
Leerraum-getrennte Liste von Unit-Namen. Sie können mehrfach angegeben
werden, wodurch Abhängigkeiten für alle aufgeführten
Namen erstellt werden.
Diese zwei Einstellungen konfigurieren Ordnungsabhängigkeiten zwischen
Units. Falls Unit foo.service die Einstellung Before=bar.service
enthält und beide Units gestartet werden, wird das Starten von
bar.service verzögert, bis der Start von foo.service abgeschlossen ist.
After= ist das Inverse von Before=, d.h. während
Before= sicherstellt, dass die konfigurierte Unit gestartet wird, bevor
die aufgeführten Unit mit dem Starten beginnt, stellt After= das
Gegenteil sicher, dass die aufgeführte Unit vollständig
gestartet ist, bevor die konfigurierte Unit gestartet wird.
Beim Herunterfahren von zwei Units, zwischen denen eine
Ordnungsabhängigkeit besteht, das Inverse der Start-Reihenfolge
angewandt wird. Dies bedeutet, falls eine Unit mit After= auf eine
andere Unit konfiguriert ist, wird die erstere vor letzterer gestoppt, falls
beide heruntergefahren werden. Existiert zwischen zwei Units eine
Ordnungsabhängigkeit und wird eine Unit gestoppt und die andere
gestartet, dann wird das Herunterfahren vor dem Hochfahren einsortiert. Dabei
spielt es in diesem Fall keine Rolle, ob die Ordnungsabhängigkeit
After= oder Before= ist. Es spielt auch keine Rolle, welcher der
beiden heruntergefahren wird, solange eine heruntergefahren und die andere
gestartet wird. Das Herunterfahren wird in allen Fällen vor dem Starten
eingeordnet. Falls zwischen zwei Units keine Ordnungsabhängigkeit
besteht, dann werden sie gleichzeitig heruntergefahren und gestartet und es
findet keine Ordnung statt. Es hängt vom Unit-Typ ab, wann genau der
Start einer Unit abgeschlossen ist. Am wichtigsten ist, dass für
Dienste-Units das Starten für die Zwecke von
Before=/After= als abgeschlossen betrachtet wird, wenn alle ihre
konfigurierten Startbefehle aufgerufen wurden und entweder fehlschlugen oder
Erfolg meldeten. Beachten Sie, dass dies ExecStartPost
einschließt (oder ExecStopPost für den
Herunterfahr-Fall).
Beachten Sie, dass diese Einstellungen unabhängig von und orthogonal zu
den mit Requires=, Wants=, Requisite= oder
BindsTo= konfigurierten Anforderungsabhängigkeit sind. Es ist
ein häufiges Muster, einen Unit-Namen sowohl in die Optionen
After= als auch in WantWants= aufzunehmen; in diesem Fall wird
die aufgeführte Unit vor der Unit, die mit diesen Optionen konfiguriert
ist, gestartet.
Beachten Sie, dass Before=-Abhängigkeiten für
Geräte-Units nicht wirksam sind und nicht unterstützt werden.
Geräte werden im Allgemeinen aufgrund externer Einsteck-Ereignisse
verfügbar und Systemd erstellt die entsprechende Geräte-Unit
unverzüglich.
OnFailure=
Eine Leerraum-getrennte Liste einer oder
mehrerer Units, die aktiviert werden, wenn diese Unit den Zustand
»failed« einnimmt. Eine Dienste-Unit, die Restart=
verwendet, nimmt den fehlgeschlagenen Zustand nur an, nachdem die
Startbegrenzung erreicht wurde.
OnSuccess=
Eine Leerraum-getrennte Liste einer oder
mehrerer Units, die aktiviert werden, wenn diese Unit den Zustand
»inactive« einnimmt.
PropagatesReloadTo=, ReloadPropagatedFrom=
Eine Leerraum-getrennte Liste einer oder
mehrerer Units, an die Neuladeanforderungen ausgebreitet werden sollen bzw.
Units, von denen Neuladeanforderungen an diese Unit ausgebereitet werden
sollen. Erteilen einer Neuladeanforderung an eine Unit, wird auch eine
Neuladeanforderungen an alle Units, die mittels dieser zwei Einstellungen
damit verlinkt sind, in die Warteschlange einstellen.
PropagatesStopTo=, StopPropagatedFrom=
Eine Leerraum-getrennte Liste einer oder
mehrerer Units, an die Stop-Aufforderungen ausgebreitet werden sollen bzw.
Units, von denen Stop-Aufforderungen an diese Unit ausgebereitet werden
sollen. Erteilen einer Stop-Aufforderungen an eine Unit, wird auch eine
Stop-Aufforderungen an alle Units, die mittels dieser zwei Einstellungen damit
verlinkt sind, in die Warteschlange einstellen.
JoinsNamespaceOf=
Für Units, die Prozesse starten (wie
Dienste-Units) werden hier eine oder mehrere andere Units aufgeführt,
dessen Netzwerk- oder temporärem Namensraum beigetreten werden soll.
Dies gilt nur für Unit-Typen, die die Anweisungen
PrivateNetwork=, NetworkNamespacePath=PrivateIPC=,
IPCNamespacePath= und PrivateTmp= unterstützen (siehe
systemd.exec(5) für Details). Falls eine Unit, die diese
Einstellung hat, gestartet wird, werden deren Prozesse die gleichen /tmp/-,
/var/tmp/-, IPC- und Netzwerk-Namensräume wie die aufgeführte
gestartete Unit haben. Falls mehrere aufgeführte Units bereits
gestartet sind, ist nicht definiert, welchem Namensraum beigetreten wird.
Beachten Sie, dass diese Einstellung nur Wirkung zeigt, falls
PrivateNetwork=/ NetworkNamespacePath=,
PrivateIPC=/IPCNamespacePath= und/oder PrivateTmp=
für sowohl die Unit, die dem Namensraum beitritt, als auch die Unit,
deren Namensraum beigetreten wird, aktiviert ist.
RequiresMountsFor=
Akzeptiert eine Leerraum-getrennte Liste
absoluter Pfade. Fügt automatisch Abhängigkeiten vom Typ
Requires= und After= für alle für den Zugriff auf
den angegebenen Pfad benötigten Einhänge-Units hinzu.
Mit noauto markierte Einhängepunkte werden nicht durch
local-fs.target automatisch eingehängt, werden für den Zweck
dieser Option aber weiterhin berücksichtigt, d.h. sie werden von dieser
Unit hereingezogen.
OnFailureJobMode=
Akzeptiert einen Wert aus
»fail«, »replace«,
»replace-irreversibly«, »isolate«,
»flush«, »ignore-dependencies«,
»ignore-requirements«. Standardmäßig
»replace«. Gibt an, wie die in OnFailure=
aufgeführten Units in die Warteschlange eingestellt werden. Siehe die
Option --job-mode= von systemctl(1) für Details
über die möglichen Werte. Falls dies auf »isolate«
gesetzt ist, darf in OnFailure= nur eine einzelne Unit
aufgeführt werden.
IgnoreOnIsolate=
Akzeptiert ein logisches Argument. Falls
true, wird die Unit nicht gestoppt, wenn eine andere Unit isoliert
wird. Standardmäßig false für Dienste-, Ziel-,
Socket-, Timer- und Pfad-Units und true für Scheiben-,
Bereichs-, Geräte-, Swap-, Einhänge- und Automount-Units.
StopWhenUnneeded=
Akzeptiert ein logisches Argument. Falls
true, wird diese Unit gestoppt, wenn sie nicht mehr benutzt wird.
Beachten Sie, dass Systemd standardmäßig Units nicht stoppt,
außer sie stehen in Konflikt zu anderen Units oder der Benutzer bittet
explizit um ihr Herunterfahren, um die auszuführende Arbeit zu
minimieren. Falls diese Option gesetzt ist, wird eine Unit automatisch
bereinigt, falls keine andere aktive Unit sie benötigt.
Standardmäßig false.
RefuseManualStart=, RefuseManualStop=
Akzeptiert ein logisches Argument. Falls
true, kann diese Unit nur indirekt aktiviert oder deaktiviert werden.
In diesem Fall werden direkte Start- oder Beendigungs-Anfragen des Benutzers
zurückgewiesen, erfolgt das Starten oder Beenden allerdings als
Abhängigkeit von einer anderen Unit, dann wird das Starten oder Beenden
erfolgreich sein. Dies ist primär eine
Sicherheitsfunktionalität, um sicherzustellen, dass der Benutzer nicht
versehentlich Units aktiviert, die nicht für direkte Aktivierung
gedacht sind und nicht versehentlich Units deaktiviert, die nicht zur
Beendigung gedacht sind. Diese Option ist standardmäßig
false.
AllowIsolate=
Akzeptiert ein logisches Argument. Falls
true, darf diese Unit mit dem Befehl systemctl isolate verwandt
werden. Andernfalls wird dies zurückgewiesen. Es ist wahrscheinlich
eine gute Idee, dies außer für Ziel-Units, die ähnlich
wie Runlevel in SysV-Init-Systemen verwandt werden sollen, deaktiviert zu
lassen, nur als Vorsichtsmaßnahme, um unbenutzbare
Systemzustände zu vermeiden. Diese Option ist
standardmäßig false.
DefaultDependencies=
Akzeptiert ein logisches Argument. Falls
yes (die Vorgabe), werden einige Standard-Abhängigkeiten
implizit für die Unit erstellt. Die tatsächlich erstellten
Abhängigkeiten hängen vom Unit-Typ ab. Für Dienste-Units
stellen diese Abhängigkeiten beispielsweise sicher, dass der Dienst
erst gestartet wird, nachdem die grundlegende System-Initialisierung
abgeschlossen ist und dass er korrekt beim System-Herunterfahren beendet wird.
Siehe die jeweilige Handbuchseite für Details. Im Allgemeinen sollten
nur Dienste, die im frühen Systemstart oder beim späten
Herunterfahren beteiligt sind, diese Option auf no setzen. Es wird
nachdrücklich empfohlen, diese Option für den Großteil
der häufigen Units aktiviert zu lassen. Falls auf no gesetzt,
deaktiviert diese Option nicht alle impliziten Abhängigkeiten, sondern
nur nicht essenzielle.
CollectMode=
Optimiert den Algorithmus der
»Müllabfuhr« für diese Unit. Akzeptiert entweder
inactive oder inactive-or-failed. Falls auf inactive
gesetzt, wird die Unit entladen, falls sie im Zustand inactive ist und
von keinen Clients, Aufträgen oder anderen Units referenziert wird;
allerdings wird sie nicht entladen, wenn sie im Modus failed ist. Im
Modus failed werden fehlgeschlagene Units nicht entladen, bis der
Benutzer systemctl reset-failed oder einen äquivalenten Befehl
auf ihnen aufruft, um den Zustand failed zurückzusetzen. Dieses
Verhalten wird geändert, falls die Option auf inactive-or-failed
gesetzt wird: in diesem Fall wird die Unit entladen, selbst falls die Unit im
Zustand failed ist und daher ist ein explizites Zurücksetzen des
Zustands failed nicht notwendig. Beachten Sie, dass Unit-Ergebnisse
(wie Exit-Codes, Exit-Signale, verbrauchte Ressourcen, …) sofort nach
Abschluss der Units entsorgt werden, außer dem Anteil, der im
Protokollieruntersystem gespeichert ist, falls dieser Modus verwandt wird.
Standardmäßig inactive.
FailureAction=, SuccessAction=
Konfiguriert die durchzuführende
Aktion, wenn die Unit stoppt und in einen Fehlzustand oder inaktiven Zustand
eintritt. Akzeptiert entweder none, reboot, reboot-force,
reboot-immediate, poweroff, poweroff-force,
poweroff-immediate, exit oder exit-force. Im Systemmodus
sind alle Optionen erlaubt. Im Benutzermodus sind nur none, exit
und exit-force erlaubt. Beide Optionen sind standardmäßig
none.
Falls none gesetzt ist, wird keine Aktion ausgelöst. reboot
verursacht einen Neustart nach der normalen Herunterfahrprozedur (d.h.
äquivalent zu systemctl reboot). reboot-force
führt zu einem erzwungenen Neustart, der alle Prozesse zwangsweise
beenden wird, aber beim Neustart kein unsauberes Dateisystem erzeugen sollte
(d.h. äquivalent zu systemctl reboot -f) und
reboot-immediate führt zu einer sofortigen Ausführung des
Systemaufrufs reboot(2), was zu Datenverlust führen kann (d.h.
äquivalent zu systemctl reboot -ff). Ähnlich haben
poweroff, poweroff-force, poweroff-immediate die Wirkung
des Herunterfahrens des Systems mit ähnlichen Semantiken. exit
führt dazu, dass sich der Verwalter beendet, wobei er der normalen
Herunterfahrprozedur folgt, und exit-force führt dazu, dass er
sich ohne Herunterfahren der Dienste beendet. Wenn exit oder
exit-force verwandt werden, wird standardmäßig der
Exit-Status des Hauptprozesses der Unit (falls dies zutrifft) vom
Diensteverwalter zurückgeliefert. Dies kann allerdings mit
FailureActionExitStatus=/ SuccessActionExitStatus= außer
Kraft gesetzt werden, siehe unten.
FailureActionExitStatus=, SuccessActionExitStatus=
Steuert den Exit-Status, der an den
Container-Verwalter zurückgeleitet werden soll (im Falle von
Systemdiensten) oder dem Diensteverwalter (im Falle eines Benutzerverwalters),
wenn die FailureAction=/SuccessAction= auf exit oder
exit-force gesetzt sind und die Aktion ausgelöst wird.
Standardmäßig wird der Exit-Status des Hauptprozesses der
auslösenden Unit (falls dies zutrifft) weitergeleitet. Akzeptiert einen
Wert im Bereich 0…255 oder die leere Zeichenkette, um das
Standardverhalten zu erbitten.
JobTimeoutSec=, JobRunningTimeoutSec=
JobTimeoutSec= legt eine
Zeitüberschreitung für den gesamten Auftrag fest, dessen
Ausführung beginnt, wenn der Auftrag in die Warteschlange eingereiht
wird. JobRunningTimeoutSec= legt eine Zeitüberschreitung fest,
dessen Ausführung beginnt, wenn der Auftrag in der Warteschlange
tatsächlich gestartet wird. Falls eine der beiden Begrenzungen erreicht
wird, wird der Auftrag abgebrochen, die Unit wird allerdings ihren Zustand
weder ändern noch in den Modus »failed« eintreten.
Beide Einstellungen akzeptieren eine Zeitdauer mit der Vorgabeeinheit Sekunden,
aber andere Einheiten können angegeben werden, siehe
systemd.time(5). Die Vorgabe ist »infinity«
(Auftragszeitüberschreitungen sind deaktiviert), außer
für Geräte-Units, bei denen standardmäßig
JobRunningTimeoutSec= auf DefaultTimeoutStartSec= gesetzt ist.
Hinweis: Diese Zeitüberschreitungen sind unabhängig von allen
Unit-spezifischen Zeitüberschreitungen (beispielsweise den mit
TimeoutStartSec= in Dienste-Units gesetzten
Zeitüberschreitungen). Die Auftragszeitüberschreitung hat keine
Wirkung für die Unit selbst. Oder mit anderen Worten: Unit-spezifische
Zeitüberschreitungen sind nützlich, um Zustandsänderungen
von Units abzubrechen und sie zurückzunehmen. Die mit dieser Option
gesetzten Auftrags-Zeitüberschreitungen sind allerdings nur
nützlich, um den Auftrag abzubrechen, der darauf wartet, dass die Unit
den Zustand ändert.
JobTimeoutAction=, JobTimeoutRebootArgument=
JobTimeoutAction= konfiguriert optional
eine zusätzliche Aktion, die beim Erreichen der
Zeitüberschreitung unternommen werden soll, siehe die Beschreibung von
JobTimeoutSec= und JobRunningTimeoutSec= oben. Es akzeptiert die
gleichen Werte wie StartLimitAction=. Standardmäßig
none.
JobTimeoutRebootArgument= konfiguriert eine optionale
Neustartzeichenkette, die an den Systemaufruf reboot(2)
übergeben wird.
StartLimitIntervalSec=Intervall,
StartLimitBurst=Häufung
Konfiguriert die Unit-Startraten-Begrenzung.
Units, die häufiger als Häufung innherhalb der Zeitdauer
Intervall gestartet werden, wird kein weiterer Start erlaubt. Verwenden
Sie StartLimitIntervalSec=, um das Überprüfungsintervall
zu konfigurieren und StartLimitBurst=, um zu konfigurieren, wie viele
Starts pro Intervall erlaubt sind.
Intervall ist eine Zeitdauer in der Standardeinheit Sekunden, aber andere
Einheiten können angegeben werden, siehe systemd.time(5).
Standardmäßig DefaultStartLimitIntervalSec= in der
Verwalterkonfigurationsdatei und kann auf 0 gesetzt werden, um jegliche Art
von Ratenbegrenzung zu deaktivieren. Häufung ist eine Zahl, die
in der Verwalterkonfigurationsdatei standardmäßig
DefaultStartLimitBurst= ist.
Diese Konfigurationsoptionen sind insbesondere im Zusammenspiel mit der
Diensteeinstellung Restart= nützlich (siehe
systemd.service(5)); allerdings gelten sie für alle Arten von
Starts (einschließlich manueller), nicht nur denen, die von der
Restart=-Logik ausgelöst werden.
Beachten Sie, dass nicht versucht wird, Units, die für Restart=
konfiguriert ist und die die Startbegrenzung erreichen, weiterhin zu starten;
allerdings können sie zu einem späteren Zeitpunkt noch manuell
oder von einem Timer oder Socket gestartet werden, nachdem das
Intervall abgelaufen ist. Von diesem Zeitpunkt an ist die Neustartlogik
wieder aktiviert. systemctl reset-failed führt dazu, dass der
Neustartratenzähler für einen Dienst gelöscht wird, was
nützlich ist, wenn der Administrator eine Unit manuell starten
möchte und die Startbegrenzung damit in die Quere kommt.
Ratenbegrenzung wird durchgesetzt, nachdem alle
Unit-Bedingungsprüfungen ausgeführt wurden. Daher zählen
für die Ratenbegrenzung Unit-Aktivierungen mit fehlgeschlagenen
Bedingungen nicht mit.
Wenn eine Unit aufgrund der Müllabführlogik entladen wird (siehe
oben) werden auch ihre Ratenbegrenzungszähler entleert. Das bedeutet,
dass die Konfiguration einer Startratenbegrenzung für eine Unit, die
nicht kontinuierlich referenziert wird, keine Wirkung hat.
Diese Einstellung gilt nicht für Scheiben-, Ziel-, Geräte- und
Bereichs-Units, da dies Unit-Typen sind, deren Aktivierung entweder nie
fehlschlagen oder nur ein einziges Mal erfolgreich sein darf.
StartLimitAction=
Konfiguriert eine zusätzliche Aktion,
die ergriffen werden soll, falls die mit StartLimitIntervalSec= und
StartLimitBurst= konfigurierte Ratenbegrenzung erreicht wird.
Akzeptiert die gleichen Werte wie die Einstellungen
FailureAction=/SuccessAction=. Falls none gesetzt ist,
wird das Erreichen der Ratenbegrenzung keine Aktion auslösen,
außer das der Start nicht erlaubt wird. Standardmäßig
none.
RebootArgument=
Konfiguriert das globale Argument für
den Systemaufruf reboot(2), falls StartLimitAction= oder
FailureAction= eine Neustartaktion ist. Dies funktioniert genauso wie
das optionale Argument für den Befehl systemctl reboot.
SourcePath=
Ein Pfad zu der Konfigurationsdatei, aus der
die Unit erstellt wurde. Dies ist hauptsächlich für
Implementierungen von Generatorwerkzeugen nützlich, die Konfigurationen
aus externen Konfigurationsdateiformaten in native Unit-Dateien umwandeln.
Diese Funktionalität sollte in normalen Unit-Dateien nicht verwandt
werden.
Bedingungen und Zusicherungen
Unit-Dateien können auch eine Reihe von Bedingung…=- und Zusicherung…=-Einstellungen enthalten. Bevor die Unit gestartet wird, wird Systemd nachweisen, dass die festgelegten Bedingungen und Zusicherungen wahr sind. Falls nicht, wird das Starten der Unit (fast ohne Ausgabe) übersprungen (im Falle von Bedingungen) oder mit einer Fehlermeldung abgebrochen (im Falle von Zusicherungen). Fehlschlagende Bedingungen oder Zusicherungen führen nicht dazu, dass die Unit in den Zustand »failed« überführt wird. Die Bedingungen und Zusicherungen werden zum Zeitpunkt überprüft, zu dem der Start-Auftrag in der Warteschlange ausgeführt wird. Die Ordnungsabhängigkeiten werden weiterhin berücksichtigt, so dass andere Units weiterhin hereingezogen und einsortiert werden, als ob die Unit erfolgreich aktiviert worden wäre und die Bedingungen und Zusicherungen werden zu dem genauen Moment ausgeführt, zu dem die Unit normalerweise starten würde und kann daher den Systemzustand nach den einsortierten Units und vor Abschluss der Initialisierung validieren. Verwenden Sie Bedingungsausdrücke, um Units zu überspringen, die auf dem lokalen System nicht zutreffen, beispielsweise da der Kernel oder die Laufzeitumgebung ihre Funktionalität nicht benötigt. Falls mehrere Bedingungen festgelegt sind, wird die Unit ausgeführt, falls alle von ihnen zutreffen (d.h. es wird ein logisches UND angewandt). Den Bedingungsprüfungen kann ein Pipe-Symbol (|) nach dem Gleichheitszeichen verwendet (»Bedingung…=!…«) werden, was dazu führt, dass die Bedingung eine auslösende Bedingung wird. Falls für eine Unit mindestens eine auslösende Bedingung definiert ist, dann wird die Unit gestartet, falls mindestens eine der auslösenden Bedingungen und alle der regulären (d.h. nicht auslösenden) Bedingungen zutreffen. Falls Sie einem Argument das Pipe-Symbol und ein Ausrufezeichen voranstellen, muss das Pipe-Symbol zuerst und das Ausrufezeichen als zweites übergeben werden. Falls einer der Optionen die leere Zeichenkette zugewiesen wird, wird die Liste der Bedingungen komplett zurückgesetzt und alle vorhergehenden Bedingungseinstellungen (jeder Art) werden keine Wirkung haben. Die Optionen AssertArchitecture=, AssertVirtualization=, … sind zu Bedingungen ähnlich, führen aber dazu, dass Aufträge fehlschlagen (statt übersprungen zu werden). Die fehlgeschlagene Prüfung wird protokolliert. Units mit 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. Beachten Sie, dass weder eine Zusicherung noch ein Bedingungsausdruck zu Unit-Zustandsänderungen führt. Beachten Sie auch, dass beide zum Zeitpunkt geprüft werden, zu dem der Auftrag ausgeführt werden soll, d.h. lange nachdem abhängige Aufträge und er selbst in die Warteschlange eingereiht wurden. Daher sind weder die Bedingungs- noch die Zusicherungsausdrücke dazu geeignet, Unit-Abhängigkeitsbedingungen auszudrücken. Der Unterbefehl condition aus systemd-analyze(1) kann zum Testen von Bedingungen und Zusicherungsausdrücken verwandt werden. Außer für ConditionPathIsSymbolicLink= folgen alle Pfadprüfungen Symlinks. ConditionArchitecture=Prüft, ob das System auf einer
bestimmten Architektur läuft. Akzeptiert einen aus »x86«,
»x86-64«, »ppc«, »ppc-le«,
»ppc64«, »ppc64-le«, »ia64«,
»parisc«, »parisc64«, »s390«,
»s390x«, »sparc«, »sparc64«,
»mips«, »mips-le«, »mips64«,
»mips64-le«, »alpha«, »arm«,
»arm-be«, »arm64«, »arm64-be«,
»sh«, »sh64«, »m68k«,
»tilegx«, »cris«, »arc«,
»arc-be« oder »native«.
Die Architektur wird aus der durch uname(2) zurückgelieferten
Information bestimmt und unterliegt daher personality(2). Beachten Sie,
dass eine Einstellung Personality= in der gleichen Unit-Datei keine
Auswirkung auf diese Bedingung hat. Ein besonderer Architekturname
»native« wird auf die Architektur, für die der
Systemverwalter selbst kompiliert wurde, abgebildet. Der Test kann durch
Voranstellung eines Ausrufezeichens negiert werden.
ConditionFirmware=
Prüft, ob die Firmware des Systems von
einem bestimmten Typ ist. Die folgenden Werte sind möglich:
ConditionVirtualization=
•»uefi« passt auf Systeme
mit EFI.
•»device-tree« passt auf
Systeme mit einem Devicetree.
•»device-tree-compatible(Wert)«
passt auf Systeme mit einem Devicetree, die kompatibel mit
»Wert« sind.
•»smbios-field(Feld
Operator Wert)« passt auf Systeme mit einem SMBIOS-Feld,
das einen bestimmten Wert enthält. Feld ist der Name eines
SMBIOS-Feldes, das als »sysfs«-Attributsdatei unterhalb von
/sys/class/dmi/id/ offengelegt wird. Operator ist einer aus
»<«, »<=«, »>=«,
»>«, »==«, »<>« zum
Versionsvergleich, »=« und »!=« für
wörtlichen Zeichenkettenvergleich oder »$=«,
»!$=« für Shell-artigen Glob-Vergleich. Wert ist
der erwartete Wert des SMBIOS-Feldes (möglicherweise enthält er
Shell-artige Globs, falls »$="/"!$=« verwandt
wird.
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 systemd-detect-virt(1)
für eine vollständige Liste der bekannten
Virtualisierungstechniken und ihrer Kennungen. Falls mehrere
Virtualisierungstechniken verschachtelt sind, wird nur die innerste
betrachtet. Der Test kann durch Voranstellung eines Ausrufezeichens negiert
werden.
ConditionHost=
ConditionHost= kann dazu verwandt
werden, den Rechnernamen oder die Maschinenkennung des Rechners zu
vergleichen. Dies akzeptiert entweder eine Rechnernamenzeichenkette (optional
mit Shell-artigen Globs), die gegen den lokal gesetzten Rechnernamen, wie er
von gethostname(2) zurückgeliefert wird, geprüft wird
oder eine als Zeichenkette formatierte Maschinenkennung (siehe
machine-id(5)). Der Test kann durch Voranstellung eines Ausrufezeichens
negiert werden.
ConditionKernelCommandLine=
ConditionKernelCommandLine= kann zur
Prüfung, ob eine bestimmte Kernelbefehlszeilenoption gesetzt ist (oder
falls ein Ausrufezeichen vorangestellt ist, nicht gesetzt ist) verwandt
werden. Das Argument muss entweder ein einzelnes Wort oder eine Zuweisung
(d.h. zwei Worte, getrennt durch »=«) sein. Im ersten Fall wird
die Kernelbefehlszeile nach Auftauchen des Wortes wie es ist oder als linke
Seite einer Zuweisung durchsucht. Im zweitem Fall wird nach der genauen
Zuweisung geschaut, wobei die rechte und die linke Seite passen müssen.
Dies agiert auf der Kernelbefehlszeile, die an die Anwendungsebene mittels
/proc/cmdline kommuniziert wird, außer wenn der Diensteverwalter als
Nutzlast eines Container-Verwalters gestartet wird - dann wird stattdessen die
Befehlszeile von PID 1 verwandt (d.h. /proc/1/cmdline).
ConditionKernelVersion=
ConditionKernelVersion= kann zur
Prüfung, ob die Kernelversion (wie sie durch uname -r gemeldet
wird) auf einen bestimmten Ausdruck passt, oder falls ein Ausrufezeichen
vorangestellt ist, nicht darauf passt. Das Argument muss eine List von
(möglicherweise in Anführungszeichen gesetzten)
Ausdrücken sein. 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.
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.
ConditionCredential=
ConditionCredential= kann zum
Prüfen, ob eine Zugangsberechtigung mit dem festgelegten Namen in den
Diensteverwalter übergeben wurde. Siehe System- und
Dienste-Zugangsberechtigungen[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
[email protected], die zu dem Benutzer gehören, gegebenen
Zugangsberechtigungen zu machen. Das Argument muss ein gültiger
Zugangsberechtigungsname sein.
ConditionEnvironment=
ConditionEnvironment= kann zur
Überprüfung, ob eine bestimmte Umgebungsvariable im
Umgebungsblock des Diensteverwalters gesetzt (bzw. nicht gesetzt, falls ein
Ausführungszeichen vorangestellt wird) ist. Das Argument kann ein
einzelnes Wort sein, um zu prüfen, ob die Variable mit diesem Namen im
Umgebungsblock definiert ist, oder eine Zuweisung (»
Name=Wert«), um zu prüfen, ob die Variable mit
genau diesem Wert definiert ist. Beachten Sie, dass der Umgebungsblock des
Diensteverwalters selbst geprüft wird, d.h. keine mit (wie oben
beschrieben) Environment= oder EnvironmentFile= definierte
Variablen. Dies ist besonders nützlich, wenn der Diensteverwalter
innerhalb einer Container-Umgebung oder als benutzerbezogener Diensteverwalter
läuft, um auf Variablen zu prüfen, die durch den
einschließenden Container-Verwalter oder PAM übergeben
wurden.
ConditionSecurity=
ConditionSecurity= kann zur
Prüfung, ob die übergebene Sicherheitstechnik auf dem System
aktiviert ist, verwandt werden. Derzeit sind die erkannten Werte
»selinux«, »apparmor«, »tomoyo«,
»ima«, »smack«, »audit«,
»uefi-secureboot« und »tpm2«. Der Test kann durch
Voranstellung eines Ausrufezeichens negiert werden.
ConditionCapability=
Prüft, ob die übergebene
Capability in der Capability-Begrenzungsmenge des Diensteverwalters existiert
(d.h. dies prüft nicht, ob die Capability tatsächlich in der
erlaubten oder effektiven Menge verfügbar ist, siehe
capabilities(7) für Details), verwandt werden. Übergeben
Sie einen Capability-Namen wie »CAP_MKNOD«,
möglicherweise mit vorangestelltem Ausrufezeichen, um die
Prüfung zu negieren.
ConditionACPower=
Prüft, ob das System zum Zeitpunkt der
Aktivierung der Unit am Netz hängt oder ausschließlich
über Akku läuft. Dies akzeptiert ein logisches Argument. Falls
auf »true« gesetzt, wird die Bedingung nur gelten, wenn
mindestens ein Netzstecker an einer Wechselstromquelle hängt oder falls
keine Wechselstromstecker bekannt sind. Umgekehrt, wenn auf
»false« gesetzt, wird die Bedingung nur gelten, falls mindestens
ein Wechselstromstecker bekannt ist und alle Wechselstromstecker von einer
Stromquelle abgetrennt sind.
ConditionNeedsUpdate=
Akzeptiert entweder /var/ oder /etc/ als
Argument, möglicherweise mit vorangestelltem »!« (zur
Invertierung der Bedingung). Diese Bedingung kann eingesetzt werden, um Units
davon abhängig zu machen, ob das angegebene Verzeichnis einer
Aktualisierung bedarf, da die Änderungszeit von /usr/ neuer als die
Stempeldatei .updated in dem angegebenen Verzeichnis ist. Dies ist
nützlich, um Offline-Aktualisierungen der Betriebssystemressourcen des
Lieferanten in /usr/ zu implementieren, die Aktualisierungen von /etc/ oder
/var/ beim nachfolgenden Systemstart benötigen. Units, die von dieser
Bedingung Gebrauch machen, sollten sich vor
systemd-update-done.service(8) einordnen, um sicherzustellen, dass sie
ausgeführt werden, bevor die Änderungszeit der Stempeldatei
zurückgesetzt wird, wodurch eine abgeschlossene Aktualisierung
angezeigt wird.
Falls die Option systemd.condition-needs-update= auf der
Kernelbefehlszeile angegeben ist (sie akzeptiert einen logischen Wert), wird
sie das Ergebnis dieser Zustandsüberprüfung außer Kraft
setzen und Vorrang vor allen Dateiänderungsprüfungen haben.
Falls die Kernelbefehlszeilenoption verwandt wird, wird
systemd-update-done.service keine direkte Auswirkung auf die nachfolgenden
ConditionNeedsUpdate=-Überprüfungen haben, bis das System
neu gestartet und dabei die Kernelbefehlszeilenoption nicht mehr angegeben
wird.
Beachten Sie, dass der Zeitstempel von /usr/ ausdrücklich aktualisiert
werden sollte, nachdem die Inhalte verändert wurden, damit dieses
Schema wirksam wird. Der Kernel wird den Veränderungszeitstempel eines
Verzeichnisses nur automatisch aktualisieren, wenn direkt darunter liegende
Einträge eines Verzeichnisses verändert werden; eine
Veränderung von verschachtelten Dateien wird nicht automatisch dazu
führen, dass die mtime von /usr/ aktualisiert wird.
Beachten Sie auch, dass die Aktualisierungsmethode nicht den Zeitstempel von
/usr/ verändern sollte, wenn sie einen Aufruf enthält, nach der
Aktualisierung selbst geeignete Schritte auszuführen. In einem
typischen Paketierungsschema einer Distribution werden Pakete alle
benötigten Aktualisierungsschritte als Teil der Installation oder des
Upgrades durchführen, um die Paketinhalte sofort nutzbar zu machen.
ConditionNeedsUpdate= sollte mit anderen Aktualisierungsmechanismen
verwandt werden, bei denen eine solche direkte Aktualisierung nicht
passiert.
ConditionFirstBoot=
Akzeptiert ein logisches Argument. Diese
Bedingung kann eingesetzt werden, um Units davon abhängig zu machen, ob
das System erstmalig startet. Dies bedeutet grob, dass /etc/ nicht
bestückt war, als das System den Systemstart begann (für
Details, siehe »SEMANTIK BEIM ERSTEN SYSTEMSTART« in
machine-id(5)). Der erste Systemstart gilt als abgeschlassen (diese
Bedingung wird als falsch ausgewertet), nachdem der Verwalter die Startphase
abgeschlossen hat.
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.
Zur Robustheit sollten sich Units mit ConditionFirstBoot=yes vor
first-boot-complete.target anordnen und dieses passive Ziel mit Wants=
hereinziehen. Dies stellt sicher, dass bei einem abgebrochenen ersten
Systemstart die Units erneut beim nächsten Systemstart
ausgeführt werden.
Falls die Option systemd.condition-first-boot= auf der Kernelbefehlszeile
angegeben ist (sie akzeptiert einen logischen Wert), wird sie das Ergebnis
dieser Zustandsüberprüfung außer Kraft setzen und Vorrang
vor /etc/machine-id-Existenzprüfungen haben.
ConditionPathExists=
Prüft auf die Existenz einer Datei.
Falls der angegebene absolute Pfadname nicht existiert, wird die Bedingung
fehlschlagen. Falls dem an ConditionPathExists= übergebenen
absoluten Pfadnamen ein Ausrufezeichen (»!«) vorangestellt wird,
wird der Test negiert und die Unit nur gestartet, falls der Pfadname nicht
existiert.
ConditionPathExistsGlob=
ConditionPathExistsGlob= ist zu
ConditionPathExists= ähnlich, prüft aber auf die Existenz
von mindestens einer Datei oder einem Verzeichnis, das auf das angegebene
Globbing-Muster passt.
ConditionPathIsDirectory=
ConditionPathIsDirectory= ist zu
ConditionPathExists= ähnlich, überprüft aber, dass
ein bestimmter Pfad existiert und ein Verzeichnis ist.
ConditionPathIsSymbolicLink=
ConditionPathIsSymbolicLink= ist zu
ConditionPathExists= ähnlich, überprüft aber, dass
ein bestimmter Pfad existiert und ein symbolischer Link ist.
ConditionPathIsMountPoint=
ConditionPathIsMountPoint= ist zu
ConditionPathExists= ähnlich, überprüft aber, dass
ein bestimmter Pfad existiert und ein Einhängepunkt ist.
ConditionPathIsReadWrite=
ConditionPathIsReadWrite= ist zu
ConditionPathExists= ähnlich, überprüft aber, dass
das zugrundeliegende Dateisystem les- und schreibbar ist (d.h. nicht
rein-lesbar eingehängt ist).
ConditionPathIsEncrypted=
ConditionPathIsEncrypted= ist
ähnlich zu ConditionPathExists=, überprüft aber,
dass das dem Dateisystem zugrundeliegende Blockgerät mittels
dm-crypt/LUKS verschlüsselt ist. Beachten Sie, dass diese
Prüfung keine verzeichnisbezogene Verschlüsselung bei Ext4
berücksichtigt und nur Verschlüsselung auf Blockebene erkennt.
Desweiteren wird nur die Verschlüsselung oberhalb des
Loopback-Gerätes erkannt, falls der angegebene Pfad sich auf einem
Dateisystem oberhalb eines per Looback eingehängten Gerätes
befindet. Es wird nicht erkannt, ob das dem Loopback zugrundeliegende
Blockgerät verschlüsselt ist.
ConditionDirectoryNotEmpty=
ConditionDirectoryNotEmpty= ist zu
ConditionPathExists= ähnlich, überprüft aber, dass
ein bestimmter Pfad existiert und ein nicht leeres Verzeichnis ist.
ConditionFileNotEmpty=
ConditionFileNotEmpty= ist zu
ConditionPathExists= ähnlich, überprüft aber, dass
ein bestimmter Pfad existiert und sich auf eine normale Datei mit einer von
Null verschiedenen Größe bezieht.
ConditionFileIsExecutable=
ConditionFileIsExecutable= ist zu
ConditionPathExists= ähnlich, überprüft aber, dass
ein bestimmter Pfad existiert und sich auf eine normale, als ausführbar
gekennzeichnete Datei bezieht.
ConditionUser=
ConditionUser= akzeptiert eine
numerische »UID«, einen UNIX-Benutzernamen oder den besonderen
Wert »@system«. Diese Bedingung kann zur Prüfung, ob der
Diensteverwalter als der angegebene Benutzer läuft, verwandt werden.
Der besondere Wert »@system« kann dazu verwandt werden, zu
prüfen, ob die Benutzerkennung innerhalb des Systembenutzerbereichs
ist. Diese Option ergibt für Systemdienste keinen Sinn, da der
Systemverwalter ausschließlich als Benutzer root läuft und daher
das Testergebnis konstant ist.
ConditionGroup=
ConditionGroup= ist zu
ConditionUser= ähnlich, überprüft aber, ob die
reale oder effektive Gruppe des Diensteverwalters oder jeder seiner
Hilfsgruppen auf die angegebene Gruppe oder GID passt. Diese Einstellung
unterstützt den besonderen Wert »@system« nicht.
ConditionControlGroupController=
Prüft, ob übergebene
Cgroup-Controller (z.B. »cpu«) für die Verwendung auf dem
System verfügbar sind.
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«, »cpuset«, »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:
ConditionMemory=
Überprüft, ob die angegebene
Menge an Systemspeicher für das aktuelle System verfügbar ist.
Akzeptiert eine Speichergröße in Byte als Argument, optional
kann ein Vergleichsoperator »<«, »<=«,
»=« (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.
ConditionCPUs=
Überprüft, dass die angegebene
Anzahl an CPUs für das aktuelle System verfügbar ist. Akzeptiert
eine Anzahl an CPUs als Argument, optional kann ein Vergleichsoperator
»<«, »<=«, »=« (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.
ConditionCPUFeature=
Prüft nach, ob die angegebene
CPU-Funktionalität mittels der »CPUID«-Anweisung
verfügbar ist. Diese Bedingung macht nur auf i386- und
x86-64-Prozessoren etwas. Auf anderen Prozessoren wird angenommen, dass die
CPU die angegebene Funktionalität nicht unterstützt. Es
prüft die Erlaubnisse »1«, »7«,
»0x80000001« und »0x80000007«. Gültige
Werte sind: »fpu«, »vme«, »de«,
»pse«, »tsc«, »msr«,
»pae«, »mce«, »cx8«,
»apic«, »sep«, »mtrr«,
»pge«, »mca«, »cmov«,
»pat«, »pse36«, »clflush«,
»mmx«, »fxsr«, »sse«,
»sse2«, »ht«, »pni«,
»pclmul«, »monitor«, »ssse3«,
»fma3«, »cx16«, »sse4_1«,
»sse4_2«, »movbe«, »popcnt«,
»aes«, »xsave«, »osxsave«,
»avx«, »f16c«, »rdrand«,
»bmi1«, »avx2«, »bmi2«,
»rdseed«, »adx«, »sha_ni«,
»syscall«, »rdtscp«, »lm«,
»lahf_lm«, »abm«,
»constant_tsc«.
ConditionOSRelease=
Bestätigt, dass ein bestimmtes
»Schlüssel-Wert«-Paar in der os-release(5) des
Rechners gesetzt ist.
Neben der genauen 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.
ConditionMemoryPressure=, ConditionCPUPressure=,
ConditionIOPressure=
Verifiziert, dass der gesamte Systemdruck
(Speicher, CPU oder E/A) unterhalb von oder identisch zu einem Schwellwert
ist. Diese Einstellung akzeptiert einen Schwellwert als Argument. Sie kann als
einfacher Prozentwert, dem »%« angehängt wird, festgelegt
werden; in diesem Fall wird der Druck als Durchschnitt über die letzten
fünf Minuten gemessen, bevor der Versuch, die Unit zu starten,
durchgeführt wird. Alternativ kann eine durchschnittliche Zeitdauer
auch mit »/« als Trenner festgelegt werden, beispielsweise
»10%/1min«. Die unterstützten Zeitdauern passen auf das
Angebot des Kernels und sind auf »10sec«, »1min«
und »5min« beschränkt. Zuerst wird der
vollständige PSI geprüft, und falls dieser nicht gefunden wird,
werden »einige« geprüft. Für weitere Details lesen
Sie die Dokumentation unter PSI (Pressure Stall Information)[3].
Optional kann dem Schwellwert die Scheiben-Unit, unter der der Druck
überprüft wird, vorangestellt werden, gefolgt von
»:«. Falls die Scheiben-Unit nicht festgelegt ist, wird der
Gesamtsystemdruck statt dem einer bestimmten Cgroup gemessen.
AssertArchitecture=, AssertVirtualization=, AssertHost=,
AssertKernelCommandLine=, AssertKernelVersion=,
AssertCredential=, AssertEnvironment=, AssertSecurity=,
AssertCapability=, AssertACPower=, AssertNeedsUpdate=,
AssertFirstBoot=, AssertPathExists=,
AssertPathExistsGlob=, AssertPathIsDirectory=,
AssertPathIsSymbolicLink=, AssertPathIsMountPoint=,
AssertPathIsReadWrite=, AssertPathIsEncrypted=,
AssertDirectoryNotEmpty=, AssertFileNotEmpty=,
AssertFileIsExecutable=, AssertUser=, AssertGroup=,
AssertControlGroupController=, AssertMemory=,
AssertCPUs=, AssertCPUFeature=, AssertOSRelease=,
AssertMemoryPressure=, AssertCPUPressure=,
AssertIOPressure=
Ähnlich zu den oben beschriebenen
Bedingungseinstellungen ConditionArchitecture=,
ConditionVirtualization=, … fügen diese Einstellungen
Zusicherungsprüfungen zum Hochfahren der Unit hinzu. Anders als bei den
Bedingungseinstellungen führt jede Zusicherungseinstellung, die nicht
erfüllt wird, zu einem Fehlschlag des Startauftrags (das bedeutet, dass
es laut protokolliert wird). Beachten Sie, dass das Erreichen einer
konfigurierten Zusicherung nicht dazu führt, dass die Unit in den
Zustand »failed« eintritt (oder tatsächlich zu
irgendeiner Zustandsänderung der Unit führt). Verwenden Sie
Zusicherungsausdrücke für Units, die nicht agieren
können, falls bestimmte Anforderungen nicht erfüllt sind und
wenn dies etwas ist, was sich der Administrator oder Benutzer anschauen
sollte.
ABBILDUNG VON UNIT-EIGENSCHAFTEN AUF IHR INVERSES
Unit-Einstellungen, die eine Beziehung zu einer zweiten Unit erstellen, zeigen sich normalerweise als Eigenschaften in beiden Units, beispielsweise in der Ausgabe von systemctl show. In einigen Fällen (aber nicht immer) ist der Name der Eigenschaft identisch mit dem Namen der Konfigurationseinstellung. Diese Tabelle listet die Eigenschaften auf, die in zwei Units angezeigt werden, die durch eine Abhängigkeit verbunden sind. Sie zeigt, welche Eigenschaft aus der »Quell«-Unit welcher Eigenschaft aus der »Ziel«-Unit entspricht.| »Vorwärts«-Eigenschaft | »Rückwärts«-Eigenschaft | Wo benutzt | |
| Before= | After= | [Unit]-Abschnitt | |
| After= | Before= | ||
| Requires= | RequiredBy= | [Unit]-Abschnitt | [Install]-Abschnitt |
| Wants= | WantedBy= | [Unit]-Abschnitt | [Install]-Abschnitt |
| PartOf= | ConsistsOf= | [Unit]-Abschnitt | eine automatische Eigenschaft |
| BindsTo= | BoundBy= | [Unit]-Abschnitt | eine automatische Eigenschaft |
| Requisite= | RequisiteOf= | [Unit]-Abschnitt | eine automatische Eigenschaft |
| Triggers= | TriggeredBy= | automatische Eigenschaften, siehe Hinweise unten | |
| Conflicts= | ConflictedBy= | [Unit]-Abschnitt | eine automatische Eigenschaft |
| PropagatesReloadTo= | ReloadPropagatedFrom= | [Unit]-Abschnitt | |
| ReloadPropagatedFrom= | PropagatesReloadTo= | ||
| Following= | n.Z. | eine automatische Eigenschaft |
[INSTALL]-ABSCHNITT-OPTIONEN
Unit-Dateien können einen Abschnitt »[Install]« enthalten, der Installationsinformationen für die Unit transportiert. Dieser Abschnitt wird von systemd(1) während der Laufzeit nicht interpretiert; er wird von den Befehlen enable und disable des Werkzeugs systemctl(1) während der Installation einer Unit verwandt. Alias=Eine Lerraum-getrennte Liste von
zusätzlichen Namen, unter der diese Unit installiert werden soll. Die
hier aufgeführten Namen müssen die gleiche Endung (d.h. Typ) wie
der Unit-Dateiname haben. Diese Option kann mehr als einmal angegeben werden,
dann werden alle aufgeführten Namen verwandt. Bei der Installation wird
systemctl enable die Symlinks von diesen Namen auf den Unit-Dateinamen
erstellen. Beachten Sie, dass nicht alle Unit-Typen solche Aliase
unterstützen und diese Einstellung für sie nicht
unterstützt wird. Insbesondere unterstützen Einhänge-,
Scheiben, Auslagerungs- und Automount-Units keinen Alias.
WantedBy=, RequiredBy=
Diese Option kann mehr als einmal verwendet
werden oder eine durch Leerzeichen getrennte Liste von Unit-Namen kann
übergeben werden. Im .wants/- oder .requires/-Verzeichnis jeder der
aufgeführten Units wird bei der Installation mit systemctl
enable ein symbolischer Link erstellt. Dadurch wird eine
Abhängigkeit vom Typ Wants= oder Requires= von der
aufgeführten Unit zu der aktuellen Unit hinzugefügt. Das
Hauptergebnis besteht darin, dass die aktuelle Unit gestartet wird, wenn die
aufgeführte Unit gestartet wird. Siehe die Beschreibung von
Wants= und Requires= im Abschnitt [Unit] für Details.
Falls Vorlagen-Units nicht-Vorlagen-Units aufführen, muss in der
aufführenden Unit DefaultInstance= gesetzt sein oder
systemctl enable muss mit einem Instanzennamen aufgerufen werden. Die
Instanz (entweder die Vorgabe oder die angegebene) wird zu der Liste der
.wants/ oder .requires/ der aufgeführten Unit hinzugefügt. Zum
Beispiel führt WantedBy=getty.target in einem Dienst
[email protected] dazuz, dass systemctl enable [email protected] einen
Link getty.target.wants/[email protected] auf [email protected] erstellt. Dies
gilt auch für das Aufführen bestimmter Instanzen aus einer
Vorlagen-Unit: diese bestimmte Instanz wird die Abhängigkeit erhalten.
Eine Vorlagen-Unit kann auch eine Vorlagen-Unit aufführen. Dann wird
eine generische Abhängigkeit hinzugefügt, bei der jede Instanz
der aufführenden Unit eine Abhängigkeit auf eine Instanz der
aufgeführten Vorlagen-Unit mit dem gleichen Instanzwert haben wird.
Beispielsweise wird WantedBy=[email protected] dazu führen, dass
systemctl enable [email protected] einen Dienste-Link
[email protected]/[email protected] auf [email protected] erstellt, der
für alle Instanzen von [email protected] gilt.
Also=
Zusätzliche Units, die
installiert/deinstalliert werden sollen, wenn diese Unit
installiert/deinstalliert wird. Falls der Benutzer die
Installation/Deinstallation einer Unit mit dieser konfigurierten Option
erbeten hat, wird systemctl enable und systemctl disable
automatisch auch die in dieser Option aufgeführten Units
installieren/deinstallieren.
Diese Option kann mehr als einmal verwandt werden oder eine Lerraum-getrennte
Liste von Unit-Namen kann übergeben werden.
DefaultInstance=
In Vorlagen-Unit-Dateien kennzeichnet dies,
welche Instanz der Unit freigegeben werden soll, falls die Vorlage ohne
explizit gesetzte Instanz freigegeben wird. Diese Option zeigt nur bei
Vorlagen-Unit-Dateien Wirkung. Die gekennzeichnete Zeichenkette zur
Identifizierung einer Instanz geeignet sein.
Die folgenden Kennzeicher werden in dem Abschnitt Install interpretiert: %a, %b,
%B, %g, %G, %H, %i, %j, %l, %m, %n, %N, %o, %p, %u, %U, %v, %w, %W, %% . Ihre
Bedeutung ist im nächsten Abschnitt beschrieben.
KENNZEICHNER
Viele Einstellungen klären Kennzeichner, die zum Schreiben generischer Unit-Dateien verwandt werden können, die sich auf Laufzeit- oder Unit-Parameter beziehen, die ersetzt werden, wenn die Unit-Dateien geladen werden. Kennzeichner müssen bekannt und auflösbar sein, damit die Einstellungen gültig sind. Die folgenden Kennzeichner werden verstanden:| Kennzeichner | Bedeutung | Details |
| "%a" | Architektur | Eine kurze Zeichenkette, die die Architektur des lokalen Systems identifiziert. Eine Zeichenkette wie x86, x86-64 oder arm64. Siehe die für ConditionArchitecture= weiter oben definierten Architekturen für die vollständige Liste. |
| "%A" | Betriebssystemabbildversion | Die Betriebssystemabbildversionskennzeichnung des laufenden Systems, wie aus dem Feld IMAGE_VERSION= in /etc/os-release ausgelesen. Falls nicht gesetzt, wird es die leere Zeichenkette. Siehe os-release(5) für weitere Informationen. |
| "%b" | Boot-Kennung | Die Boot-Kennung des laufenden Systems, formatiert als Zeichenkette. Siehe random(4) für weitere Informationen. |
| "%B" | Betriebssystembaukennung | Die Betriebssystembaukennung des laufenden Systems, wie aus dem Feld BUILD_ID= in /etc/os-release ausgelesen. Falls nicht gesetzt, wird es zur leeren Zeichenkette aufgelöst. Siehe os-release(5) für weitere Informationen. |
| "%C" | Wurzelverzeichnis des Zwischenspeichers | Dies ist entweder /var/cache (für den Systemverwalter) oder worauf der Pfad »$XDG_CACHE_HOME« zeigt (für Benutzerverwalter). |
| "%d" | Zugangsdaten-Verzeichnis | Dies ist der Wert der Umgebungsvariablen »$CREDENTIALS_DIRECTORY«, falls verfügbar. Siehe den Abschnitt »Zugangsdaten« in systemd.exec(5) für weitere Informationen. |
| "%E" | Wurzelverzeichnis der Konfiguration | Dies ist entweder /etc/ (für den Systemverwalter) oder worauf der Pfad »$XDG_CONFIG_HOME« zeigt (für Benutzerverwalter). |
| "%f" | Demaskierter Dateiname | Dies ist entweder der demaskierte Instanzenname (falls zutreffend), dem / vorangestellt wurde (falls zutreffend), oder der desmaskierte Präfixname, dem / vorangestellt wurde. Hiermit wird das Demaskieren entsprechend den oben beschriebenen Regeln des Maskierens absoluter Dateisystempfade implementiert. |
| "%g" | Benutzergruppe | Dies ist der Name der Gruppe, die die Diensteverwalterinstanz ausführt. Im Falle des Systemverwalters löst sich dies auf »root« auf. |
| "%G" | Benutzer-GID | Dies ist die numerische GID des Benutzers, der die Diensteverwalterinstanz ausführt. Im Falle des Systemverwalters löst sich dies auf »0« auf. |
| "%h" | Benutzer-Home-Verzeichnis. | Dies ist das Home-Verzeichnis des Benutzers, der die Diensteverwalterinstanz ausführt. Im Falle des Systemverwalters löst sich dies auf »/root« auf. Beachten Sie, dass diese Einstellung nicht von der im Abschnitt [Service] der Dienste-Unit konfigurierbaren Einstellung User= beeinflusst wird. |
| "%H" | Rechnername | Der Rechnername des laufenden Systems zum Zeitpunkt des Ladens der Unit-Konfiguration. |
| "%i" | Instanzenname | Für instanziierte Units ist dies die Zeichenkette zwischen dem ersten »@«-Zeichen und der Typendung. Leer für nichtinstanziierte Units. |
| "%I" | Demaskierter Instanzenname | Identisch zu »%i«, aber mit zurückgenommener Maskierung. |
| "%j" | Abschließende Komponente des Präfixes | Dies ist die Zeichenkette zwischen dem letzten »-« und dem Ende des Präfixnamens. Falls es kein »-« gibt, ist dies zu »%p« identisch. |
| "%J" | Nicht maskierte abschließende Komponente des Präfixes | Identisch zu »%j«, aber mit zurückgenommener Maskierung. |
| "%l" | Kurzer Rechnername | Der Rechnername des laufenden Systems zum Zeitpunkt des Ladens der Unit-Konfiguration, abgeschnitten am ersten Punkt, um alle Domain-Komponenten zu entfernen. |
| "%L" | Wurzel des Protokollierverzeichnisses | Dies ist entweder /var/log (für den Systemverwalter) oder worauf der Pfad »$XDG_CONFIG_HOME« zeigt, mit angehängtem /log (für Benutzerverwalter). |
| "%m" | Maschinenkennung | Die Maschinenkennung des laufenden Systems, formatiert als Zeichenkette. Siehe machine-id(5) für weitere Informationen. |
| "%M" | Betriebssystemabbildkennung | Die Betriebssystemabbildkennung des laufenden Systems, wie aus dem Feld IMAGE_ID= in /etc/os-release ausgelesen. Falls nicht gesetzt, wird es die leere Zeichenkette. Siehe os-release(5) für weitere Informationen. |
| "%n" | Vollständiger Unit-Name | |
| "%N" | Vollständiger Unit-Name | Identisch zu »%n«, aber mit entfernter Typendung. |
| "%o" | Betriebssystemkennung | Die Betriebssystemkennung des laufenden Systems, wie aus dem Feld ID= in /etc/os-release ausgelesen. Siehe os-release(5) für weitere Informationen. |
| "%p" | Präfixname | Für instanziierte Units bezieht sich das auf die Zeichenkette vor dem ersten »@«-Zeichen des Unit-Namens. Für nicht instanziierte Units identisch zu »%N«. |
| "%P" | Nicht maskierter Präfixname | Identisch zu »%p«, aber mit zurückgenommener Maskierung. |
| "%q" | Schöner Rechnername | Der schöne Rechnername des laufenden Systems zum Zeitpunkt des Ladens der Unit-Konfiguration, wie aus dem Feld PRETTY_HOSTNAME= in /etc/machine-info ausgelesen. Falls nicht gesetzt, wird es auf den kurzen Rechnernamen gesetzt. Siehe machine-info(5) für weitere Informationen. |
| "%s" | Benutzer-Shell | Dies ist die Shell des Benutzers, der die Diensteverwalterinstanz ausführt. |
| "%S" | Wurzel des Zustandsverzeichnisses | Dies ist entweder /var/lib (für den Systemverwalter) oder worauf der Pfad »$XDG_CONFIG_HOME« zeigt (für Benutzerverwalter). |
| "%t" | Wurzel des Laufzeitverzeichnisses | Dies ist entweder /run/ (für den Systemverwalter) oder worauf der Pfad »$XDG_RUNTIME_DIR« zeigt (für Benutzerverwalter). |
| "%T" | Verzeichnis für temporäre Dateien | 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.) |
| "%u" | Benutzername | Dies ist der Name des Benutzers, der die Diensteverwalterinstanz ausführt. Im Falle des Systemverwalters löst sich dies auf »root« auf. Beachten Sie, dass diese Einstellung nicht von der im Abschnitt [Service] der Dienste-Unit konfigurierbaren Einstellung User= beeinflusst wird. |
| "%U" | Benutzer-UID | Dies ist die numerische UID des Benutzers, der die Diensteverwalterinstanz ausführt. Im Falle des Systemverwalters löst sich dies auf »0« auf. Beachten Sie, dass diese Einstellung nicht von der im Abschnitt [Service] der Dienste-Unit konfigurierbaren Einstellung User= beeinflusst wird. |
| "%v" | Kernelveröffentlichung | Identisch zur Ausgabe von uname -r. |
| "%V" | Verzeichnis für größere und dauerhafte temporäre Dateien | 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.) |
| "%w" | Betriebssystemversionskennung | Die Betriebssystemversionskennzeichnung des laufenden Systems, wie aus dem Feld VERSION_ID= in /etc/os-release ausgelesen. Falls nicht gesetzt, wird es die leere Zeichenkette. Siehe os-release(5) für weitere Informationen. |
| "%W" | Betriebssystemvariantenkennung | Die Betriebssystemvariantenkennung des laufenden Systems, wie aus dem Feld VARIANT_ID= in /etc/os-release ausgelesen. Falls nicht gesetzt, wird es die leere Zeichenkette. Siehe os-release(5) für weitere Informationen. |
| "%y" | Der Pfad zum Fragment. | Dies ist der Pfad dorthin, wo sich der Hauptteil der Unit-Datei befindet. Für verlinkte Unit-Dateien wird der echte Pfad außerhalb der Unit-Suchverzeichnisse verwandt. Für Units ohne Fragementdateien wird der Kennzeichner einen Fehler hervorrufen. |
| "%Y" | Das Verzeichnis des Fragement. | Dies ist der Verzeichnisanteil von »%y«. |
| "%%" | Einzelnes Prozentzeichen | Verwenden Sie »%%« anstelle von »%«, um ein einzelnes Prozentzeichen anzugeben. |
BEISPIELE
Beispiel 1. Units erlauben, freigegeben zu werden Der nachfolgende Schnipsel (hervorgehoben) erlaubt es einer Unit (z.B. foo.service), mittels systemctl enable freigegeben zu werden:[Unit] Description=Foo [Service] ExecStart=/usr/sbin/foo-daemon [Install] WantedBy=multi-user.target
[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
[Unit] Description=Ein HTTP-Server After=remote-fs.target sqldb.service memcached.service Requires=sqldb.service memcached.service AssertPathExists= /srv/www [Service] Type=notify ExecStart=/usr/sbin/some-fancy-httpd-server Nice=0 PrivateTmp=yes [Install] WantedBy=multi-user.target
[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
[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
[Unit]
OnFailure=failure-handler@%N.service
mkdir /etc/systemd/system/[email protected]/ ln -s /dev/null /etc/systemd/system/[email protected]/10-all.conf systemctl daemon-reload
SIEHE AUCH
systemd(1), systemctl(1), systemd-system.conf(5), systemd.special(7), systemd.service(5), systemd.socket(5), systemd.device(5), systemd.mount(5), systemd.automount(5), systemd.swap(5), systemd.target(5), systemd.path(5), systemd.timer(5), systemd.scope(5), systemd.slice(5), systemd.time(7), systemd-analyze(1), capabilities(7), systemd.directives(7), uname(1)ANMERKUNGEN
- 1.
- Schnittstellenportabilitäts- und -stabilitätszusage
- 2.
- System- und Dienste-Zugangsberechtigungen
- 3.
- PSI (Pressure Stall Information)
ÜBERSETZUNG
Die deutsche Übersetzung dieser Handbuchseite wurde von Helge Kreutzmann <[email protected]> erstellt. Diese Übersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 3 oder neuer bezüglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG übernommen. Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an die Mailingliste der Übersetzer| systemd 252 |