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/systemd.attached/*
/run/systemd/system/*
/run/systemd/systemd.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/*
$XDG_CONFIG_HOME/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.

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 Symlink (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.

Zusätzlich können Unit-Dateien Aliase mittels der Anweisung Alias= im Abschnitt [Install] festlegen. Wenn die Unit aktiviert ist, werden Symlinks für diese Namen erstellt und wieder entfernt, wenn die Unit deaktiviert wird. Beispielsweise legt reboot.target Alias=ctrl-alt-del.target so fest, dass der Symlink /etc/systemd/systemd/ctrl-alt-del.service auf die Datei reboot.target bei der Aktivierung erstellt wird und wenn Strg-Alt-Entf gedrückt wird, systemd nach ctrl-alt-del.service suchen und reboot.service ausführen wird. systemd schaut während des normalen Betriebs überhaupt nicht in den Abschnitt [Install], daher haben sämtliche Direktiven in diesem Abschnitt nur durch während der Aktivierung erstellte Symlinks eine Wirkung.

Das Verzeichnis foo.service.wants/ kann zusammen mit der Unit-Datei foo.service existieren. Alle Unit-Dateien, die von so einem Verzeichnis mittels Symlink verknüpft sind, werden implizit als Abhängigkeiten vom Typ Wants= für die Unit hinzugefügt. Eine ähnliche Funktionalität existiert auch für Abhängigkeiten vom Typ Requires=, die Verzeichnisendung ist in diesem Fall .requires/. Diese Funktionalität ist nützlich, um Units in den Start von anderen Units einzuhängen, ohne ihre Unit-Dateien zu verändern. Für Details über die Semantik von Wants= siehe unten. Die bevorzugte Art, Symlinks in den Verzeichnissen .wants/ oder .requires/ einer Unit-Datei zu erstellen, ist über Einbettung der Abhängigkeit in den Abschnitt [Install] der Ziel-Unit und Erstellung des Symlinks im Dateisystem mittel des Befehls enable oder preset von systemctl(1).

Zusammen mit einer Unit-Datei foo.service kann ein »Ergänzungs«-Verzeichnis foo.service.d/ existieren. Alle Dateien mit der Endung ».conf« aus diesem Verzeichnis werden, nachdem die Unit-Datei selbst ausgewertet wurde, ausgewertet. Dies ist nützlich, um die Konfigurationseinstellungen für eine Unit zu verändern oder zu ergänzen, ohne die Unit-Dateien selbst verändern zu müssen. Ergänzungsdateien müssen geeignete Abschnittskopfzeilen enthalten. Für instanziierte Units wird diese Logik zuerst nach dem Instanzen-Unterverzeichnis ».d/« (z.B. »foo@bar.service.d/«) schauen und dessen ».conf«-Dateien lesen, gefolgt von dem Vorlagenunterverzeichnis ».d/« (z.B. »foo@.service.d/«) und den ».conf«-Dateien dort. Für Unit-Namen, die desweiteren Bindestriche (»-«) enthalten, wird die Menge der Verzeichnisse, die durch 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. Konfigurationen in Typ.d/ haben den niedrigsten Vorrang im Vergleich zu Einstellungen in den namensspezifischen Außerkraftsetzungsverzeichnissen. Daher würden die Inhalte von foo-.service.d/10-override.conf service.d/10-override.conf außer Kraft setzen.

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) für seine Verwendung und Vorsichtsmaßnahmen.

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=

Conflicts=

Before=, After=

OnFailure=

PropagatesReloadTo=, ReloadPropagatedFrom=

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.

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

Ü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.