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

/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/*

~/.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. »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.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. »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/ 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 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¶

UNIT-DATEI-LADEPFAD¶

Unit-Dateien werden von einer Reihe von Pfaden geladen, die während der Kompilierung bestimmt werden, wie dies in den zwei Tabellen unten beschrieben ist. Unit-Dateien, die in früher aufgeführten Verzeichnissen gefunden werden, setzen Dateien mit dem gleichen Namen in Verzeichnissen, die weiter unten in der Liste aufgeführt sind, außer Kraft.

Wenn die Variable $SYSTEMD_UNIT_PATH gesetzt ist, setzt der Inhalt dieser Variable den Unit-Ladepfad außer Kraft. Falls $SYSTEMD_UNIT_PATH mit einer leeren Komponente (»:«) endet, wird der normale Unit-Ladepfad an den Inhalt der Variablen angehängt.

Tabelle 1.  Ladepfad beim Betrieb im Systemmodus (--system).

Tabelle 2.  Ladepfad bei der Ausführung im Benutzermodus
(--user).

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=

Documentation=

Wants=

Requires=

Requisite=

BindsTo=

PartOf=

Upholds=

Conflicts=

Before=, After=

OnFailure=

OnSuccess=

PropagatesReloadTo=, ReloadPropagatedFrom=

PropagatesStopTo=, StopPropagatedFrom=

JoinsNamespaceOf=

RequiresMountsFor=

OnFailureJobMode=

IgnoreOnIsolate=

StopWhenUnneeded=

RefuseManualStart=, RefuseManualStop=

AllowIsolate=

DefaultDependencies=

CollectMode=

FailureAction=, SuccessAction=

FailureActionExitStatus=, SuccessActionExitStatus=

JobTimeoutSec=, JobRunningTimeoutSec=

JobTimeoutAction=, JobTimeoutRebootArgument=

StartLimitIntervalSec=Intervall, StartLimitBurst=Häufung

StartLimitAction=

RebootArgument=

SourcePath=

ABBILDUNG VON UNIT-EIGENSCHAFTEN AUF IHR INVERSES¶

Unit-Einstellungen, die eine Beziehung zu einer zweiten Unit erstellen, zeigen sich normalerweise als Eigenschaften in beiden Units, beispielsweise in der Ausgabe von systemctl show. In einigen Fällen (aber nicht immer) ist der Name der Eigenschaft identisch mit dem Namen der Konfigurationseinstellung. Diese Tabelle listet die Eigenschaften auf, die in zwei Units angezeigt werden, die durch eine Abhängigkeit verbunden sind. Sie zeigt, welche Eigenschaft aus der »Quell«-Unit welcher Eigenschaft aus der »Ziel«-Unit entspricht.

Tabelle 3.  Vorwärts- und Rückwärts-Unit-Eigenschaften

Beachten Sie: WantedBy= und RequiredBy= werden im Abschnitt [Install] verwandt, um Symlinks in .wants/- und .requires/-Verzeichnissen zu erstellen. Sie können nicht in Unit-Konfigurationseinstellungen direkt verwandt werden.

Beachten Sie: ConsistsOf=, BoundBy=, RequisiteOf=, ConflictedBy= werden zusammen mit ihren Inversen implizit erstellt und können nicht direkt festgelegt werden.

Beachten Sie: Triggers= wird implizit zwischen einem Socket, einer Pfad-Unit oder einer Automount-Unit und der sie aktivierenden Unit erstellt. Standardmäßig wird eine Unit mit dem gleichen Namen ausgelöst, dies kann aber mit den Einstellungen Sockets=, Service= und Unit= außer Kraft gesetzt werden. Siehe systemd.service(5), systemd.socket(5), systemd.path(5) und systemd.automount(5) für ihre Details. 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=

WantedBy=, RequiredBy=

Also=

DefaultInstance=

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 4. In Unit-Dateien verfügbare Kennzeichner

BEISPIELE¶

Beispiel 1. Units erlauben, freigegeben zu werden

Der nachfolgende Schnipsel (hervorgehoben) erlaubt es einer Unit (z.B. foo.service), mittels systemctl enable freigegeben zu werden:

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

Nach der Ausführung von systemctl enable verlinkt ein Symlink /etc/systemd/system/multi-user.target.wants/foo.service auf die tatsächlich zu erstellende Unit-Datei. Er teilt Systemd mit, die Unit beim Starten von multi-user.target hereinzuziehen. Das inverse systemctl disable wird diesen Symlink wieder entfernen.

Beispiel 2. Lieferanteneinstellungen außer Kraft setzen

Es gibt zwei Methoden, die Lieferanteneinstellungen in Unit-Dateien außer Kraft zu setzen: Kopieren der Unit-Datei aus /lib/systemd/system nach /etc/systemd/system und Anpassen der gewählten Einstellungen oder alternativ durch Anlage eines Verzeichnisses namens Unit.d/ innerhalb von /etc/systemd/system und darin einer Ergänzungsdatei Name.conf, die nur die speziellen Einstellungen, an denen Sie interessiert sind, ändert. Beachten Sie, dass diese Ergänzungsdateien in lexikalischer Reihenfolge ihres Dateinamens verarbeitet werden, falls mehrere vorhanden sind.

Der Vorteil der ersten Methode besteht darin, dass normalerweise die komplette Unit außer Kraft gesetzt wird und die Unit des Lieferanten überhaupt nicht mehr ausgewertet wird. Der Nachteil besteht darin, dass Verbesserungen an der Unit-Datei durch den Lieferanten bei Aktualisierungen nicht mehr automatisch mit berücksichtigt werden.

Der Vorteil der zweiten Methode besteht darin, dass nur die genau gewünschten Einstellungen außer Kraft gesetzt und Aktualisierungen vom Lieferanten angewandt werden. Dies hat den Nachteil, dass zukünftige Aktualisierungen vom Lieferanten zu den lokalen Änderungen inkompatibel sein könnten.

Dies gilt auch für Benutzerinstanzen von Systemd, aber mit anderen Orten für die Unit-Dateien. Siehe den Abschnitt über Unit-Ladepfade für weitere Details.

Lassen Sie uns annehmen, dass es eine vom Lieferanten bereitgestellte Unit /lib/systemd/system/httpd.service mit dem folgenden Inhalt gibt:

[Unit]
Description=Ein HTTP-Server
After=remote-fs.target sqldb.service
Requires=sqldb.service
AssertPathExists=/srv/webserver
[Service]
Type=notify
ExecStart=/usr/sbin/some-fancy-httpd-server
Nice=5
[Install]
WantedBy=multi-user.target

Jetzt möchten Sie als Administrator einige Einstellungen ändern: zuerst könnte in der lokalen Installation /srv/webserver nicht existieren, da der Webserver stattdessen auf /srv/www konfiguriert ist. Zweitens hängt der HTTP-Server aufgrund der lokalen Konfiguration auch von einem Arbeitsspeicherzwischenspeicherdienst, memcached.service ab, der (mittels Requires=) hereingezogen und auch entsprechend angeordnet (mittels After=) werden soll. Drittens möchte der Administrator zur weiteren Härtung des Dienstes die Einstellung PrivateTmp= (siehe systemd.exec(5) für Details) setzen. Schließlich möchte der Administrator die Einstellung des Nice-Wertes des Dienstes auf den Vorgabewert 0 zurücksetzen.

Die erste Möglichkeit besteht darin, die Unit-Datei nach /etc/systemd/system/httpd.service zu kopieren und die ausgewählten Einstellungen zu ändern:

[Unit]
Description=Ein HTTP-Server
After=remote-fs.target sqldb.service memcached.service
Requires=sqldb.service memcached.service
AssertPathExists=/srv/www
[Service]
Type=notify
ExecStart=/usr/sbin/some-fancy-httpd-server
Nice=0
PrivateTmp=yes
[Install]
WantedBy=multi-user.target

Alternativ könnte der Administrator eine Ergänzungsdatei in /etc/systemd/system/httpd.service.d/local.conf mit folgendem Inhalt erstellen:

[Unit]
After=memcached.service
Requires=memcached.service
# Setzt alle Zusicherungen zurück and fügt dann die gewünschten Bedingungen hinzu
AssertPathExists=
AssertPathExists=/srv/www
[Service]
Nice=0
PrivateTmp=yes

Beachten Sie, dass bei Einstellungen, die als Liste ausgewertet werden (und die keine Abhängigkeit sind), wie AssertPathExists= (oder z.B. ExecStart= in Dienste-Units), zuerst die Liste bereinigt werden muss, bevor Einträge (ohne den zu entfernenden) hinzugefügt werden, falls Sie einen Eintrag von einer Einstellung entfernen möchten. Abhängigkeiten (After=, usw.) können nicht auf die leere Liste zurückgesetzt werden, daher können in Ergänzungsdateien Abhängigkeiten nur hinzugefügt werden. Falls Sie eine Abhängigkeit entfernen möchten, müssen Sie die gesamte Unit außer Kraft setzen.

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.

System- und Dienste-Zugangsberechtigungen

3.

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.