table of contents
- BEZEICHNUNG
- ÜBERSICHT
- BESCHREIBUNG
- ZEICHENKETTENMASKIERUNG FÜR DIE AUFNAHME IN UNIT-NAMEN
- AUTOMATISCHE ABHÄNGIGKEITEN
- UNIT-DATEI-LADEPFAD
- UNIT-MÜLLABFUHR
- [UNIT]-ABSCHNITT-OPTIONEN
- ABBILDUNG VON UNIT-EIGENSCHAFTEN AUF IHR INVERSES
- [INSTALL]-ABSCHNITT-OPTIONEN
- KENNZEICHNER
- BEISPIELE
- SIEHE AUCH
- ANMERKUNGEN
- ÜBERSETZUNG
- bookworm 4.18.1-1
- bookworm-backports 4.24.0-2~bpo12+1
- testing 4.24.0-2
- unstable 4.24.0-2
SYSTEMD.UNIT(5) | systemd.unit | SYSTEMD.UNIT(5) |
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.scope
System-Unit-Suchpfad¶
Benutzer-Unit-Suchpfad¶
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 »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 »\« 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.
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.
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. »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.
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.target auf die Datei reboot.target bei der Aktivierung erstellt wird und wenn Strg-Alt-Entf gedrückt wird, systemd nach ctrl-alt-del.target suchen, dem Symlink nach reboot.target folgen und reboot.service als Teil von diesem Ziel 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. »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.
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 /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.
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 getty@tty3.service angefragt wird und keine Datei mit diesem Namen gefunden wird, dann wird Systemd nach getty@.service suchen und einen Dienst aus dieser Konfigurationsdatei instanziieren, falls sie gefunden wurde.
Um sich innerhalb der Konfigurationsdatei auf die Instanziierungszeichenkette zu beziehen, können Sie den speziellen Kennzeichner »%i« in vielen Konfigurationsoptionen verwenden. Siehe unten für Details.
Falls eine Unit-Datei leer ist (d.h. die Größe 0 hat) oder ein Symlink ist, der auf /dev/null zeigt, wird seine Konfiguration nicht geladen und sie erscheint mit einem Ladezustand »masked« und kann nicht aktiviert werden. Verwenden Sie dies als wirksame Methode, um eine Unit komplett zu deaktivieren und es somit unmöglich zu machen, sie sogar manuell zu starten.
Das Unit-Dateiformat wird durch die 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 [2].
Wenn die Variable $SYSTEMD_UNIT_PATH gesetzt ist, setzt der Inhalt dieser Variable den Unit-Ladepfad außer Kraft. Falls $SYSTEMD_UNIT_PATH mit einer leeren Komponente (»:«) endet, wird der normale Unit-Ladepfad an den Inhalt der Variablen angehängt.
Tabelle 1. Ladepfad beim Betrieb im Systemmodus
(--system).
Pfad | Beschreibung |
/etc/systemd/system.control | Mittels Dbus-API erstellte dauerhafte und flüchtige Konfiguration |
/run/systemd/system.control | |
/run/systemd/transient | Dynamische Konfiguration für flüchtige Units |
/run/systemd/generator.early | Erstellte Units mit hoher Priorität (siehe early-dir in systemd.generator(7)) |
/etc/systemd/system | System-Units, die vom Administrator erstellt wurden |
/run/systemd/system | Laufzeit-Units |
/run/systemd/generator | Erstellte Units mit mittlerer Priorität (siehe normal-dir in systemd.generator(7)) |
/usr/local/lib/systemd/system | System-Units, die vom Administrator installiert wurden |
/usr/lib/systemd/system | System-Units, die durch den Paketverwalter der Distribution installiert wurden |
/run/systemd/generator.late | Erstellte Units mit niedriger Priorität (siehe late-dir in systemd.generator(7)) |
Tabelle 2. Ladepfad bei der Ausführung im
Benutzermodus (--user).
Pfad | Beschreibung |
$XDG_CONFIG_HOME/systemd/user.control 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)) |
Die Gruppe der Ladepfade für die Benutzerverwalterinstanzen kann mittels verschiedener Umgebungsvariablen ergänzt oder geändert werden. Und Umgebungsvariablen können wiederum mittels Umgebungsgeneratoren gesetzt werden, siehe systemd.environment-generator(7). Insbesondere $XDG_DATA_HOME und $XDG_DATA_DIRS können leicht mittels systemd-environment-d-generator(8) gesetzt werden. Daher sind die hier aufgeführten Verzeichnisse nur die Vorgaben. Um die tatsächlich verwandte Liste, basierend auf den Compiler-Optionen und der aktuellen Umgebung, zu sehen, verwenden Sie
systemd-analyze --user unit-paths
Desweiteren können zusätzliche Units aus Verzeichnissen, die nicht im Unit-Ladepfad sind, in Systemd hereingeladen werden, indem ein Symlink erstellt wird, der auf eine Unit-Datei im Verzeichnis zeigt. Sie können systemctl link für diese Aktion verwenden; siehe systemctl(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).
Es ist wichtig, »verlinkte Unit-Dateien« von »Unit-Dateien mit Alias« zu unterscheiden: Jeder Symlink, dessen Symlink-Ziel 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.
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:
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=
Hinzugefügt in Version 201.
Documentation=
Hinzugefügt in Version 201.
Wants=
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.
Hinzugefügt in Version 201.
Requires=
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).
Hinzugefügt in Version 201.
Requisite=
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.
Hinzugefügt in Version 201.
BindsTo=
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.
Hinzugefügt in Version 201.
PartOf=
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.
Hinzugefügt in Version 201.
Upholds=
Wenn Upholds=b.service auf a.service benutzt wird, wird diese Abhängigkeit als UpheldBy=a.service in der Eigenschaftsliste von b.service angezeigt.
Hinzugefügt in Version 249.
Conflicts=
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.
Hinzugefügt in Version 201.
Before=, After=
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.
Hinzugefügt in Version 201.
OnFailure=
Hinzugefügt in Version 201.
OnSuccess=
Hinzugefügt in Version 249.
PropagatesReloadTo=, ReloadPropagatedFrom=
Hinzugefügt in Version 201.
PropagatesStopTo=, StopPropagatedFrom=
Hinzugefügt in Version 249.
JoinsNamespaceOf=
Hinzugefügt in Version 209.
RequiresMountsFor=
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.
Hinzugefügt in Version 201.
WantsMountsFor=
Hinzugefügt in Version 256.
OnSuccessJobMode=, OnFailureJobMode=
Hinzugefügt in Version 209.
IgnoreOnIsolate=
Hinzugefügt in Version 201.
StopWhenUnneeded=
Hinzugefügt in Version 201.
RefuseManualStart=, RefuseManualStop=
Hinzugefügt in Version 201.
AllowIsolate=
Hinzugefügt in Version 201.
DefaultDependencies=
Hinzugefügt in Version 201.
SurviveFinalKillSignal=
Hinzugefügt in Version 255.
CollectMode=
Hinzugefügt in Version 236.
FailureAction=, SuccessAction=
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, kexec, kexec-force, halt, halt-force und halt-immediate die Wirkung des Herunterfahrens des Systems bzw. der Ausführung von Kexec und Anhalten 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. soft-reboot wird eine Neustartkaktion im Anwendungsraum auslösen. soft-reboot-force macht dies auch, aber durchläuft vorher die Herunterfahrtransaktion nicht.
Hinzugefügt in Version 236.
FailureActionExitStatus=, SuccessActionExitStatus=
Hinzugefügt in Version 240.
JobTimeoutSec=, JobRunningTimeoutSec=
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 DefaultDeviceTimeoutSec= 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.
Hinzugefügt in Version 201.
JobTimeoutAction=, JobTimeoutRebootArgument=
JobTimeoutRebootArgument= konfiguriert eine optionale Neustartzeichenkette, die an den Systemaufruf reboot(2) übergeben wird.
Hinzugefügt in Version 240.
StartLimitIntervalSec=Intervall, StartLimitBurst=Häufung
Intervall ist eine Zeitdauer in der Standardeinheit Sekunden, aber andere Einheiten können angegeben werden, siehe systemd.time(5). Der besondere Wert »infinity« kann zur Begrenzung der Gesamtanzahl an Startversuchen verwandt werden, selbst wenn diese in großen Zeitintervallen passieren. 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.
Hinzugefügt in Version 229.
StartLimitAction=
Hinzugefügt in Version 229.
RebootArgument=
Hinzugefügt in Version 229.
SourcePath=
Hinzugefügt in Version 201.
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=
Verwenden Sie systemd-analyze(1) für die vollständieg Liste der bekannten Architekturen.
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.
Hinzugefügt in Version 201.
ConditionFirmware=
Hinzugefügt in Version 249.
ConditionVirtualization=
Hinzugefügt in Version 244.
ConditionHost=
Hinzugefügt in Version 244.
ConditionKernelCommandLine=
Hinzugefügt in Version 244.
ConditionKernelVersion=
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.
Hinzugefügt in Version 244.
ConditionCredential=
Hinzugefügt in Version 252.
ConditionEnvironment=
Hinzugefügt in Version 246.
ConditionSecurity=
Tabelle 3. Erkannte Sicherheitstechniken
Wert | Beschreibung |
selinux | SELinux MAC |
apparmor | AppArmor MAC |
tomoyo | Tomoyo MAC |
smack | SMACK MAC |
ima | Integritätsmessungsarchitektur (IMA) |
audit | Linux-Audit-Rahmenwerk |
uefi-secureboot | Sicherer UEFI-Systemstart |
tpm2 | Trusted Platform Module 2.0 (TPM2) |
cvm | Vertrauenswürdige virtuelle Maschine (SEV/TDX) |
measured-uki | Vereinigtes Kernelabbild mit PCR-11-Messung, gemäß systemd-stub(7). Hinzugefügt in Version 255. |
Der Test kann durch Voranstellung eines Ausrufezeichens negiert werden.
Hinzugefügt in Version 244.
ConditionCapability=
Hinzugefügt in Version 244.
ConditionACPower=
Hinzugefügt in Version 244.
ConditionNeedsUpdate=
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.
Hinzugefügt in Version 244.
ConditionFirstBoot=
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.
Beachten Sie, dass der Diensteverwalter selbst Einrichtungsschritte während des ersten Systemstarts durchführen wird: er wird die machine-id(5) initialisieren und alle Units voreinstellen, sie gemäß der systemd.preset(5)-Einstellungen aktivieren oder deaktivieren. Zusätzliche Einrichtungen können mittels Units mit ConditionFirstBoot=yes durchgeführt 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.
Hinzugefügt in Version 244.
ConditionPathExists=
Hinzugefügt in Version 244.
ConditionPathExistsGlob=
Hinzugefügt in Version 244.
ConditionPathIsDirectory=
Hinzugefügt in Version 244.
ConditionPathIsSymbolicLink=
Hinzugefügt in Version 244.
ConditionPathIsMountPoint=
Hinzugefügt in Version 244.
ConditionPathIsReadWrite=
Hinzugefügt in Version 244.
ConditionPathIsEncrypted=
Hinzugefügt in Version 246.
ConditionDirectoryNotEmpty=
Hinzugefügt in Version 244.
ConditionFileNotEmpty=
Hinzugefügt in Version 244.
ConditionFileIsExecutable=
Hinzugefügt in Version 244.
ConditionUser=
Hinzugefügt in Version 244.
ConditionGroup=
Hinzugefügt in Version 244.
ConditionControlGroupController=
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:
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 systemd(1) für weitere Informationen.
Hinzugefügt in Version 244.
ConditionMemory=
Hinzugefügt in Version 244.
ConditionCPUs=
Hinzugefügt in Version 244.
ConditionCPUFeature=
Hinzugefügt in Version 248.
ConditionOSRelease=
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.
Hinzugefügt in Version 249.
ConditionMemoryPressure=, ConditionCPUPressure=, ConditionIOPressure=
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.
Hinzugefügt in Version 250.
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=
Hinzugefügt in Version 218.
ABBILDUNG VON UNIT-EIGENSCHAFTEN AUF IHR INVERSES¶
Unit-Einstellungen, die eine Beziehung zu einer zweiten Unit erstellen, zeigen sich normalerweise als Eigenschaften in beiden Units, beispielsweise in der Ausgabe von systemctl show. In einigen Fällen (aber nicht immer) ist der Name der Eigenschaft identisch mit dem Namen der Konfigurationseinstellung. Diese Tabelle listet die Eigenschaften auf, die in zwei Units angezeigt werden, die durch eine Abhängigkeit verbunden sind. Sie zeigt, welche Eigenschaft aus der »Quell«-Unit welcher Eigenschaft aus der »Ziel«-Unit entspricht.
Tabelle 4. Vorwärts- und
Rückwärts-Unit-Eigenschaften
»Vorwärts«-Eigenschaft | »Rückwärts«-Eigenschaft | Wo benutzt | |
Before= | After= | [Unit]-Abschnitt | |
After= | Before= | ||
Requires= | RequiredBy= | [Unit]-Abschnitt | [Install]-Abschnitt |
Wants= | WantedBy= | [Unit]-Abschnitt | [Install]-Abschnitt |
Upholds= | UpheldBy= | [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 |
Conflicts= | ConflictedBy= | [Unit]-Abschnitt | eine automatische Eigenschaft |
Triggers= | TriggeredBy= | automatische Eigenschaften, siehe Hinweise unten | |
PropagatesReloadTo= | ReloadPropagatedFrom= | [Unit]-Abschnitt | |
ReloadPropagatedFrom= | PropagatesReloadTo= | ||
PropagatesStopTo= | StopPropagatedFrom= | [Unit]-Abschnitt | |
StopPropagatedFrom= | PropagatesStopTo= | ||
Following= | n.Z. | eine automatische Eigenschaft |
Beachten Sie: WantedBy=, RequiredBy= und UpheldBy= 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.
Beachten Sie: ConsistsOf=, BoundBy=, RequisiteOf=, ConflictedBy= werden zusammen mit ihren Inversen implizit erstellt und können nicht direkt festgelegt werden.
Beachten Sie: Triggers= wird implizit zwischen einem Socket, einer Pfad-Unit oder einer Automount-Unit und der sie aktivierenden Unit erstellt. Standardmäßig wird eine Unit mit dem gleichen Namen ausgelöst, dies kann aber mit den Einstellungen Sockets=, Service= und Unit= außer Kraft gesetzt werden. Siehe systemd.service(5), systemd.socket(5), systemd.path(5) und systemd.automount(5) für ihre Details. TriggeredBy= wird implizit von der ausgelösten Unit erstellt.
Beachten Sie: Following= wird zur Gruppierung von Geräte-Aliassen und -Punkten zu der »primären«-Geräte-Unit, die Systemd zur Nachverfolgung des Gerätezustandes verwendet, verwandt, normalerweise entspricht dies einem Sysfs-Pfad. Dies taucht nicht in der »Ziel«-Unit auf.
[INSTALL]-ABSCHNITT-OPTIONEN¶
Unit-Dateien können einen Abschnitt »[Install]« enthalten, der Installationsinformationen für die Unit transportiert. Dieser Abschnitt wird von systemd(1) während der Laufzeit nicht interpretiert; er wird von den Befehlen enable und disable des Werkzeugs systemctl(1) während der Installation einer Unit verwandt.
Alias=
Hinzugefügt in Version 201.
WantedBy=, RequiredBy=, UpheldBy=
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/, .requires/ oder .upholds/ der aufgeführten Unit hinzugefügt. Zum Beispiel führt WantedBy=getty.target in einem Dienst getty@.service dazuz, dass systemctl enable getty@tty2.service 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 WantedBy=container@.target dazu führen, dass systemctl enable monitor@.service einen Dienste-Link container@.target.wants/monitor@.service auf monitor@.service erstellt, der für alle Instanzen von container@.target gilt.
Hinzugefügt in Version 201.
Also=
Diese Option kann mehr als einmal verwandt werden oder eine Lerraum-getrennte Liste von Unit-Namen kann übergeben werden.
Hinzugefügt in Version 201.
DefaultInstance=
Hinzugefügt in Version 215.
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:
Tabelle 5. In Unit-Dateien verfügbare
Kennzeichner
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. |
"%D" | Gemeinsames Datenverzeichnis | Dies ist entweder /usr/share (für den Systemverwalter) oder worauf der Pfad »$XDG_DATA_HOME« zeigt (für Benutzerverwalter). |
"%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
Nach der Ausführung von systemctl enable verlinkt ein Symlink /etc/systemd/system/multi-user.target.wants/foo.service auf die tatsächlich zu erstellende Unit-Datei. Er teilt Systemd mit, die Unit beim Starten von multi-user.target hereinzuziehen. Das inverse systemctl disable wird diesen Symlink wieder entfernen.
Beispiel 2. Lieferanteneinstellungen außer Kraft setzen
Es gibt zwei Methoden, die Lieferanteneinstellungen in Unit-Dateien außer Kraft zu setzen: Kopieren der Unit-Datei aus /usr/lib/systemd/system nach /etc/systemd/system und Anpassen der gewählten Einstellungen oder alternativ durch Anlage eines Verzeichnisses namens Unit.d/ innerhalb von /etc/systemd/system und darin einer Ergänzungsdatei Name.conf, die nur die speziellen Einstellungen, an denen Sie interessiert sind, ändert. Beachten Sie, dass diese Ergänzungsdateien in lexikalischer Reihenfolge ihres Dateinamens verarbeitet werden, falls mehrere vorhanden sind.
Der Vorteil der ersten Methode besteht darin, dass normalerweise die komplette Unit außer Kraft gesetzt wird und die Unit des Lieferanten überhaupt nicht mehr ausgewertet wird. Der Nachteil besteht darin, dass Verbesserungen an der Unit-Datei durch den Lieferanten bei Aktualisierungen nicht mehr automatisch mit berücksichtigt werden.
Der Vorteil der zweiten Methode besteht darin, dass nur die genau gewünschten Einstellungen außer Kraft gesetzt und Aktualisierungen vom Lieferanten angewandt werden. Dies hat den Nachteil, dass zukünftige Aktualisierungen vom Lieferanten zu den lokalen Änderungen inkompatibel sein könnten.
Dies gilt auch für Benutzerinstanzen von Systemd, aber mit anderen Orten für die Unit-Dateien. Siehe den Abschnitt über Unit-Ladepfade für weitere Details.
Lassen Sie uns annehmen, dass es eine vom Lieferanten bereitgestellte Unit /usr/lib/systemd/system/httpd.service mit dem folgenden Inhalt gibt:
[Unit] Description=Ein HTTP-Server After=remote-fs.target sqldb.service Requires=sqldb.service AssertPathExists=/srv/webserver [Service] Type=notify ExecStart=/usr/sbin/some-fancy-httpd-server Nice=5 [Install] WantedBy=multi-user.target
Jetzt möchten Sie als Administrator einige Einstellungen ändern: zuerst könnte in der lokalen Installation /srv/webserver nicht existieren, da der Webserver stattdessen auf /srv/www konfiguriert ist. Zweitens hängt der HTTP-Server aufgrund der lokalen Konfiguration auch von einem Arbeitsspeicherzwischenspeicherdienst, memcached.service ab, der (mittels Requires=) hereingezogen und auch entsprechend angeordnet (mittels After=) werden soll. Drittens möchte der Administrator zur weiteren Härtung des Dienstes die Einstellung PrivateTmp= (siehe systemd.exec(5) für Details) setzen. Schließlich möchte der Administrator die Einstellung des Nice-Wertes des Dienstes auf den Vorgabewert 0 zurücksetzen.
Die erste Möglichkeit besteht darin, die Unit-Datei nach /etc/systemd/system/httpd.service zu kopieren und die ausgewählten Einstellungen zu ändern:
[Unit] Description=Ein HTTP-Server After=remote-fs.target sqldb.service memcached.service Requires=sqldb.service memcached.service AssertPathExists=/srv/www [Service] Type=notify ExecStart=/usr/sbin/some-fancy-httpd-server Nice=0 PrivateTmp=yes [Install] WantedBy=multi-user.target
Alternativ könnte der Administrator eine Ergänzungsdatei in /etc/systemd/system/httpd.service.d/local.conf mit folgendem Inhalt erstellen:
[Unit] After=memcached.service Requires=memcached.service # Setzt alle Zusicherungen zurück and fügt dann die gewünschten Bedingungen hinzu AssertPathExists= AssertPathExists=/srv/www [Service] Nice=0 PrivateTmp=yes
Beachten Sie bei Ergänzungsdateien, dass bei Einstellungen, die als Liste ausgewertet werden (und die keine Abhängigkeit sind), wie AssertPathExists= (oder z.B. ExecStart= in Dienste-Units), zuerst die Liste bereinigt werden muss, bevor Einträge (ohne den zu entfernenden) hinzugefügt werden, falls Sie einen Eintrag von einer Einstellung entfernen möchten. Abhängigkeiten (After=, usw.) können nicht auf die leere Liste zurückgesetzt werden, daher können in Ergänzungsdateien Abhängigkeiten nur hinzugefügt werden. Falls Sie eine Abhängigkeit entfernen möchten, müssen Sie die gesamte Unit außer Kraft setzen.
Beispiel 3. Ergänzungen auf oberster Ebene mit Vorlagen-Units
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 OnFailure= für alle Dienste-Units installiert wird.
/etc/systemd/system/failure-handler@.service:
[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
Eine Instanz von failure-handler@.service kann als eine Abhängigkeit OnFailure= für alle Dienste-Units hinzugefügt werden.
/etc/systemd/system/service.d/10-all.conf:
[Unit] OnFailure=failure-handler@%N.service
Nach der Ausführung von systemctl daemon-reload werden jetzt alle Dienste ein Abhängigkeit OnFailure= 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:
mkdir /etc/systemd/system/failure-handler@.service.d/ ln -s /dev/null /etc/systemd/system/failure-handler@.service.d/10-all.conf systemctl daemon-reload
Dies stellt sicher, dass eine Instanz von failure-handler@.service fehlschlägt, falls sie keine Instanz namens failure-handler@failure-handler.service auslöst.
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.
- 💣💥🧨💥💥💣 Bitte beachten Sie, dass diese Konfigurationsdateien zu allen Zeiten verfügbar sein müssen. Falls /usr/local/ eine separate Partition ist, könnte diese während des frühen Systemstarts nicht verfügbar sein und darf dann nicht für Konfiguration verwandt werden.
- 3.
- Systemd- und Speicher-Daemons für das Wurzeldateisystem
- 4.
- System- und Dienste-Zugangsberechtigungen
- 5.
- PSI (Pressure Stall Information)
ÜBERSETZUNG¶
Die deutsche Übersetzung dieser Handbuchseite wurde von Helge Kreutzmann <debian@helgefjell.de> erstellt.
Diese Übersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 3 oder neuer bezüglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG übernommen.
Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an die Mailingliste der Übersetzer.
systemd 256.5 |