BEZEICHNUNG¶

ÜBERSICHT¶

/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/*
~/.config/systemd/user/*
/etc/systemd/user/*
$XDG_RUNTIME_DIR/systemd/user/*
/run/systemd/user/*
$XDG_RUNTIME_DIR/systemd/generator/*
~/.local/share/systemd/user/*
…
/usr/lib/systemd/user/*
$XDG_RUNTIME_DIR/systemd/generator.late/*

BESCHREIBUNG¶

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.

Unit-Dateien 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 Symlink /lib/systemd/system/dbus-org.freedesktop.network1.service erstellt wurde. Zuätzlich können Unit-Dateien Aliase mittels der Anweisung Alias= im Abschnitt [Install] festlegen. Diese Aliase sind nur wirksam, wenn die Unit aktiviert ist, dann werden Symlinks für diese Namen erstellt und wieder entfernt, wenn die Unit deaktiviert wird. Beispielsweise legt reboot.target Alias=ctrl-alt-del.target fest, daher wird sie aufgerufen, wenn sie aktiviert ist und STRG-ALT+ENTF gedrückt wird. Aliasnamen können in Befehlen wie enable, disable, start, stop, status, … und in Unit-Abhängigkeitsanweisungen Wants=, Requires=, Before=, After= mit der Einschränkung verwandt werden, dass die durch Alias= festgelegten Aliase nur wirksam sind, wenn die Unit aktiviert ist. Aliase können nicht mit dem Befehl preset verwandt werden.

Das Verzeichnis foo.service.wants/ kann zusammen mit der Unit-Datei foo.service existieren. Alle Unit-Dateien, die von so einem Verzeichnis gesymlinkt sind, werden implizit als Abhängigkeiten vom Typ Wants= für die Unit hinzugefügt. Dies 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/ einer Unit-Datei zu erstellen, ist über den Befehl enable des Werkzeugs systemctl(1), der Informationen vom Abschnitt [Install] von Unit-Dateis liest (siehe unten). Eine ähnliche Funktionalität existiert auch für Abhängigkeiten vom Typ Requires=, die Verzeichnisendung ist in diesem Fall .requires/.

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 Gedankenstriche (»-«) enthalten, wird die Menge der Verzeichnisse, die durch Abschneiden des Unit-Namens nach allen Gedankenstrichen 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 Reinlegungen 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 Gedankenstriche 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.

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.

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 eine 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 auf /dev/null gesymlinkt ist, 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 Schnittstellenstabilitätszusage[1] abgedeckt.

ZEICHENKETTENMASKIERUNG FÜR DIE AUFNAHME IN UNIT-NAMEN¶

Der Maskieralgorithmus funktioniert wie folgt: in einer gegebenen Zeichenkette wird jedes »/«-Zeichen durch »-« und alle anderen Zeichen außerhalb der ASCII alphanumerischen 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 Gedankenstrich »-« 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¶

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 (»gelinkt«) werden. Siehe den Befehl link für systemctl(1).

UNIT-MÜLLABFUHR¶

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¶

Description=

Documentation=

Requires=

Requisite=

Wants=

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=Interval, StartLimitBurst=Häufung

StartLimitAction=

RebootArgument=

ConditionArchitecture=, ConditionVirtualization=, ConditionHost=, ConditionKernelCommandLine=, ConditionKernelVersion=, ConditionSecurity=, ConditionCapability=, ConditionACPower=, ConditionNeedsUpdate=, ConditionFirstBoot=, ConditionPathExists=, ConditionPathExistsGlob=, ConditionPathIsDirectory=, ConditionPathIsSymbolicLink=, ConditionPathIsMountPoint=, ConditionPathIsReadWrite=, ConditionDirectoryNotEmpty=, ConditionFileNotEmpty=, ConditionFileIsExecutable=, ConditionUser=, ConditionGroup=, ConditionControlGroupController=

AssertArchitecture=, AssertVirtualization=, AssertHost=, AssertKernelCommandLine=, AssertKernelVersion=, AssertSecurity=, AssertCapability=, AssertACPower=, AssertNeedsUpdate=, AssertFirstBoot=, AssertPathExists=, AssertPathExistsGlob=, AssertPathIsDirectory=, AssertPathIsSymbolicLink=, AssertPathIsMountPoint=, AssertPathIsReadWrite=, AssertDirectoryNotEmpty=, AssertFileNotEmpty=, AssertFileIsExecutable=, AssertUser=, AssertGroup=, AssertControlGroupController=

SourcePath=

ABBILDUNG VON UNIT-EIGENSCHAFTEN AUF IHR INVERSES¶

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. TriggersBy= wird implizit von der ausgelösten Unit erstellt.

Beachten Sie: Following= wird zur Gruppierungen 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¶

Alias=

WantedBy=, RequiredBy=

Also=

DefaultInstance=

Die folgenden Kennzeicher werden in dem Abschnitt Install interpretiert: %n, %N, %p, %i, %j, %g, %G, %U, %u, %m, %H, %b, %v. Ihre Bedeutung ist im nächsten Abschnitt beschrieben.

KENNZEICHNER¶

Tabelle 4. In Unit-Dateien verfügbare Kennzeichner

BEISPIELE¶

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 zweite 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¶

ANMERKUNGEN¶

1.

Schnittstellenstabilitätszusage

ÜBERSETZUNG¶

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 <debian-l10n-german@lists.debian.org>.