table of contents
- BEZEICHNUNG
- ÜBERSICHT
- BESCHREIBUNG
- IMPLIZITE ABHÄNGIGKEITEN
- PFADE
- BENUTZER-/GRUPPEN-IDENTITÄTEN
- CAPABILITIES
- SICHERHEIT
- MANDATORY ACCESS CONTROL (VERFPLICHTENDE ZUGRIFFSSTEUERUNG)
- PROZESSEIGENSCHAFTEN
- SCHEDULING
- SANDBOXING
- SYSTEMAUFRUFFILTERUNG
- UMGEBUNGSVARIABLEN
- PROTOKOLLIERUNG UND STANDARD-EIN-/-AUSGABE
- ZUGANGSDATEN
- SYSTEM V-KOMPATIBILITÄT
- UMGEBUNGSVARIABLEN IN ERZEUGTEN PROZESSEN
- PROZESS-EXIT-CODES
- 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.EXEC(5) | systemd.exec | SYSTEMD.EXEC(5) |
BEZEICHNUNG¶
systemd.exec - Konfiguration der Ausführungsumgebung
ÜBERSICHT¶
Dienst.service, Socket.socket, Einhängung.mount, Auslagerung.swap
BESCHREIBUNG¶
Unit-Konfigurationsdateien für Dienste, Sockets, Einhängepunkte und Auslagerungsgeräte nutzen eine Teilmenge der Konfigurationsoptionen, die die Ausführungsumgebung von gestarteten Prozessen definieren.
Diese Handbuchseite listet die Konfigurationsoptionen auf, die von diesen vier Unit-Typen gemeinsam benutzt werden. Siehe systemd.unit(5) für die Konfiguration der von allen Unit-Typen gemeinsam benutzten Optionen und systemd.service(5), systemd.socket(5), systemd.swap(5) und systemd.mount(5) für weitere Informationen über die Konfigurationsdateioptionen, die für jeden Unit-Typen spezifisch sind. Die ausführungsspezifischen Konfigurationsoptionen werden in den Abschnitten [Service], [Socket], [Mount] oder [Swap] konfiguriert, abhängig vom Unit-Typ.
Zusätzlich werden Optionen, die verfügbare Ressourcen mittels Linux Control Groups (cgroups) steuern, in systemd.resource-control(5) aufgeführt. Diese Optionen ergänzen die hier aufgeführten Optionen.
IMPLIZITE ABHÄNGIGKEITEN¶
Einige Ausführungsparameter führen zur Ergänzung von zusätzlichen, automatischen Abhängigkeiten:
PFADE¶
Die folgenden Einstellungen können zur Änderung der Sicht eines Dienstes auf das Dateisystem verwandt werden. Bitte beachten Sie, dass die Pfade absolut sein müssen und keine »..«-Pfadkomponente enthalten dürfen.
ExecSearchPath=
WorkingDirectory=
RootDirectory=
Die Einstellungen MountAPIVFS= und PrivateUsers= sind inbesondere im Zusammenhang mit RootDirectory= nützlich. Für Details siehe unten.
Falls RootDirectory=/RootImage= zusammen mit NotifyAccess= verwandt werden, wird der Benachrichtigungs-Socket automatisch vom Rechner in die Wurzel-Umgebung eingehängt, um sicherzustellen, dass das Benachrichtigungs-Socket korrekt funktionieren kann.
Beachten Sie, dass Dienste, die RootDirectory=/RootImage= verwenden, nicht in der Lage sein werden, über das Syslog- oder Journal-Protokoll in die Protokollierinfrastruktur des Rechners zu protokollieren, außer die relevanten Sockets vom Rechner sind eingehängt, konkret:
Beispiel 1. Einhängen von Protokollier-Sockets in die Wurzel-Umgebung
BindReadOnlyPaths=/dev/log /run/systemd/journal/socket /run/systemd/journal/stdout
Diese Option ist nur für Systemdienste verfügbar oder für Dienste, die in benutzerbezogenen Instanzen des Diensteverwalters laufen, wenn nicht privilegierte Benutzernamensräume verfügbar sind.
RootImage=
Wenn DevicePolicy= auf »closed« oder »strict« gesetzt ist oder auf »auto« und DeviceAllow= gesetzt ist, dann fügt diese Einstellung /dev/loop-control mit Modus rw, »block-loop« und »block-blkext« mit Modus rwm zu DeviceAllow= hinzu. Siehe systemd.resource-control(5) für die Details über DevicePolicy= oder DeviceAllow=. Siehe auch nachfolgendes PrivateDevices=, da sie die Einstellungen von DevicePolicy= ändern könnte.
Units, die RootImage= verwenden, erlangen automatisch eine After=-Abhängigkeit auf systemd-udevd.service.
Diese Option ist nur für Systemdienste verfügbar und wird nicht für Dienste, die in benutzerbezogenene Instanzen des Diensteverwalters laufen, unterstützt.
RootImageOptions=
Gültige Partitionsnamen folgen der Spezifikation für auffindbare Partitionen[1]: root, usr, home, srv, esp, xbootldr, tmp, var.
Diese Option ist nur für Systemdienste verfügbar und wird nicht für Dienste, die in benutzerbezogenene Instanzen des Diensteverwalters laufen, unterstützt.
RootHash=
Falls das Plattenabbild eine separate Partition für /usr/ enthält, könnte sie auch Verity-geschützt sein. In diesem Fall könnte der Wurzel-Hash auch über ein erweitertes Attribut »user.verity.usrhash« oder eine Datei .usrhash in der Nähe des Plattenabbildes konfiguriert sein. Derzeit gibt es keine Option, um den Wurzel-Hash für das Dateisystem /usr/ mittels der Unit-Datei direkt zu konfigurieren.
Diese Option ist nur für Systemdienste verfügbar und wird nicht für Dienste, die in benutzerbezogenene Instanzen des Diensteverwalters laufen, unterstützt.
RootHashSignature=
Falls das Plattenabbild eine separate Partition für /usr/ enthält, könnte sie auch Verity-geschützt sein. In diesem Fall könnte die Signatur für den Wurzel-Hash auch über eine Datei .usrhash.p7s in der Nähe des Plattenabbildes konfiguriert sein. Derzeit gibt es keine Option, um die Wurzel-Hash-Signatur für das Dateisystem /usr/ mittels der Unit-Datei direkt zu konfigurieren.
Diese Option ist nur für Systemdienste verfügbar und wird nicht für Dienste, die in benutzerbezogenene Instanzen des Diensteverwalters laufen, unterstützt.
RootVerity=
Diese Option wird nur für Plattenabbilder unterstützt, die ein einzelnes Dateisystem, ohne umhüllende Partitionstabelle, enthalten. Abbilder, die eine GPT-Partitionstabelle enthalten, sollten stattdessen sowohl ein Wurzeldateisystem als auch passende Verity-Daten im gleichen Abbild enthalten, und damit die Spezifikation für auffindbare Partitionen[1] umsetzen.
Diese Option ist nur für Systemdienste verfügbar und wird nicht für Dienste, die in benutzerbezogenene Instanzen des Diensteverwalters laufen, unterstützt.
MountAPIVFS=
Um die sichere Einhängeausbreitung zur Laufzeit zu ermöglichen, wird auf dem Rechner /run/systemd/propagate zur Einrichtung neuer Einhängungen und im privaten Namensraum /run/host/incoming/ als Zwischenschritt verwandt, um diese zu speichern, bevor sie auf den endgültigen Einhängepunkt verschoben werden.
ProtectProc=
Falls der Kernel keine einhängepunktbezogenen Einhängeoptionen hidepid= unterstützt, dann bleibt diese Einstellung ohne Auswirkung und die Prozesse der Unit werden in der Lage sein, andere Prozesse zu sehen und auf sie zuzugreifen, als ob diese Option nicht verwandt worden wäre.
Diese Option ist nur für Systemdienste verfügbar und wird nicht für Dienste, die in benutzerbezogenene Instanzen des Diensteverwalters laufen, unterstützt.
ProcSubset=
Ganz ähnlich zu obigem ProtectProc= wird dies mittels Namensräumen für Dateisysteme implementiert und daher gelten die gleichen Einschränkungen: es ist nur für Systemdienste verfügbar und deaktiviert die Einhängeweiterleitung an die Einhängetabelle des Rechners und es implementiert MountAPIVFS=. Diese Einstellung wird wie bei ProtectProc= auch sauber beendet, falls der Kernel die Einhängeoption »subset=« von »procfs« nicht unterstützt..
BindPaths=, BindReadOnlyPaths=
BindPaths= erstellt reguläre, schreibbare Bind-Einhängungen (außer die Quelldateisystemeinhängung ist bereits nur-lesbar markiert), während BindReadOnlyPaths= nur-lesbare Bind-Einhängungen erstellt. Diese Einstellungen können mehr als einmal verwandt werden, jede Verwendung hängt sich an die Liste der Bind-Einhängungen der Unit an. Falls zu einer dieser zwei Optionen die leere Zeichenkette zugewiesen wird, wird die gesamte Liste an vorher definierten Bind-Einhängungen dazu zurückgesetzt. Beachten Sie, dass in diesem Fall sowohl die nur-lesbaren als auch die regulären Bind-Einhängungen zurückgesetzt werden, unabhängig davon, welche der zwei Einhängungen verwandt wird.
Diese Option ist besonders nützlich, wenn RootDirectory=/RootImage= verwandt wird. In diesem Fall bezieht sich der Quellpfad auf einen Pfad im Dateisystem des Rechners, während der Zielpfad sich auf einen Pfad unterhalb des Wurzelverzeichnisses der Unit bezieht.
Beachten Sie, dass das Zielverzeichnis existieren oder Systemd in der Lage sein muss, es zu erstellen. Daher ist es nicht möglich, diese Option für Einhängepunkte, die unterhalb von in InaccessiblePaths= oder unter /home/ und anderen geschützten Verzeichnissen verschachtelt sind, zu verwenden, falls ProtectHome=yes angegeben ist. Stattdessen sollte TemporaryFileSystem= mit »:ro« oder ProtectHome=tmpfs verwandt werden.
MountImages=
Einhängeoptionen können als eine durch einzelne Kommata getrennte Liste von Optionen definiert werden. In diesem Fall werden sie implizit auf die Wurzelpartition auf dem Abbild angewandt. Alternativ kann eine Reihe von Doppelpunkt-getrennten Tupeln von Partitionsnamen und Einhängeoptionen angegeben werden. Gültige Partitionsnamen und -Einhängeoptionen sind zu der oben beschriebenen Einstellung RootImageOptions= identisch.
Jeder Einhängedefinition darf ein »-« vorangestellt werden. In diesem Fall wird sie ignoriert, falls sein Quellpfad nicht existiert. Das Quellargument ist ein Pfad zu einem Blockgeräteknoten oder einer regulären Datei. Falls die Quelle oder das Ziel ein »:« enthält, muss dieses mit »\:« maskiert werden. Der Geräteknoten oder das Dateisystemabbild muss den gleichen Regeln folgen, wie diese für RootImage= spezifiziert sind. Alle Einhängungen, die mit dieser Option erstellt sind, sind spezifisch für die Unit, und können in der Einhängetabelle des Rechners nicht gesehen werden.
Diese Einstellung kann mehr als einmal verwandt werden. Jede Verwendung wird an die Liste der Einhängepfade der Unit angehängt. Falls die leere Zeichenkette zugewiesen wird, wird die gesamte Liste der Einhängepfade, die vorher definiert wurde, zurückgesetzt.
Beachten Sie, dass das Zielverzeichnis existieren oder Systemd in der Lage sein muss, es zu erstellen. Daher ist es nicht möglich, diese Option für Einhängepunkte, die unterhalb von in InaccessiblePaths= oder unter /home/ und anderen geschützten Verzeichnissen verschachtelt sind, zu verwenden, falls ProtectHome=yes angegeben ist.
Wenn DevicePolicy= auf »closed« oder »strict« gesetzt ist oder auf »auto« und DeviceAllow= gesetzt ist, dann fügt diese Einstellung /dev/loop-control mit Modus rw, »block-loop« und »block-blkext« mit Modus rwm zu DeviceAllow= hinzu. Siehe systemd.resource-control(5) für die Details über DevicePolicy= oder DeviceAllow=. Siehe auch nachfolgendes PrivateDevices=, da sie die Einstellungen von DevicePolicy= ändern könnte.
Diese Option ist nur für Systemdienste verfügbar und wird nicht für Dienste, die in benutzerbezogenene Instanzen des Diensteverwalters laufen, unterstützt.
ExtensionImages=
Es wird ein nur lesbares OverlayFS oberhalb der Hierarchien /usr/ und /opt/ eingerichtet. Die Reihenfolge, in der die Abbilder aufgeführt sind, wird die Reihenfolge bestimmen, in der die Überlagerung aufgebaut ist: das zuerst angegebene Abbild ist auf unterster Ebene im OverlayFS und spätere sind entsprechend darüber bis ganz oben.
Einhängeoptionen können als eine durch einzelne Kommata getrennte Liste von Optionen definiert werden. In diesem Fall werden sie implizit auf die Wurzelpartition auf dem Abbild angewandt. Alternativ kann eine Reihe von Doppelpunkt-getrennten Tupeln von Partitionsnamen und Einhängeoptionen angegeben werden. Gültige Partitionsnamen und -Einhängeoptionen sind zu der oben beschriebenen Einstellung RootImageOptions= identisch.
Jeder Einhängedefinition darf ein »-« vorangestellt werden. In diesem Fall wird sie ignoriert, falls sein Quellpfad nicht existiert. Das Quellargument ist ein Pfad zu einem Blockgeräteknoten oder einer regulären Datei. Falls der Quellpfad ein »:« enthält, muss dieses mit »\:« maskiert werden. Der Geräteknoten oder das Dateisystemabbild muss den gleichen Regeln folgen, wie diese für RootImage= spezifiziert sind. Alle Einhängungen, die mit dieser Option erstellt sind, sind spezifisch für die Unit, und können in der Einhängetabelle des Rechners nicht gesehen werden.
Diese Einstellung kann mehr als einmal verwandt werden. Jede Verwendung wird an die Liste der Abbildpfade der Unit angehängt. Falls die leere Zeichenkette zugewiesen wird, wird die gesamte Liste der Einhängepfade, die vorher definiert wurde, zurückgesetzt.
Jede Abbilddatei muss eine Datei /usr/lib/extension-release.d/extension-release.IMAGE transportieren, mit den geeigneten Metadaten, die auf RootImage=/RootDirectory= oder den Rechner passen. Siehe os-release(5).
Wenn DevicePolicy= auf »closed« oder »strict« gesetzt ist oder auf »auto« und DeviceAllow= gesetzt ist, dann fügt diese Einstellung /dev/loop-control mit Modus rw, »block-loop« und »block-blkext« mit Modus rwm zu DeviceAllow= hinzu. Siehe systemd.resource-control(5) für die Details über DevicePolicy= oder DeviceAllow=. Siehe auch nachfolgendes PrivateDevices=, da sie die Einstellungen von DevicePolicy= ändern könnte.
Diese Option ist nur für Systemdienste verfügbar und wird nicht für Dienste, die in benutzerbezogenene Instanzen des Diensteverwalters laufen, unterstützt.
ExtensionDirectories=
Es wird ein nur lesbares OverlayFS oberhalb der Hierarchien /usr/ und /opt/ eingerichtet. Die Reihenfolge, in der die Verzeichnisse aufgeführt sind, wird die Reihenfolge bestimmen, in der die Überlagerung aufgebaut ist: das zuerst angegebene Verzeichnis ist auf unterster Ebene im OverlayFS und spätere sind entsprechend darüber bis ganz oben.
Jedem in ExtensionDirectories= aufgeführten Verzeichnis darf ein »-« vorangestellt werden. In diesem Fall wird es ignoriert, falls sein Quellpfad nicht existiert. Alle Einhängungen, die mit dieser Option erstellt sind, sind spezifisch für die Unit, und können in der Einhängetabelle des Rechners nicht gesehen werden.
Diese Einstellung kann mehr als einmal verwandt werden. Jede Verwendung wird an die Liste der Verzeichnispfade der Unit angehängt. Falls die leere Zeichenkette zugewiesen wird, wird die gesamte Liste der Einhängepfade, die vorher definiert wurde, zurückgesetzt.
Jede Verzeichnis muss eine Datei /usr/lib/extension-release.d/extension-release.IMAGE enthalten, mit den geeigneten Metadaten, die auf RootImage=/RootDirectory= oder den Rechner passen. Siehe os-release(5).
Beachten Sie, dass die Verwendung aus Benutzer-Units die Unterstützung von Overlayfs in nicht privilegierten Benutzernamensräumen benötigt, welche erstmalig in Kernel v5.11. eingeführt wurde.
Diese Option ist nur für Systemdienste verfügbar oder für Dienste, die in benutzerbezogenen Instanzen des Diensteverwalters laufen, wenn nicht privilegierte Benutzernamensräume verfügbar sind.
BENUTZER-/GRUPPEN-IDENTITÄTEN¶
Diese Optionen sind nur für Systemdienste verfügbar und werden nicht für Dienste, die in benutzerbezogenen Instanzen des Diensteverwalters laufen, unterstützt.
User=, Group=
Beachten Sie, dass dies nur schwache Einschränkungen in der Namenssyntax von Benutzer/Gruppen erzwingt, aber in vielen Fällen Warnungen erzeugt, bei denen Benutzer-/Gruppennamen nicht den folgenden Regeln genügen: der angegebene Name sollte nur aus den Zeichen a-z, A-Z, 0-9, »_« und »-« (außer beim ersten Zeichen, das eines aus a-z, A-Z oder »_« sein muss, d.h. Zahlen und »-« sind als erstes Zeichen nicht erlaubt) bestehen. Der Benutzer-/Gruppenname muss mindestens ein und maximal 31 Zeichen enthalten. Diese Einschränkungen erfolgen, um Mehrdeutigkeiten zu vermeiden und um sicherzustellen, dass Benutzer-/Gruppennamen und Unit-Dateien zwischen Linux-Systemen portierbar bleiben. Für weitere Details über die akzeptierten Namen und die Namen, über die gewarnt wird, siehe Benutzer-/Gruppennamesyntax[3].
Wenn dies zusammen mit DynamicUser= verwandt wird, wird der angegebene Benutzer-/Gruppename dynamisch zum Startzeitpunkt des Dienstes zugewiesen und beim Beenden des Dienstes wieder freigegeben — außer er ist bereits statisch zugewiesen (siehe unten). Falls DynamicUser= nicht verwandt wird, muss der angegebene Benutzer und die angegebene Gruppe spätestens beim Startmoment des Dienstes statisch in der Benutzerdatenbank erzeugt worden sein, beispielsweise mit der Einrichtung sysusers.d(5), die beim Systemstart oder zum Zeitpunkt der Paketinstallation angewandt wird. Falls der Benutzer nicht existiert, wird der Programmaufruf fehlschlagen.
Falls die Einstellung User= verwandt wird, wird die Liste der zusätzlichen Gruppen aus der festgelegten Standardgruppenliste des Benutzers, wie dies durch die Benutzer- und Gruppendatenbank des Systems definiert ist, initialisiert. Zusätzliche Gruppen können durch die Einstellung SupplementaryGroups= konfiguriert werden (siehe unten).
DynamicUser=
SupplementaryGroups=
PAMName=
Beachten Sie, dass für jede Unit, die diese Option einsetzt, ein PAM-Sitzungshandhabungsprozess als Teil der Unit verwaltet und aktiv gehalten wird, solange die Unit aktiv ist, um sicherzustellen, dass geeignete Aktionen unternommen werden können, wenn die Unit und damit die PAM-Sitzung beendet wird. Dieser Prozess heißt »(sd-pam)« und ist ein direkter Kindprozess des Hauptprozesses der Unit.
Beachten Sie, dass es sehr wahrscheinlich ist (abhängig von der PAM-Konfiguration), dass der Haupt-Unit-Prozess in seine eigene Sitzungsgeltungsbereich-Unit migriert wird, wenn diese Option für eine Unit verwandt und sie aktiviert wird. Dieser Prozess wird daher zwei Units zugeordnet sein: der Unit, in der er ursprünglich gestartet wurde (und für die PAMName= konfiguriert wurde) und der Sitzungsgeltungsbereichs-Unit. Jeder Kindprozess dieses Prozesses wird allerdings nur der Sitzungsgeltungsbereichs-Unit zugeordnet sein. Dies hat Auswirkungen, wenn das in Kombination mit NotifyAccess=all verwandt wird, da diese Kindprozesse nicht in der Lage sein werden, Änderungen an der usprünglichen Unit über Benachrichtigungsmeldungen zu erreichen. Es wird angenommen, dass diese Nachrichten zu der Sitzungsgeltungsbereichs-Unit und nicht der ursprünglichen Unit gehören. Es wird daher nicht empfohlen, PAMName= in Kombination mit NotifyAccess=all zu verwenden.
CAPABILITIES¶
Diese Optionen sind nur für Systemdienste verfügbar oder für Dienste, die in benutzerbezogenen Instanzen des Diensteverwalters laufen, wenn nicht privilegierte Benutzernamensräume verfügbar sind.
CapabilityBoundingSet=
Verwenden Sie den Befehl capability von systemd-analyze(1), um eine Liste von Capabilities abzufragen, die auf dem lokalen System definiert sind.
Beispiel: Falls eine Unit die Einstellunng
CapabilityBoundingSet=CAP_A CAP_B CapabilityBoundingSet=CAP_B CAP_C
hat, dann werden CAP_A, CAP_B und CAP_C gesetzt. Falls der zweiten Zeile »~« vorangestellt wird, d.h.
CapabilityBoundingSet=CAP_A CAP_B CapabilityBoundingSet=~CAP_B CAP_C
dann wird nur CAP_A gesetzt.
AmbientCapabilities=
Umgebungs-Capabilitymengen sind nützlich, falls Sie einen Prozess als nicht privilegierter Benutzer ausführen wollen, ihm aber dennoch einige Capabilities geben möchten. Beachten Sie, dass in diesem Fall die Option keep-caps automatisch zu SecureBits= hinzugefügt wird, um die Capabilities über den Benutzerwechsel hinweg zu erhalten. AmbientCapabilities= betrifft keine Befehle, denen »+« vorangestellt ist.
SICHERHEIT¶
NoNewPrivileges=
SecureBits=
MANDATORY ACCESS CONTROL (VERFPLICHTENDE ZUGRIFFSSTEUERUNG)¶
Diese Optionen sind nur für Systemdienste verfügbar und werden nicht für Dienste, die in benutzerbezogenen Instanzen des Diensteverwalters laufen, unterstützt.
SELinuxContext=
AppArmorProfile=
SmackProcessLabel=
Diesem Wert kann »-« vorangestellt werden, wodurch alle Fehler ignoriert werden. Ein leerer Wert kann angegeben werden, um alle vorhergehenden Zuweisungen zurückzusetzen. Dies betrifft keine Befehle, denen »+« vorangestellt ist.
PROZESSEIGENSCHAFTEN¶
LimitCPU=, LimitFSIZE=, LimitDATA=, LimitSTACK=, LimitCORE=, LimitRSS=, LimitNOFILE=, LimitAS=, LimitNPROC=, LimitMEMLOCK=, LimitLOCKS=, LimitSIGPENDING=, LimitMSGQUEUE=, LimitNICE=, LimitRTPRIO=, LimitRTTIME=
Beachten Sie, dass die meisten der mit diesen Optionen konfigurierten Ressourcenbeschränkungen prozessbezogen sind. Prozesse können einen Fork durchführen, um einen neuen Satz an Ressourcen zu erlangen. Diese neuen Ressourcen können unabhängig vom ursprünglichen Prozess verbucht werden und daher gesetzten Beschränkungen entkommen.Beachten Sie auch, dass LimitRSS= unter Linux nicht implementiert ist und das Setzen keinen Effekt hat. Oft ist es ratsam, die in systemd.resource-control(5) aufgeführten Ressourcensteuerungen gegenüber den prozessabhängigen zu bevorzugen, da sie, auf Dienste als ganzes angewandt, zur Laufzeit verändert werden und im Allgemeinen ausdrucksstärker sind. Beispielsweise ist MemoryMax= ein leistungsfähigerer (und funktionierender) Ersatz für LimitRSS=.
Beachten Sie, dass LimitNPROC= die Anzahl der Prozesse einer (echten) UID begrenzen wird und nicht die Anzahl der vom Dienst (mit Fork) gestarteten Prozesse. Daher ist diese Begrenzung für alle unter der gleichen UID laufenden Prozesse kumulierend. Bitte beachten Sie auch, dass LimitNPROC= nicht durchgesetzt wird, falls der Dienst als root läuft (und seine Privilegien nicht abgibt). Aufgrund dieser Einschränkungen ist TasksMax= (siehe systemd.resource-control(5)) typischerweise eine bessere Wahl als LimitNPROC=.
Nicht explizit konfigurierte Ressourcenbeschränkungen für eine Unit verwenden als Vorgabe die in den verschiedenen in systemd-system.conf(5) verfügbaren Optionen DefaultLimitCPU=, DefaultLimitFSIZE=, … konfigurierten Werte und – falls sie dort nicht konfiguriert sind – die Kernel- oder benutzerbezogenen Vorgaben, wie sie durch das Betriebssystem (Letzteres nur für Benutzerdienste, siehe unten) definiert sind.
Für System-Units können diese Ressourcenbeschränkungen frei gewählt werden. Wenn diese Einstellungen in einem Benutzerdienst (d.h. einem Dienst, der von der benutzerbezogenen Instanz des Diensteverwalters ausgeführt wird) konfiguriert sind, können sie nicht zum Anheben der Beschränkungen über die Werte, die für den Benutzerverwalter beim ersten Aufruf selbst gesetzt sind, verwandt werden, da dem Benutzerverwalter im Allgemeinen hierfür die Privilegien fehlen. Im Benutzerkontext sind diese Konfigurationsoptionen daher nur nützlich, um die hereingegebenen Beschränkungen zu senken oder für den Benutzer konfigurierten weichen Beschränkungen maximal auf die harten Beschränkungen anzuheben. Um die Benutzerbeschränkungen weiter anzuheben, unterscheiden sich die verfügbaren Konfigurationsmechanismen zwischen Betriebssystemen, benötigen aber typischerweise Privilegien. In den meisten Fällen ist es möglich, höhere benutzerbezogene Ressourcenbeschränkungen mittels PAM zu konfigurieren oder durch Setzen von Beschränkungen auf den System-Dienst, der den Diensteverwalter des Benutzers einkapselt, d.h. der Instanz von user@.service des Benutzers. Starten Sie den Diensteverwalter des Benutzers neu, nachdem Sie solche Änderungen vorgenommen haben.
Tabelle 1. Ressourcenbegrenzungsanweisungen, ihre
äquivalenten
Ulimit-Shell-Befehle und die verwandte Einheit
Anweisung | ulimit-Äquivalent | Einheit |
LimitCPU= | ulimit -t | Sekunden |
LimitFSIZE= | ulimit -f | Bytes |
LimitDATA= | ulimit -d | Bytes |
LimitSTACK= | ulimit -s | Bytes |
LimitCORE= | ulimit -c | Bytes |
LimitRSS= | ulimit -m | Bytes |
LimitNOFILE= | ulimit -n | Anzahl an Dateideskriptoren |
LimitAS= | ulimit -v | Bytes |
LimitNPROC= | ulimit -u | Anzahl an Prozessen |
LimitMEMLOCK= | ulimit -l | Bytes |
LimitLOCKS= | ulimit -x | Anzahl an Sperren |
LimitSIGPENDING= | ulimit -i | Anzahl von Signalen in der Warteschlange |
LimitMSGQUEUE= | ulimit -q | Bytes |
LimitNICE= | ulimit -e | Nice-Stufe |
LimitRTPRIO= | ulimit -r | Echtzeitpriorität |
LimitRTTIME= | Kein Äquivalent | Mikrosekunden |
UMask=
CoredumpFilter=
Beispiel 2. DAX-Seiten zum Speicherauszugsfilter hinzufügen
CoredumpFilter=default private-dax shared-dax
KeyringMode=
OOMScoreAdjust=
Verwenden Sie die Einstellung OOMPolicy= von Dienste-Units, um zu konfigurieren, wie der Diensteverwalter darauf reagieren soll, wenn der OOM-Killer oder systemd-oomd einen Prozess des Dienstes beendet. Siehe systemd.service(5) für Details.
TimerSlackNSec=
Personality=
IgnoreSIGPIPE=
SCHEDULING¶
Nice=
CPUSchedulingPolicy=
CPUSchedulingPriority=
CPUSchedulingResetOnFork=
CPUAffinity=
NUMAPolicy=
NUMAMask=
IOSchedulingClass=
IOSchedulingPriority=
SANDBOXING¶
Die nachfolgenden Sandboxing-Optionen bieten eine wirksame Art, die Kontakte des Systems im Hinblick auf die Prozesse der Unit zu begrenzen. Es wird empfohlen, so viele dieser Optionen wie möglich, ohne die Betriebsfähigkeit der Prozesse der Unit negativ zu betreffen, einzuschalten. Beachten Sie, dass viele dieser Sandboxing-Funktionalitäten beschwerdefrei auf Systemen, auf denen der unterliegende Sicherheitsmechanismus nicht verfügbar ist, ausgeschaltet werden. Beispielsweise hat ProtectSystem= keine Wirkung, falls der Kernel ohne Namensräume für Dateisysteme gebaut wurde oder falls der Diensteverwalter in einem Container-Verwalter ausgeführt wird, der dafür sorgt, dass Dateisystem-Namensräume für seine Nutzlast nicht verfügbar sind. Ähnlich hat RestrictRealtime= auf Systemen keine Wirkung, denen die Unterstützung für SECCOMP-Systemaufruffilterung fehlt oder in Containern, in denen die Unterstützung dafür abgeschaltet ist.
Beachten Sie auch, dass einige Sandboxing-Funktionalität im Allgemeinen in Benutzerdiensten (d.h. Diensten, die vom benutzerbezogenen Diensteverwalter ausgeführt werden) nicht verfügbar ist. Insbesondere die verschiedenen Einstellungen, die die Unterstützung für Dateisystem-Namensräume benötigen (wie ProtectSystem=) sind nicht verfügbar, da die zugrundeliegende Kernelfunktionalität nur für privilegierte Prozesse erreichbar ist. Allerdings werden die meisten Namensraum-Einstellungen, die nicht in ihrem eigenen Benutzerdienst funktionieren, bei der Verwendung zusammen mit PrivateUsers=true funktionieren.
ProtectSystem=
ProtectHome=
Setzen dieser Einstellung auf »yes« ist fast äquivalent zum Setzen der drei Verzeichnisse in InaccessiblePaths=. Ähnlich ist »read-only« fast äquivalent zu ReadOnlyPaths= und »tmpfs« ist fast äquivalent zu TemporaryFileSystem= mit »:ro«.
Es wird empfohlen, diese Einstellung für alle langlaufenden Dienste (insbesondere solchen zu Netzen) zu aktivieren, um sicherzustellen, dass sie keinen Zugriff auf private Benutzerdaten bekommen, außer der Dienst benötigt tatsächlich Zugriff auf die privaten Daten der Benutzer. Diese Einstellung ist impliziert, falls DynamicUser= gesetzt ist. Diese Einstellung kann nicht für alle Fälle den Schutz sicherstellen. Im Allgemeinen hat es die gleichen Begrenzungen wie ReadOnlyPaths=, siehe unten.
Diese Option ist nur für Systemdienste verfügbar oder für Dienste, die in benutzerbezogenen Instanzen des Diensteverwalters laufen, wenn nicht privilegierte Benutzernamensräume verfügbar sind.
RuntimeDirectory=, StateDirectory=, CacheDirectory=, LogsDirectory=, ConfigurationDirectory=
Tabelle 2. Automatische Verzeichniserstellung
und
Umgebungsvariablen
Verzeichnis | Unterhalb vom Pfad von System-Units | Unterhalb vom Pfad von Benutzer-Units | Umgebungsvariablenmenge |
RuntimeDirectory= | /run/ | $XDG_RUNTIME_DIR | $RUNTIME_DIRECTORY |
StateDirectory= | /var/lib/ | $XDG_CONFIG_HOME | $STATE_DIRECTORY |
CacheDirectory= | /var/cache/ | $XDG_CACHE_HOME | $CACHE_DIRECTORY |
LogsDirectory= | /var/log/ | $XDG_CONFIG_HOME/log/ | $LOGS_DIRECTORY |
ConfigurationDirectory= | /etc/ | $XDG_CONFIG_HOME | $CONFIGURATION_DIRECTORY |
Im Falle von RuntimeDirectory= werden die innersten Unterverzeichnisse entfernt, wenn die Unit gestoppt wird. Es ist möglich, in diesem Fall die festgelegten Verzeichnisse zu erhalten, falls RuntimeDirectoryPreserve= auf restart oder yes konfiguriert ist (siehe unten). Die mit StateDirectory=, CacheDirectory=, LogsDirectory=, ConfigurationDirectory= festgelegten Verzeichnisse werden nicht entfernt, wenn die Unit gestoppt wird.
Außer im Fall von ConfigurationDirectory= werden die innersten festgelegten Verzeichnisse dem in User= und Group= angegebenem Benutzer und der Gruppe gehören. Falls die angegebenen Verzeichnisse bereits existieren und ihre besitzenden Benutzer und Gruppe nicht auf die konfigurierten passen, werden alle Dateien und Verzeichnisse unterhalb der angegebenen Verzeichnisse sowie alle Verzeichnisse selbst rekursiv geändert, so dass die Eigentümerschaft auf die konfigurierte passt. Falls die angegebenen Verzeichnisse bereits dem richtigen Benutzer und der richtigen Gruppe gehören, werden als Optimierung alle Dateien und Verzeichnisse darunter unverändert gelassen, selbst falls sie nicht auf das angeforderte passen. Die Zugriffsmodi der innersten angegebenen Verzeichnisse wird auf das, was in RuntimeDirectoryMode=, StateDirectoryMode=, CacheDirectoryMode=, LogsDirectoryMode= und ConfigurationDirectoryMode= festgelegt ist, angepasst.
Diese Optionen implizieren BindPaths= für die festgelegten Pfade. Bei der Kombination mit RootDirectory= oder RootImage= werden diese Pfade immer innerhalb des Rechners liegen und von dort in den Dateisystemnamensraum der Unit eingehängt.
Falls DynamicUser= verwandt wird, ändert sich die Logik für CacheDirectory=, LogsDirectory= und StateDirectory= leicht: die Verzeichnisse werden unterhalb /var/cache/private, /var/log/private bzw. /var/lib/private erstellt, die Verzeichnisse des Rechners sind, die für nicht privilegierte Benutzer nicht zugreifbar sind. Dadurch wird sichergestellt, dass Zugriff auf diese Verzeichnisse nicht über die Wiederverwendung dynamischer Benutzerkennungen möglich ist. Symbolische Links werden erstellt, um diese Unterschiede im Verhalten zu verstecken. Daher tauchen sowohl aus Sicht des Rechners als auch aus innerhalb der Unit die relevanten Verzeichnisse immer direkt unter /var/cache, /var/log und /var/lib auf.
Verwenden Sie RuntimeDirectory=, um eine oder mehrere Laufzeitverzeichnisse für die Unit zu verwalten und ihre Lebensdauer an die Lebensdauer des Daemons zu koppeln. Dies ist insbesonders für nicht privilegierte Daemons nützlich, die aufgrund fehlender Privilegien keine Laufzeitverzeichnisse in /run/ erstellen können und um sicherzustellen, dass die Laufzeitverzeichnisse nach der Verwendung automatisch bereinigt werden. Für Laufzeitverzeichnisse, die eine komplexere oder andere Konfiguration oder Lebensdauergarantie benötigen, prüfen Sie den Einsatz von tmpfiles.d(5).
RuntimeDirectory=, StateDirectory=, CacheDirectory= und LogsDirectory= unterstützen optional einen zweiten Parameter, der durch »:« abgetrennt wird. Der zweite Parameter wird als Zielpfad interpretiert, der als Symlink auf das Verzeichnis erstellt wird. Die Symlinks werden erstellt, nachdem alle Optionen BindPaths= oder TemporaryFileSystem= eingerichtet wurden, um flüchtige Symlinks zu ermöglichen. Die gleiche Quelle kann mehrere Symlnks haben, indem der gleiche erste Parameter, aber ein verschiedener zweiter Parameter verwandt wird.
Die durch diese Optionen definierten Verzeichnisse werden immer unter den von Systemd verwandten Standardpfaden (/var/, /run/, /etc/ …) erstellt. Falls der Dienst Verzeichnisse an einem anderen Ort benötigt, muss ein anderer Mechanismus zu deren Erstellung verwandt werden.
tmpfiles.d(5) stellt Funktionalität bereit, die sich mit diesen Optionen überlappt. Es wird empfohlen, dass diese Optionen eingesetzt werden, da die Lebensdauer der Verzeichnisse an die Lebensdauer der Unit gekoppelt ist, und es nicht notwendig ist, sicherzustellen, dass die tmpfiles.d-Konfiguration vor dem Start der Unit ausgeführt wird.
Um alle von diesen Einstellungen erzeugten Verzeichnisse zu entfernen, verwenden Sie den Befehl systemctl clean … auf die relevanten Units, siehe systemctl(1) für Details.
Beispiel: Falls eine Systemdienste-Unit
RuntimeDirectory=foo/bar baz
enthält, erstellt der Diensteverwalter /run/foo (falls es noch nicht existiert), /run/foo/bar und /run/baz. Die Verzeichnisse /run/foo/bar und /run/baz außer /run/foo gehören dem Benutzer und der Gruppe, die in User= und Group= angegeben sind und werden entfernt, wenn der Dienst gestoppt wird.
Beispiel: Falls eine Systemdienste-Unit
RuntimeDirectory=foo/bar StateDirectory=aaa/bbb ccc
enthält, dann wird die Umgebungsvariable »RUNTIME_DIRECTORY« mit »/run/foo/bar« und »STATE_DIRECTORY« mit »/var/lib/aaa/bbb:/var/lib/ccc« gesetzt.
Beispiel: Falls eine Systemdienste-Unit
RuntimeDirectory=foo:bar foo:baz
Der Diensteverwalter erstellt /run/foo (falls es noch nicht existiert) und /run/bar sowie /run/baz als Symlinks auf /run/foo.
RuntimeDirectoryMode=, StateDirectoryMode=, CacheDirectoryMode=, LogsDirectoryMode=, ConfigurationDirectoryMode=
RuntimeDirectoryPreserve=
TimeoutCleanSec=
ReadWritePaths=, ReadOnlyPaths=, InaccessiblePaths=, ExecPaths=, NoExecPaths=
In ReadWritePaths= aufgeführte Pfade sind von innerhalb des Namensraums mit den gleichen Zugriffsmodi wie von außerhalb zugreifbar. Auf in ReadOnlyPaths= aufgeführte Pfade kann nur lesend zugegriffen werden, Schreiben wird abgelehnt, selbst falls die normale Dateizugriffssteuerung dies erlauben würde. Schachteln Sie ReadWritePaths= innerhalb von ReadOnlyPaths=, um schreibbare Unterverzeichnisse innerhalb nur lesbarer Verzeichnisse bereitzustellen. Verwenden Sie ReadWritePaths=, um bestimmte Pfade für den Schreibzugriff freizuschalten, falls ProtectSystem=strict verwandt wird.
In InaccessiblePaths= aufgeführte Pfade, einschließlich der Dateisystemhierarchie darunter, werden für Prozesse innerhalb des Namensraums unzugreifbar gemacht. Dies könnte restriktiver als gewünscht sein, da es nicht möglich ist, darin ReadWritePaths=, ReadOnlyPaths=, BindPaths= oder BindReadOnlyPaths= zu verschachteln. Für eine flexiblere Option siehe TemporaryFileSystem=.
Inhalte in den in NoExecPaths= aufgeführten Pfaden können nicht ausgeführt werden, selbst falls die gewöhnliche Zugriffskontrolle dies erlauben würde. Verschachteln Sie ExecPaths= innerhalb von NoExecPaths=, um ausführbaren Inhalt innerhalb nichtausführbarer Verzeichnisse bereitzustellen.
Es können auch Pfade, die keine Verzeichnisse sind, angegeben werden. Diese Optionen können mehr als einmal angegeben werden, dann haben alle aufgeführten Pfade von innerhalb des Namensraums aus beschränkten Zugriff. Falls dieser Option die leere Zeichenkette zugewiesen wird, wird die Liste zurückgesetzt und alle vorherigen Zuweisungen haben keinen Effekt.
Pfaden in ReadWritePaths=, ReadOnlyPaths=, InaccessiblePaths=, ExecPaths= und NoExecPaths= kann ein »-« vorangestellt werden, wodurch sie ignoriert werden, falls sie nicht existieren. Falls ihnen »+« vorangestellt wird, werden die Pfade als relativ zum Wurzelverzeichnis der Unit akzeptiert, wie dies mit RootDirectory=/RootImage= konfiguriert ist, statt relativ zum Wurzelverzeichnis des Rechners (siehe oben). Wenn Sie »-« und »+« auf dem gleichen Pfad kombinieren, verwenden Sie »-« zuerst und danach »+«.
Beachten Sie, dass diese Einstellungen die Ausbreitung von Einhängungen von den Prozessen einer Unit zum Rechner abtrennt. Dies bedeutet, dass diese Einstellung nicht für Dienste benutzt werden darf, die in der Lage sein müssen, Einhängepunkte im Haupteinhängenamensraum zu installieren. Die ReadWritePaths=- und ReadOnlyPaths=-Ausbreitung in die andere Richtung ist nicht betroffen, d.h. Einhängungen, die im Rechner erstellt werden, tauchen im Allgemeinen im Namensraum der Unit auf und Einhängungen, die auf dem Rechner entfernt werden, verschwinden auch dort. Beachten Sie insbesondere, dass die Einhängeausbreitung vom Rechner zu der Unit dazu führt, dass unveränderte Einhängungen im Namensraum der Unit erstellt werden, d.h. schreibbare Einhängungen, die auf dem Rechner auftauchen, werden auch im Namensraum der Unit schreibbar sein, selbst wenn sie zu einem Pfad ausgebreitet werden, der mit ReadOnlyPaths= markiert ist! Daher wird die Zugriffseinschränkung mit diesen Optionen nicht auf Untereinhängungen eines Verzeichnisses, das später erstellt wird, ausgeweitet. Dies bedeutet, dass die durch diese Einstellung angebotene Sperrung nicht vollständig ist und keinen vollständigen Schutz bietet.
Beachten Sie, dass die Wirkung dieser Einstellung durch privilegierte Prozesse zurückgenommen werden kann. Um eine wirksame Sandbox-Umgebung für eine Unit einzurichten, wird daher empfohlen, diese Einstellungen mit entweder CapabilityBoundingSet=~CAP_SYS_ADMIN oder SystemCallFilter=~@mount zu kombinieren.
Beispiel für eine einfache Erlaubnisliste mittels dieser Direktiven:
[Service] ReadOnlyPaths=/ ReadWritePaths=/var /run InaccessiblePaths=-/lost+found NoExecPaths=/ ExecPaths=/usr/sbin/mein_Daemon /lib /lib64
Diese Optionen sind nur für Systemdienste verfügbar oder für Dienste, die in benutzerbezogenen Instanzen des Diensteverwalters laufen, wenn nicht privilegierte Benutzernamensräume verfügbar sind.
TemporaryFileSystem=
Dies ist nützlich, um Dateien oder Verzeichnisse, die für die von der Unit gestarteten Prozesse nicht relevant sind, zu verstecken, während auf notwendige Dateien oder Verzeichnisse durch Kombination mit BindPaths= oder BindReadOnlyPaths= weiterhin zugegriffen werden kann:
Beispiel: Falls eine Unit die Einstellunng
TemporaryFileSystem=/var:ro BindReadOnlyPaths=/var/lib/systemd
Der durch die Unit aufgerufene Prozess kann dann keine Dateien, Verzeichnisse oder Inhalte unter /var/ außer /var/lib/systemd sehen.
Diese Option ist nur für Systemdienste verfügbar oder für Dienste, die in benutzerbezogenen Instanzen des Diensteverwalters laufen, wenn nicht privilegierte Benutzernamensräume verfügbar sind.
PrivateTmp=
Beachten Sie, dass die Implementierung dieser Einstellung unmöglich sein könnte (beispielsweise, falls Einhängenamensräume nicht verfügbar sind) und dass die Unit auf eine Art geschrieben sein sollte, die sich nicht ausschließlich auf diese Einstellung für die Sicherheit verlässt.
Diese Option ist nur für Systemdienste verfügbar oder für Dienste, die in benutzerbezogenen Instanzen des Diensteverwalters laufen, wenn nicht privilegierte Benutzernamensräume verfügbar sind.
PrivateDevices=
Aktivieren dieser Option wird einen Systemaufruffilter installieren, um systemnahe E/A-Systemaufrufe, die in der Gruppe @raw-io versammelt sind, zu blockieren, CAP_MKNOD und CAP_SYS_RAWIO aus der Capability-Begrenzungsmenge für die Unit zu entfernen und DevicePolicy=closed zu setzen (siehe systemd.resource-control(5) für Details). Beachten Sie, dass die Verwendung dieser Einstellung die Ausbreitung von Einhängungen aus dem Dienst zum Rechner trennen wird (Ausbreitung in die umgekehrte Richtung wird weiterhin funktionieren). Dies bedeutet, dass diese Einstellung nicht für Dienste benutzt werden kann, die in der Lage sein sollen, Einhängepunkte in dem Haupteinhängeraum zu installieren. Das neue /dev/ wird nur lesbar und »noexec« eingehängt. Letzteres könnte alte Programme beschädigen, die mit mmap(2) aus /dev/zero ausführbaren Speicher einrichten, statt MAP_ANON zu verwenden. Für diese Einstellung gelten die gleichen Einschränkungen im Hinblick auf Einhängeausbreitung und Privilegien wie für ReadOnlyPaths= und verwandte Aufrufe, siehe oben. Falls dies eingeschaltet und im Benutzermodus oder im Systemmodus aber ohne die Capability CAP_SYS_ADMIN (z.B. durch Setzen von User=) betrieben wird, wird NoNewPrivileges=yes impliziert.
Beachten Sie, dass die Implementierung dieser Einstellung unmöglich sein könnte (beispielsweise, falls Einhängenamensräume nicht verfügbar sind) und dass die Unit auf eine Art geschrieben sein sollte, die sich nicht ausschließlich auf diese Einstellung für die Sicherheit verlässt.
Diese Option ist nur für Systemdienste verfügbar oder für Dienste, die in benutzerbezogenen Instanzen des Diensteverwalters laufen, wenn nicht privilegierte Benutzernamensräume verfügbar sind.
Wenn Zugriff auf einige aber nicht alle Geräte möglich sein soll, kann stattdessen die Einstellung DeviceAllow= verwandt werden. Siehe systemd.resource-control(5).
PrivateNetwork=
Beachten Sie, dass die Implementierung dieser Einstellung unmöglich sein könnte (beispielsweise, falls Netzwerknamensräume nicht verfügbar sind) und dass die Unit auf eine Art geschrieben sein sollte, die sich nicht ausschließlich auf diese Einstellung für die Sicherheit verlässt.
Wenn diese Option auf einer Socket-Unit verwandt wird, dann werden alle im Auftrag dieser Unit angebundenen Sockets innerhalb eines privaten Netzwerknamensraums angebunden. Dies kann mit JoinsNamespaceOf= kombiniert werden, um auf Sockets innerhalb von Netzwerknamensräumen von anderen Diensten auf Anfragen zu warten.
Diese Option ist nur für Systemdienste verfügbar oder für Dienste, die in benutzerbezogenen Instanzen des Diensteverwalters laufen, wenn nicht privilegierte Benutzernamensräume verfügbar sind.
NetworkNamespacePath=
Wenn diese Option auf einer Socket-Unit verwandt wird, dann werden alle Sockets, die im Auftrag dieser Units angebunden sind, innerhalb des festgelegten Netzwerknamensraums angebunden.
Diese Option ist nur für Systemdienste verfügbar oder für Dienste, die in benutzerbezogenen Instanzen des Diensteverwalters laufen, wenn nicht privilegierte Benutzernamensräume verfügbar sind.
PrivateIPC=
Beachten Sie, dass IPC-Namensräume keinerlei Auswirkung auf AF_UNIX-Sockets haben, die die häufigste Form von IPC unter Linux sind. Stattdessen unterliegen AF_UNIX in dem Dateisystem den Einhängenamensräumen. IPC-Namensräume haben nur eine Auswirkung auf SysV-IPC (was größtenteils veraltet ist), sowie POSIX-Nachrichtenwarteschlangen (für die AF_UNIX-/SOCK_SEQPACKET-Sockets typischerweise die bessere Alternative sind). IPC-Namensräume haben auch keine Auswirkungen auf gemeinsam benutzten Speicher gemäß POSIX (der Einhängenamensräumen unterliegt). Siehe ipc_namespaces(7) für Details.
Beachten Sie, dass die Implementierung dieser Einstellung unmöglich sein könnte (beispielsweise, falls IPC-Namensräume nicht verfügbar sind) und dass die Unit auf eine Art geschrieben sein sollte, die sich nicht ausschließlich auf diese Einstellung für die Sicherheit verlässt.
Diese Option ist nur für Systemdienste verfügbar oder für Dienste, die in benutzerbezogenen Instanzen des Diensteverwalters laufen, wenn nicht privilegierte Benutzernamensräume verfügbar sind.
IPCNamespacePath=
Diese Option ist nur für Systemdienste verfügbar oder für Dienste, die in benutzerbezogenen Instanzen des Diensteverwalters laufen, wenn nicht privilegierte Benutzernamensräume verfügbar sind.
PrivateUsers=
Wenn diese Einstellung durch eine benutzerbezogene Instanz des Diensteverwalters eingerichtet ist, entfällt die Abbildung des Benutzers und der Gruppe »root« auf sich selbst (außer der Benutzerverwalter ist root). Im Falle des benutzerbezogenen Instanzverwalters wird der Namensraum zusätzlich vor den meisten anderen Namensräumen eingerichtet. Das bedeutet, dass die Kombination von PrivateUsers=true mit anderen Namensräumen die Verwendung von Funktionalitäten aktiviert, die normalerweise von benutzerbezogenen Instanzen des Diensteverwalters nicht unterstützt werden.
Diese Einstellung ist insbesondere im Zusammenspiel mit RootDirectory=/RootImage= nützlich, da die Notwendigkeit, die Benutzer- und Gruppendatenbank im Wurzelverzeichnis und dem Gesamtsystem zu synchronisieren, reduziert wird, da die einzigen Benutzer und Gruppen, die angepasst werden müssen, »root«, »nobody« und der Benutzer und die Gruppe der Unit selbst sind.
Beachten Sie, dass die Implementierung dieser Einstellung unmöglich sein könnte (beispielsweise, falls Benutzernamensräume nicht verfügbar sind) und dass die Unit auf eine Art geschrieben sein sollte, die sich nicht ausschließlich auf diese Einstellung für die Sicherheit verlässt.
ProtectHostname=
Beachten Sie, dass die Implementierung dieser Einstellung unmöglich sein könnte (beispielsweise, falls UTS-Namensräume nicht verfügbar sind) und dass die Unit auf eine Art geschrieben sein sollte, die sich nicht ausschließlich auf diese Einstellung für die Sicherheit verlässt.
Beachten Sie, dass Änderungen des »hostname« sich nicht länger vom System in den Dienst ausbreiten, wenn diese Option für einen Dienst aktiviert ist. Daher ist sie nicht für Dienste geeignet, die dynamisch die Änderung des »hostname« des Systems beachten sollen.
Falls diese Einstellung eingeschaltet ist, aber die Unit nicht über die Capability CAP_SYS_ADMIN verfügt (d.h. für Dienste, bei denen User= gesetzt ist), wird NoNewPrivileges=yes impliziert.
Diese Option ist nur für Systemdienste verfügbar oder für Dienste, die in benutzerbezogenen Instanzen des Diensteverwalters laufen, wenn nicht privilegierte Benutzernamensräume verfügbar sind.
ProtectClock=
Diese Option ist nur für Systemdienste verfügbar oder für Dienste, die in benutzerbezogenen Instanzen des Diensteverwalters laufen, wenn nicht privilegierte Benutzernamensräume verfügbar sind.
ProtectKernelTunables=
Diese Option ist nur für Systemdienste verfügbar oder für Dienste, die in benutzerbezogenen Instanzen des Diensteverwalters laufen, wenn nicht privilegierte Benutzernamensräume verfügbar sind.
ProtectKernelModules=
Diese Option ist nur für Systemdienste verfügbar oder für Dienste, die in benutzerbezogenen Instanzen des Diensteverwalters laufen, wenn nicht privilegierte Benutzernamensräume verfügbar sind.
ProtectKernelLogs=
Diese Option ist nur für Systemdienste verfügbar oder für Dienste, die in benutzerbezogenen Instanzen des Diensteverwalters laufen, wenn nicht privilegierte Benutzernamensräume verfügbar sind.
ProtectControlGroups=
Diese Option ist nur für Systemdienste verfügbar und wird nicht für Dienste, die in benutzerbezogenene Instanzen des Diensteverwalters laufen, unterstützt.
RestrictAddressFamilies=
Verwenden Sie diese Option, um den Kontakt des Prozesses für Zugriff aus der Ferne, insbesondere über exotische und heikle Netzwerkprotokolle wie AF_PACKET, zu begrenzen. Beachten Sie, dass in den meisten Fällen die lokale Adressfamilie AF_UNIX in die konfigurierte Freigabeliste aufgenommen werden sollte, da sie häufig für lokale Kommunikation verwandt wird, einschließlich für die syslog(2)-Protokollierung.
RestrictFileSystems=
Falls Sie beide Arten dieser Option (d.h. explizite Freischaltung und Ausschlussliste) festlegen, wird die erste angetroffene Vorrang haben und die Standardaktion festlegen (Erlauben oder Verweigern des Zugriffs auf das Dateisystem). Dann wird das nächste Auftreten dieser Option die Liste der Dateisysteme zu der Menge der beschränkten Dateisysteme hinzufügen oder aus dieser löschen, abhängig von seiner Art und der Standardaktion.
Beispiel: Falls eine Unit die Einstellunng
RestrictFileSystems=ext4 tmpfs RestrictFileSystems=ext2 ext4
Dann wird der Zugriff auf ext4, tmpfs und ext2 erlaubt und Zugriff auf andere Dateisysteme verweigert.
Beispiel: Falls eine Unit die Einstellunng
RestrictFileSystems=ext4 tmpfs RestrictFileSystems=~ext4
Dann wird nur der Zugriff auf tmpfs erlaubt.
Beispiel: Falls eine Unit die Einstellunng
RestrictFileSystems=~ext4 tmpfs RestrictFileSystems=ext4
Dann wird nur der Zugriff auf tmpfs verweigert.
Da die Anzahl der möglichen Dateisysteme groß ist, werden vordefinierte Gruppen von Dateisystemen bereitgestellt. Eine Gruppe beginnt mit dem Zeichen »@«, gefolgt vom Namen der Gruppe.
Tabelle 3. Derzeit vordefinierte
Dateisystemgruppen
Gruppe | Beschreibung |
@basic-api | Grundlegende Dateisystem-API. |
@auxiliary-api | Hilfs-Dateisystem-API. |
@common-block | Gebräuchliche Blockgeräte-Dateisysteme. |
@historical-block | Historische Blockgeräte-Dateisysteme. |
@network | Gut bekannte Netzwerk-Dateisysteme. |
@privileged-api | Privilegierte Dateisystem API. |
@temporary | Temporäre Dateisysteme: tmpfs, ramfs. |
@known | Alle durch den Kernel definierten bekannten Dateisysteme. Diese Liste ist in Systemd statisch basierend auf der Kernelversion, die bei der Veröffentlichung von Systemd verfügbar war, definiert. Sie wird fortschreitend veralten, wenn der Kernel aktualisiert wird. |
Verwenden Sie den Befehl filesystems von systemd-analyze(1), um eine Liste von Dateisystemen abzufragen, die auf dem lokalen System definiert sind.
Beachten Sie, dass diese Einstellung auf einigen Systemen nicht unterstützt werden könnte (beispielsweise weil der LSM-eBFP-Hook in dem zugrundeliegenden Kernel nicht aktiviert wurde oder falls die vereinigte Control-Gruppen-Hierarchie nicht verwandt wird). In diesem Fall hat diese Einstellung keine Auswirkung.
RestrictNamespaces=
Beispiel: Falls eine Unit die Einstellunng
RestrictNamespaces=cgroup ipc RestrictNamespaces=cgroup net
hat, dann werden cgroup, ipc und net gesetzt. Falls der zweiten Zeile »~« vorangestellt wird, d.h.
RestrictNamespaces=cgroup ipc RestrictNamespaces=~cgroup net
dann wird nur ipc gesetzt.
LockPersonality=
MemoryDenyWriteExecute=
RestrictRealtime=
RestrictSUIDSGID=
RemoveIPC=
Diese Option ist nur für Systemdienste verfügbar und wird nicht für Dienste, die in benutzerbezogenene Instanzen des Diensteverwalters laufen, unterstützt.
PrivateMounts=
Falls eingeschaltet, wird dies drei Aktionen für jeden aufgerufenen Prozess auslösen: ein neuer CLONE_NEWNS-Namensraum wird erstellt, danach werden alle existierenden Einhängungen neu als MS_SLAVE eingehängt, um die Ausbreitung aus den Prozessen der Unit zu dem Hauptsystem zu deaktivieren (aber die Ausbreitung in die umgekehrte Richtung bleibt wirksam). Schließlich werden die Einhängungen erneut gemäß des in dem Schalter MountFlags= konfigurierten Ausbreitungsmodus eingehängt, siehe unten.
Dateisystemnamensräume werden individuell für jeden mit »fork« vom Diensteverwalter gestarteten Prozess eingerichtet. Einhängungen, die im Namensraum des durch ExecStartPre= erstellten Prozesses etabliert wurden, werden daher automatisch bereinigt, sobald der Prozess sich beendet und werden für nachfolgend durch ExecStart= mit Fork gestartete Prozesse nicht verfügbar sein (und Ähnliches gilt auch für die verschiedenen anderen für Units konfigurierten Befehle). Ähnlich erlaubt JoinsNamespaceOf= nicht die gemeinsame Benutzung von Kernelnamensräumen zwischen Units, es ermöglicht nur die gemeinsame Benutzung der Verzeichnisse /tmp/ und /var/tmp/.
Andere Dateisystemnamensräume-Einstellungen für Units — PrivateMounts=, PrivateTmp=, PrivateDevices=, ProtectSystem=, ProtectHome=, ReadOnlyPaths=, InaccessiblePaths=, ReadWritePaths=, … — ermöglichen Dateisystemnamensräume in einer Art ähnlich dieser Option. Daher ist es primär zur expliziten Anfrage dieses Verhalten nützlich, falls keine der anderen Einstellungen verwandt wird.
Diese Option ist nur für Systemdienste verfügbar oder für Dienste, die in benutzerbezogenen Instanzen des Diensteverwalters laufen, wenn nicht privilegierte Benutzernamensräume verfügbar sind.
MountFlags=
Diese Einstellung steuert nur die abschließenden Ausbreitungseinstellungen, die für alle Einhängepunkte des Dateisystemnamensraums, der für jeden Prozess dieser Unit erstellt wurde, wirksam sind. Andere Dateisystemnamensraum-Unit-Einstellungen (siehe die Diskussion in PrivateMounts= oben) werden implizit Einhänge- und Aushängeausbreitung von den Prozessen der Unit in Richtung des Systems deaktivieren, indem sie die Ausbreitungseinstellungen aller Einhängepunkte in dem Dateisystemnamensraum der Unit zuerst auf slave setzen. Setzen der Option auf shared richtet die Ausbreitung in diesem Fall nicht wieder ein.
Falls nicht gesetzt – aber es sind durch andere Dateisystemnamensraumeinstellungen der Unit keine Dateisystemnamensräume aktiviert –, wird shared Einhängeausbreitung verwandt, aber wie erwähnt, wird slave zuerst angewandt, Ausbreitung von den Prozessen der Unit zum Hauptsystem bleibt weiterhin abgeschaltet.
Es wird nicht empfohlen, private Einhängeausbreitung für Units zu verwenden, da dies bedeutet, dass temporäre Einhängungen (wie Wechselmedien) auf dem Hauptsystem eingehängt bleiben und daher unbefristet in mit Fork erstellten Programmen als beschäftigt markiert sind, da die Aushängeausbreitungsereignisse in dem Dateisystemnamensraum der Unit nicht empfangen werden.
Normalerweise ist es am besten, diese Einstellung unverändert zu lassen und stattdessen abstraktere Dateisystemnamensraumoptionen zu verwenden, insbesondere PrivateMounts=, siehe oben.
Diese Option ist nur für Systemdienste verfügbar oder für Dienste, die in benutzerbezogenen Instanzen des Diensteverwalters laufen, wenn nicht privilegierte Benutzernamensräume verfügbar sind.
SYSTEMAUFRUFFILTERUNG¶
SystemCallFilter=
Beachten Sie, dass auf Systemen, die mehrere ABIs unterstützen (wie X86/X86-64), empfohlen wird, alternative ABIs für Dienste zu deaktivieren, so dass sie nicht zur Umgehung der Einschränkungen dieser Option verwandt werden können. Insbesondere wird empfohlen, diese Option mit SystemCallArchitectures=native oder Ähnlichem zu kombinieren.
Beachten Sie, dass strenge Systemaufruffilterung die Ausführungs- und Fehlerbehandlungs-Code-Pfade des Diensteaufrufs beeinflussen können. Insbesondere wird der Zugriff auf den Systemaufruf execve() für die Ausführung des Dienstprogrammes benutzt — falls er blockiert ist, wird der Diensteaufruf notwendigerweise fehlschlagen. Falls auch die Ausführung des Dienstprogramms aus irgendwelchen Gründen fehlschlägt (beispielsweise fehlendes Dienstprogramm), könnte die Fehlerbehandlungslogik Zugriff auf eine zusätzliche Gruppe an Systemaufrufen benötigen, um diesen Fehlschlag korrekt zu verarbeiten und zu protokollieren. Es könnte notwendig sein, temporär die Systemaufruffilter zu deaktivieren, um die Fehlersuche bei solchen Fehlschlägen zu vereinfachen.
Falls Sie beide Arten dieser Option (d.h. explizite Freischaltung und Ausschlussliste) festlegen, wird die erste angetroffene Vorrang haben und die Standardaktion festlegen (Beendigung oder Bestätigung eines Systemaufrufs). Dann wird das nächste Auftreten dieser Option die Liste der Systemaufrufe zu der Menge der gefilterten Systemaufrufe hinzufügen oder aus dieser löschen, abhängig von seiner Art und der Standardaktion. (Falls Sie beispielsweise mit einer expliziten Freischaltung von read() und write() beginnen und direkt danach eine Ausschlussliste mit write() hinzufügen, dann wird write() aus der Menge entfernt.)
Da die Anzahl der möglichen Systemaufrufe groß ist, werden vordefinierte Gruppen von Systemaufrufen bereitgestellt. Eine Gruppe beginnt mit dem Zeichen »@«, gefolgt vom Namen der Gruppe.
Tabelle 4. Derzeit vordefinierte
Systemaufrufgruppen
Gruppe | Beschreibung |
@aio | Asynchrone E/A (io_setup(2), io_submit(2) und verwandte Aufrufe) |
@basic-io | Systemaufrufe für grundlegende E/A: Lesen, Schreiben, Suchen, Duplizieren und Schließen von Dateideskriptoren (read(2), write(2) und verwandte Aufrufe) |
@chown | Änderung der Dateieigentümerschaft (chown(2), fchownat(2) und verwandte Aufrufe) |
@clock | Systemaufrufe zur Änderung der Systemuhr (adjtimex(2), settimeofday(2) und verwandte Aufrufe) |
@cpu-emulation | Systemaufrufe für CPU-Emulierungsfunktionen (vm86(2) und verwandte Aufrufe) |
@debug | Fehlersuche, Leistungsüberwachung und Nachverfolgungsfunktionen (ptrace(2), perf_event_open(2) und verwandte Aufrufe) |
@file-system | Dateisystemaktionen: Öffnen, Dateien und Verzeichnisse zum Lesen und Schreiben erstellen, sie umbenennen oder entfernen, Lesen von Dateieigenschaften oder Erstellen von harten und symbolischen Links |
@io-event | Systemaufrufe für Ereignisschleifen (poll(2), select(2), epoll(7), eventfd(2) und verwandte Aufrufe) |
@ipc | Pipes, SysV IPC, POSIX-Nachrichtenwarteschlangen und andere IPC (mq_overview(7), svipc(7)) |
@keyring | Kernel-Schlüsselbundzugriff (keyctl(2) und verwandte Aufrufe) |
@memlock | Sperren von Speicher im RAM (mlock(2), mlockall(2) und verwandte Aufrufe) |
@module | Laden und Entladen von Kernelmodulen (init_module(2), delete_module(2) und verwandte Aufrufe) |
@mount | Einhängen und Aushängen von Dateisystemen (mount(2), chroot(2) und verwandte Aufrufe) |
@network-io | Socket-E/A (einschließlich lokalem AF_UNIX): socket(7), unix(7) |
@obsolete | Ungewöhnliches, Veraltetes oder nicht Implementiertes (create_module(2), gtty(2), …) |
@privileged | Alle Systemaufrufe, die Administrator-Capabilities benötigen (capabilities(7)) |
@process | Prozesssteuerung, -ausführung, Namensraumaktionen (clone(2), kill(2), namespaces(7), …) |
@raw-io | Rohzugriff auf E/A-Ports (ioperm(2), iopl(2), pciconfig_read(), …) |
@reboot | Systemaufrufe für den Neustart und die Neustartvorbereitung (reboot(2), kexec(), …) |
@resources | Systemaufrufe für die Änderung von Ressourcenbeschränkungen, Speicher- und Schedulingparametern (setrlimit(2), setpriority(2), …) |
@setuid | Systemaufrufe zur Änderung der Benutzerkennung und Gruppenberechtigungen (setuid(2), setgid(2), setresuid(2), …) |
@signal | Systemaufrufe für die Veränderung und Handhabung von Prozesssignalen (signal(2), sigprocmask(2), …) |
@swap | Systemaufrufe für die Aktivierung/Deaktivierung von Auslagerungsgeräten (swapon(2), swapoff(2)) |
@sync | Synchronisierung von Dateien und Speicher auf Platte (fsync(2), msync(2) und verwandte Aufrufe) |
@system-service | Eine vernünftige Gruppe von Systemaufrufen, die von typischen Systemdiensten benutzt werden, ausschließlich aller Systemaufrufe für besondere Zwecke. Dies ist der empfohlene Anfangspunkt zum expliziten Erlauben von Systemaufrufen für Systemdienste, da es das enthält, was typischerweise von Systemdiensten benötigt wird, aber äußerst spezielle Schnittstellen ausschließt. Beispielsweise sind die folgenden APIs ausgeschlossen: »@clock«, »@mount«, »@swap«, »@reboot«. |
@timer | Systemaufrufe für Scheduling-Aktionen von Time (alarm(2), timer_create(2), …) |
@known | Alle durch den Kernel definierten Systemaufrufe. Diese Liste ist in Systemd statisch basierend auf der Kernelversion, die bei der Veröffentlichung von Systemd verfügbar war, definiert. Sie wird fortschreitend veralten, wenn der Kernel aktualisiert wird. |
Beachten Sie, dass neue Systemaufrufe zu den obigen Gruppen hinzugefügt werden könnten, wenn neue Systemaufrufe zu dem Kernel hinzugefügt werden. Die Inhalte dieser Gruppen können sich auch zwischen Systemd-Versionen unterscheiden. Zusätzlich hängt die Liste der Systemaufrufe auch von der Kernelversion und der Architektur, für die Systemd kompiliert wurde, ab. Verwenden Sie systemd-analyze syscall-filter, um die tatsächliche Liste der Systemaufrufe in jedem Filter aufzuführen.
Im Allgemeinen ist das explizite Erlauben von Systemaufrufen (statt einer Ausschlussliste) der sicherere Betriebsmodus. Es wird empfohlen, für alle langlaufenden Systemdienste eine Liste explizit erlaubter Systemaufrufe zu erzwingen. Insbesondere sind die nachfolgenden Zeilen eine relativ sicherere grundlegende Wahl für den Großteil der Systemdienste:
[Service] SystemCallFilter=@system-service SystemCallErrorNumber=EPERM
Beachten Sie, dass die verschiedenen Systemaufrufe redundant definiert werden: es gibt mehrere Systemaufrufe zur Ausführung der gleichen Aktion. Beispielsweise kann der Systemaufruf pidfd_send_signal() zur Ausführung von Aktionen ähnlich zu dem älteren Systemaufruf kill() verwandt werden, daher führt das Blockieren von letzterem ohne das Blockieren des ersteren nur zu einem schwachen Schutz. Da neue Systemaufrufe regelmäßig dem Kernel hinzugefügt werden, verlangt das Pflegen von vollständigen Ausschlusslisten für Systemaufrufe ständige Arbeit. Es wird daher empfohlen, stattdessen Freischaltungen einzusetzen, wodurch der Nutzen entsteht, dass neue Systemaufrufe standardmäßig implizit blockiert sind, bis die Freischaltung aktualisiert wurde.
Beachten Sie auch, dass eine Reihe von Systemaufrufen zugreifbar sein müssen, damit der dynamische Linker funktioniert. Der dynamische Linker wird zur Ausführung der meisten regulären Programme benötigt (konkret dynamische ELF-Programme - auf diese Art bauen die meisten Distributionen paketierte Programme). Dies bedeutet, dass das Blockieren dieser Systemaufrufe (wozu open(), openat() und mmap() gehören) dazu führen wird, das die meisten mit generischen Distributionen ausgelieferten Programme unbenutzbar werden.
Es wird empfohlen, die auf den Namensraum des Dateisystems bezogenen Optionen mit SystemCallFilter=~@mount zu kombinieren, um zu verhindern, dass die Prozesse der Unit die Abbildungen rückgängig machen. Insbesondere sind dies die Optionen PrivateTmp=, PrivateDevices=, ProtectSystem=, ProtectHome=, ProtectKernelTunables=, ProtectControlGroups=, ProtectKernelLogs=, ProtectClock=, ReadOnlyPaths=, InaccessiblePaths= und ReadWritePaths=.
SystemCallErrorNumber=
SystemCallArchitectures=
Falls diese Einstellung verwandt wird, wird den Prozessen dieser Unit nur der Aufruf nativer Systemaufrufe und von Systemaufrufen der festgelegten Architektur erlaubt. Für die Zwecke dieser Option wird die Architektur X32 so behandelt, dass sie die Systemaufrufe von X86-64 enthält. Allerdings erfüllt diese Einstellung auf X32 weiterhin ihren Zweck, wie unten dargestellt.
Systemaufruffilterung ist nicht auf allen Architekturen wirksam. Beispielsweise ist auf X86 aufgrund von ABI-Einschränkungen das Filtern von Netz-Socket-bezogenen Aufrufen nicht möglich, eine Einschränkung, die X86-64 allerdings nicht hat. Auf Systemen, die mehrere ABI gleichzeitig unterstützen, wie X86/X86-64, wird daher empfohlen, die Gruppe der erlaubten Systemaufrufarchitekturen einzuschränken, so dass das sekundäre ABI nicht dazu verwandt werden kann, die dem nativen ABI des Systems auferlegten Einschränkungen zu umgehen. Insbesondere ist das Setzen von SystemCallArchitectures=native für das Deaktivieren nichtnativer ABIs eine gute Wahl.
Systemaufrufarchitekturen können auch systemweit mittels der Option SystemCallArchitectures= in der globalen Konfiguration eingeschränkt werden. Siehe systemd-system.conf(5) für Details.
SystemCallLog=
UMGEBUNGSVARIABLEN¶
Environment=
Diese Option kann mehr als einmal angegeben werden, dann werden alle aufgeführten Variablen gesetzt. Falls die gleiche Option zweimal aufgeführt wird, setzt die spätere Einstellung die frühere Einstellung außer Kraft. Falls dieser Option die leere Zeichenkette zugewiesen wird, wird die Liste der Umgebungsvariablen zurückgesetzt und alle vorherigen Zuweisungen haben keinen Effekt.
Die Namen der Variablen dürfen ASCII-Buchstaben, Ziffern und der Unterstrich enthalten sein. Variablennamen dürfen nicht leer sein oder mit einer Ziffer beginnen. In den Variablenwerten sind die meisten Zeichen erlaubt, aber nicht darstellbare Zeichen werden derzeit zurückgewiesen.
Beispiel:
Environment="VAR1=Wort1 Wort2" VAR2=Wort3 "VAR3=$Wort 5 6"
ergibt drei Variablen »VAR1«, »VAR2«, »VAR3« mit den Werten »Wort1 Wort2«, »Wort3«, »$Wort 5 6«.
Siehe environ(7) für Details über Umgebungsvariablen.
Beachten Sie, dass Umgebungsvariablen nicht dazu geeignet sind, Geheimnisse (wie Passwörter, Schlüsselmaterial, …) an Diensteprozesse weiterzugeben. Für eine Unit gesetzte Umgebungsvariablen können von nicht privilegierten Clients wie D-Bus-IPC eingesehen werden und werden im Allgemeinen nicht als Daten betrachtet, die geschützt werden müssen. Desweiteren werden Umgebungsvariablen den Prozessbaum heruntergereicht, auch über Sicherheitsgrenzen (wie Setuid/Setgid-Programme) hinweg und könnten daher zu Prozessen durchsickern, die keinen Zugriff auf die geheimen Daten haben sollen. Verwenden Sie LoadCredential=, LoadCredentialEncrypted= oder SetCredentialEncrypted= (siehe unten), um Daten sicher an Unit-Prozesse zu übergeben.
EnvironmentFile=
In der Datei wird ein Wert nach dem »=« außerhalb von Anführungszeichen mit den gleichen Rückwärts-Schrägstrich-Regeln wie Text ohne Anführungszeichen[10] in einer POSIX-Shell ausgewertet. Allerdings wird anders als in einer Shell innenliegender Leerraum beibehalten und Anführungszeichen nach dem erste Zeichen, das kein Leerraum ist, werden erhalten. Führende und abschließende Leerraumzeichen (Leerzeichen, Tabulatoren, Zeilenumbrüche) werden verworfen, aber innere Leeraumzeichen innerhalb der Zeile bleiben unverändert erhalten. Eine Zeile, die mit einem Rückwärtsschrägstrich endet, wird auf der nachfolgenden weitergeführt, wobei der Zeilenumbruch selbst verworfen wird. Ein Rückwärtsschrägstrich »\« gefolgt von einem Zeichen außer dem Zeilenumbruch selbst wird das nachfolgende Zeichen erhalten, so dass aus »\\« der Wert »\« wird.
In der Datei kann ein mit »'« maskierter Wert nach dem »=« über mehrere Zeilen gehen und jedes Zeichen außer dem Anführungszeichen selbst direkt enthalten, wie Text in einfachen Anführungszeichen[11] in einer POSIX-Shell. Es werden keine Rückwärtsschrägstrich-Maskiersequenzen erkannt. Führende und abschließende Leerraumzeichen außerhlab der einfachen Anführungszeichen werden verworfen.
In der Datei kann ein mit »"« maskierter Wert nach dem »=« über mehrere Zeilen gehen und die gleichen Maskiersequenzen wie in Text in doppelten englischen Anführungszeichen[12] einer POSIX-Shell werden erkannt. Rückwärtsschrägstrich (»\«) gefolgt von einem aus »"\`$« wird das Zeichen erhalten. Ein Rückwärtsschrägstrich, dem ein Zeilenumbruch folgt, ist eine Zeilenfortsetzung, und das Zeilenumbruchzeichen selbst wird verworfen. Andere Zeichen, die dem Rückwärtsschrägstrich folgen, werden ignoriert; sowohl der Rückwärtsschrägstrich als auch das nachfolgende Zeichen werden so erhalten. Führende und abschließende Leerraumzeichen außerhalb der doppelten Anführungszeichen werden verworfen.
Das übergebene Argument sollte ein absoluter Dateiname oder ein Platzhalterausdruck sein, dem optional »-« vorangestellt werden kann, um anzuzeigen, dass sie nicht gelesen werden soll und keine Fehler- oder Warnmeldung protokolliert wird, falls sie nicht existiert. Diese Option kann mehr als einmal angegeben werden, in diesem Fall werden alle festgelegten Dateien gelesen. Falls der Option die leere Zeichenkette zugewiesen wird, wird die Liste der zu lesenden Dateien zurückgesetzt und alle vorherigen Zuweisungen haben keine Wirkung.
Die mit dieser Anweisung aufgeführten Dateien werden kurz vor der Ausführung des Prozesses gelesen (genauer gesagt, nachdem alle Prozesse eines vorherigen Unit-Zustandes beendet wurden. Dies bedeutet, dass Sie diese Dateien in einem Unit-Zustand erstellen und sie mit dieser Option in dem nächsten lesen können. Diese Dateien werden aus dem Dateisystem des Diensteverwalters gelesen, bevor Änderungen im Dateisystem wie Bind-Einhängungen stattfinden).
Einstellungen von diesen Dateien setzen mit Environment= vorgenommene Einstellungen außer Kraft. Falls die gleiche Variable zweimal von diesen Dateien gesetzt wird, werden die Dateien in der festgelegten Reihenfolge eingelesen und spätere Einstellungen werden die früheren Einstellungen außer Kraft setzen.
PassEnvironment=
Variablen, die aufgrund dieser Einstellung für aufgerufene Prozesse gesetzt werden, könnten durch solche, die mit Environment= oder EnvironmentFile= konfiguriert wurden, außer Kraft gesetzt zu werden.
Beispiel:
PassEnvironment=VAR1 VAR2 VAR3
übergibt die drei Variablen »VAR1«, »VAR2«, »VAR3« mit den für diese Variablen in PID1 gesetzten Werten.
Siehe environ(7) für Details über Umgebungsvariablen.
UnsetEnvironment=
Siehe nachfolgenden Abschnitt »Umgebungsvariablen in erzeugten Prozessen« für eine Beschreibung, wie diese Einstellungen kombiniert werden, um eine vererbte Umgebung zu bilden. Siehe environ(7) für allgemeine Informationen über Umgebungsvariablen.
PROTOKOLLIERUNG UND STANDARD-EIN-/-AUSGABE¶
StandardInput=
Falls null ausgewählt wird, wird die Standardeingabe mit /dev/null verbunden, d.h. alle Leseversuche durch den Prozess werden sofort zu einem EOF führen.
Falls tty ausgewählt ist, wird die Standardeingabe mit einem TTY (wie mit TTYPath= konfiguriert, siehe unten) verbunden und der ausgeführte Prozess wird der steuernde Prozess des Terminals. Falls das Terminal bereits durch einen anderen Prozess gesteuert wird, wartet der ausgeführte Prozess, bis der derzeit steuernde Prozess das Terminal freigibt.
tty-force ist ähnlich zu tty, der ausgeführte Prozess wird aber zwangsweise und sofort zum steuernden Prozess des Terminals gemacht, möglicherweise werden dabei vorhergehende steuernde Prozesse von dem Terminal entfernt.
tty-fail ist ähnlich zu tty, falls aber das Terminal bereits einen steuernden Prozess hat, schlägt das Hochfahren des ausgeführten Prozesses fehl.
Die Option data kann zur Konfiguration beliebiger textueller oder binärer Daten, die mittels Standardeingabe an den ausgeführten Prozess übergeben werden sollen, verwandt werden. Die zu übergebenden Daten werden mittels StandardInputText=/StandardInputData= (siehe unten) konfiguriert. Beachten Sie, dass der tatsächlich übergebene Dateideskriptortyp (Speicherdatei, reguläre Datei, UNIX-Pipe, …) vom Kernel und den verfügbaren Privilegien abhängen könnte. Auf jeden Fall ist der Dateideskriptor nur lesbar und er liefert die festgelegten Daten, gefolgt von EOF, zurück, wenn er gelesen wird.
Die Option file:Pfad kann zur Verbindung der Standardeingabe mit einem bestimmten Dateisystemobjekt verwandt werden. Es wird ein absoluter Pfad gefolgt von dem Zeichen »:« erwartet, der sich auf eine reguläre Datei, ein FIFO oder eine Spezialdatei beziehen kann. Falls ein AF_UNIX-Socket in dem Dateisystem festgelegt ist, wird mit ihm ein Datenstrom-Socket verbunden. Letzteres ist nützlich, um die Standardeingabe eines beliebigen Prozesses mit einem beliebigen Systemdienst zu verbinden.
Die Option »socket« ist nur in Socket-aktivierten Diensten gültig und es muss in der relevanten Socket-Unit-Datei (siehe systemd.socket(5) für Details) Accept=yes gesetzt oder nur ein einzelnes Socket spezifiziert sein. Falls diese Option gesetzt ist, wird die Standardeingabe mit dem Socket, aus dem der Dienst aktiviert wurde, verbunden. Dies ist hauptsächlich für die Kompatibilität mit Daemons nützlich, die für die Verwendung mit der traditionellen inetd(8)-Socket-Daemon-Aktivierung entwickelt wurden.
Die Option fd:Name verbindet die Standardeingabe mit einem durch die Socket-Unit bereitgestellten bestimmten, benannten Dateideskriptor. Der Name kann als Teil dieser Option angegeben werden, gefolgt vom Zeichen »:« (z.B. »fd:foobar«). Falls kein Name angegeben ist, wird der Name »stdin« impliziert (d.h. »fd« ist äquivalent zu »fd:stdin«). Mindestens eine Socket-Unit, die den angegebenen Namen definiert, muss über die Option Sockets= bereitgestellt werden und der Dateideskriptorname darf sich vom Namen der Socket-Unit, die ihn enthält, unterscheiden. Falls mehrere Treffer gefunden werden, wird der erste verwandt. Siehe FileDescriptorName= in systemd.socket(5) für weitere Details über benannte Dateideskriptoren und ihrer Sortierung.
Diese Einstellung ist standardmäßig null, außer StandardInputText=/StandardInputData= sind gesetzt, dann ist die Vorgabe data.
StandardOutput=
inherit dupliziert den Dateideskriptor der Standardeingabe für die Standardausgabe.
null verbindet die Standardausgabe mit /dev/null, d.h. alles dahin Geschriebene geht verloren.
tty verbindet die Standardausgabe mit einem TTY (wie in TTYPath= konfiguriert, siehe unten). Falls das TTY nur für die Ausgabe verwandt wird, wird der ausgeführte Prozess nicht der steuernde Prozess des Terminals werden und wird nicht fehlschlagen oder darauf warten, dass andere Prozesse das Terminal freigeben.
journal verbindet die Standardausgabe mit dem Journal, das über journalctl(1) erreichbar ist. Beachten Sie, dass alles, was nach Syslog oder Kmsg (siehe unten) geschrieben wird, implizit auch im Journal gespeichert wird, die spezielle unten aufgeführten Optionen ist daher eine Obermenge dieser Option. (Beachten Sie auch, dass alle externen, zusätzlichen Syslog-Daemons ihre Protokolldaten auch aus dem Journal empfangen, daher ist dies die Option, die verwandt werden sollte, wenn das Protokoll mit solch einem Daemon verarbeitet werden soll.)
kmsg verbindet die Standardeingabe mit dem Kernelprotokollpuffer, der über dmesg(1) erreichbar ist, zusätzlich zum Journal. Der Journal-Daemon könnte so konfiguriert sein, dass er alles, was er empfängt, sowieso zu Kmsg sendet, wodurch diese Option in diesem Fall keinen Unterschied zu journal darstellt.
journal+console und kmsg+console arbeiten auf eine ähnliche Art wie die zwei Optionen oben, kopieren aber auch sämtliche Ausgabe auf die Systemkonsole.
Die Option file:Pfad kann zum Verbinden eines bestimmten Dateisystemobjektes mit der Standardausgabe verwandt werden. Die Semantik ist ähnlich zu der der gleichen Option von StandardInput=, siehe oben. Falls sich Pfad auf eine reguläre Datei auf dem Dateisystem bezieht, wird sie zum Schreiben am Anfang der Datei geöffnet (erstellt, falls sie noch nicht existiert), aber ohne sie abzuschneiden. Falls die Standardeingabe und -ausgabe auf den gleichen Dateipfad verwiesen werden, wird dieser nur einmal – zum Lesen und Schreiben – geöffnet und dupliziert. Dies ist insbesondere nützlich, wenn sich der festgelegte Pfad auf ein AF_UNIX-Socket im Dateisystem bezieht, da in diesem Fall nur eine einzelne Datenstromverbindung für sowohl Ein- als auch Ausgabe erstellt wird.
append:Pfad ist ähnlich zu file:Pfad oben, es öffnet die Datei aber im Anhängemodus.
truncate:Pfad ist ähnlich zu obigem file:Pfad, schneidet die Datei beim Öffnen aber ab. Für Units mit mehreren Befehlszeilen, z.B. Type=oneshot-Dienste mit mehreren ExecStart= oder Diensten mit ExecCondition=, ExecStartPre= oder ExecStartPost=, wird die Ausgabedatei erneut für jede Befehlszeile geöffnet und daher erneut abgeschnitten. Falls die Ausgabedatei abgeschnitten wird, während ein anderer Prozess die Datei noch geöffnet hat, z.B. durch ein ExecReload=, das parallel zu einem ExecStart= ausgeführt wird, und dieser Prozess weiter in die Datei schreibt, ohne seinen Versatz anzupassen, dann kann der Leerraum zwischen den Dateizeigern der zwei Prozesse mit NUL-Bytes aufgefüllt werden, wodurch eine Sparse-Datei erzeugt wird. Daher ist truncate:Pfad normalerweise nur mit einer einzelnen ExecStart= und keinem ExecStartPost=, ExecReload=, ExecStop= oder ähnlichem nützlich.
socket verbindet die Standardausgabe zu einem mittels Socket-Aktivierung erlangten Socket. Die Semantik ist ähnlich zu der der gleichen Option von StandardInput=, siehe oben.
Die Option fd:Name verbindet die Standardausgabe mit einem bestimmten benannten, durch eine Socket-Unit bereitgestellten Dateideskriptor. Es kann als Teil dieser Option ein Name, gefolgt von einem »:«-Zeichen, angegeben werden (z.B. »fd:foobar«). Falls kein Name angegeben ist, wird der Name »stdout« impliziert (d.h. »fd« ist äquivalent zu »fd:stdout«). Mindestens eine Socket-Unit, die den angegebenen Namen definiert, muss über die Option Sockets= bereitgestellt werden und der Dateideskriptorname darf sich vom Namen der Socket-Unit, die ihn enthält, unterscheiden. Falls mehrere Treffer gefunden werden, wird der erste verwandt. Siehe FileDescriptorName= in systemd.socket(5) für weitere Details über benannte Dateideskriptoren und ihrer Sortierung.
Falls die Standardausgabe (oder die Fehlerausgabe, siehe unten) einer Unit mit dem Journal oder dem Kernelprotokollpuffer verbunden ist, wird die Unit implizit eine Abhängigkeit vom Typ After= von systemd-journald.socket erhalten (siehe auch den Abschnitt »Implizite Abhängigkeiten« oben). Beachten Sie auch, dass in diesem Fall Stdout (oder Stderr, siehe unten) ein AF_UNIX-Datenstrom-Socket und keine PIPE oder FIFO, die erneut geöffnet werden kann, sein wird. Das bedeutet, dass bei der Ausführung von Shell-Skripten die Konstruktion »echo "hello" > /dev/stderr« zum Schreiben von Text nach Stderr nicht funktionieren wird. Um dies zu entschärfen, verwenden Sie stattdessen die Konstruktion »echo "hello" >&2«, die größtenteils äquivalent ist und diesen Fallstrick vermeidet.
Der Vorgabewert dieser Einstellung ist der mit DefaultStandardOutput= in systemd-system.conf(5) gesetzte Wert, der standardmäßig journal ist. Beachten Sie, dass dieser Parameter zum Hinzufügen zusätzlicher Abhängigkeiten führen kann (siehe oben).
StandardError=
Der Vorgabewert dieser Einstellung ist der mit DefaultStandardError= in systemd-system.conf(5) gesetzte Wert, der standardmäßig inherit ist. Beachten Sie, dass dieser Parameter zum Hinzufügen zusätzlicher Abhängigkeiten führen kann (siehe oben).
StandardInputText=, StandardInputData=
StandardInputText= akzeptiert beliebige textuelle Daten. C-artige Maskierungen für besondere Zeichen sowie die normalen »%«-Kennzeichner werden aufgelöst. Jedes Mal, wenn diese Einstellung benutzt wird, wird der festgelegte Text an den Unit-bezogenen Datenpuffer, gefolgt von einem Zeilenumbruchzeichen, angehängt (daher hängt jeder Einsatz eine neue Zeile an das Ende des Puffers an). Beachten Sie, dass einleitende und abschließende Leerraumzeichen von mit dieser Option konfigurierten Zeilen entfernt werden. Falls eine leere Zeile festgelegt wird, wird der Puffer bereinigt (daher sollte ein zusätzliches »\n« an das Ende oder den Anfang einer Zeile eingefügt werden, um eine leere Zeile einzufügen).
StandardInputData= akzeptiert beliebige, in Base64[13] kodierte binäre Daten. Es werden keine Maskiersequenzen oder Kennzeichner aufgelöst. Sämtliche Leerraumzeichen in der kodierten Version werden während der Dekodierung ignoriert.
Beachten Sie, dass StandardInputText= und StandardInputData= auf dem gleichen Datenpuffer arbeiten und gemischt werden können, um sowohl binäre als auch textuelle Daten für den gleichen Eingabedatenstrom zu konfigurieren. Die textuellen oder binären Daten werden genau in der Reihenfolge zusammengefügt, in der sie in der Unit-Datei auftauchen. Wird einem eine leere Zeichenkette zugewiesen, wird der Datenpuffer zurückgesetzt.
Bitte beachten Sie, dass lange Unit-Dateieinstellungen in mehrere Zeilen aufgeteilt werden können, um die Lesbarkeit zu erhalten. Hierzu wird jeder Zeile (außer der letzten) ein Zeichen »\« vorangestellt (siehe systemd.unit(5) für Details). Dies ist insbesondere für große Daten, die mit diesen Optionen konfiguriert werden, nützlich. Beispiel:
… StandardInput=data StandardInputData=V2XigLJyZSBubyBzdHJhbmdlcnMgdG8gbG92ZQpZb3Uga25vdyB0aGUgcnVsZXMgYW5kIHNvIGRv \
IEkKQSBmdWxsIGNvbW1pdG1lbnQncyB3aGF0IEnigLJtIHRoaW5raW5nIG9mCllvdSB3b3VsZG4n \
dCBnZXQgdGhpcyBmcm9tIGFueSBvdGhlciBndXkKSSBqdXN0IHdhbm5hIHRlbGwgeW91IGhvdyBJ \
J20gZmVlbGluZwpHb3R0YSBtYWtlIHlvdSB1bmRlcnN0YW5kCgpOZXZlciBnb25uYSBnaXZlIHlv \
dSB1cApOZXZlciBnb25uYSBsZXQgeW91IGRvd24KTmV2ZXIgZ29ubmEgcnVuIGFyb3VuZCBhbmQg \
ZGVzZXJ0IHlvdQpOZXZlciBnb25uYSBtYWtlIHlvdSBjcnkKTmV2ZXIgZ29ubmEgc2F5IGdvb2Ri \
eWUKTmV2ZXIgZ29ubmEgdGVsbCBhIGxpZSBhbmQgaHVydCB5b3UK …
LogLevelMax=
LogExtraFields=
LogRateLimitIntervalSec=, LogRateLimitBurst=
LogNamespace=
Intern sind Journal-Namensräume mittes Linux-Einhängenamensräume und durch Übereinhängen des Verzeichnisses, das die relevanten AF_UNIX-Sockets für das Protokollieren in dem Einhängenamensraum enthält, implementiert. Da Einhängenamensräume verwandt werden, trennt diese Einstellung die Weiterleitung von Einhängungen von den Prozessen der Unit zu dem Rechner ab, ähnlich wie ReadOnlyPaths= und ähnliche Einstellungen (siehe oben) funktionieren. Journal-Namensräume können daher nicht für Dienste verwandt werden, die Einhängepunkte auf dem Rechner etablieren müssen.
Wenn diese Option gesetzt ist, wird die Unit automatisch Ordnungs- und Anforderungsabhängigkeiten von den zwei der systemd-journald@.service-Instanz zugeordneten Socket-Units erlangen, so dass diese vor dem Starten der Unit automatisch etabliert werden. Beachten Sie, dass bei Verwendung dieser Option die Protokollierausgabe dieses Dienstes nicht in der regulären journalctl(1)-Ausgabe erscheint, außer die Option --namespace= wird verwandt.
Diese Option ist nur für Systemdienste verfügbar und wird nicht für Dienste, die in benutzerbezogenene Instanzen des Diensteverwalters laufen, unterstützt.
SyslogIdentifier=
SyslogFacility=
SyslogLevel=
SyslogLevelPrefix=
TTYPath=
TTYReset=
TTYVHangup=
TTYRows=, TTYColumns=
TTYVTDisallocate=
ZUGANGSDATEN¶
LoadCredential=KENNUNG[:PFAD], LoadCredentialEncrypted=KENNUNG[:PFAD]
Die Einstellung LoadCredential= akzeptiert eine textuelle Kennung als Namen für ein Zugangsberechtigungsdatum sowie einen Dateisystempfad, getrennt durch einen Doppelpunkt. Die Kennung muss eine kurze ASCII-Zeichenkette sein, die als Dateiname in dem Dateisystem geeignet ist, und kann vom Benutzer frei gewählt werden. Falls der angegebene Pfad absolut ist, wird er als reguläre Datei geöffnet und das Zugangsberechtigungsdatum wird daraus gelesen. Falls sich der absolute Pfad auf ein AF_UNIX-Datenstrom-Socket im Dateisystem bezieht, dann wird zu ihm eine Verbindung aufgebaut (nur einmalig während des Startens) und das Zugangsberechtigungsdatum aus dieser Verbindung ausgelesen, wodurch ein einfacher IPC-Integrationspunkt bereitgestellt wird, um Zugangsberechtigungsdaten dynamisch von anderen Diensten zu übertragen.
Falls der angegeben Pfad nicht absolut ist und selbst wieder als gültiger Zugangsberechtigungsdatumkennzeichner geeignet ist, wird versucht, ein Zugangsberechtigungsdatum zu finden, das der Diensteverwalter selbst unter dem festgelegten Namen empfangen hat – was zur Weiterleitung von Zugangsberechtigungsdaten von einer aufrufenden Umgebung (z.B. einem Container-Verwalter, der den Diensteverwalter aufgerufen hat) an einen Dienst verwandt werden kann. Falls keine passenden Systemzugangsdaten gefunden wurden, werden die Verzeichnisse /etc/credstore/, /run/credstore/ und /usr/lib/credstore/ nach Dateien unter dem Namen der Zugangsberechtigung durchsucht – dies sind daher die bevorzugten Orte für Zugangsberechtigungsdaten auf der Platte. Falls LoadCredentialEncrypted= verwandt wird, dann werden auch /run/credstore.encrypted/, /etc/credstore.encrypted/ und /usr/lib/credstore.encrypted/ durchsucht.
Falls der Dateisystempfad nicht angegeben wird, wird er als identisch zum Zugangsberechtigungsnamen angenommen, d.h. dies ist eine bündige Art und Weise, um zu erklären, dass Zugangsberechtigungsdaten vom Diensteverwalter in einen Dienst vererbt werden. Diese Option kann mehrfach verwandt werden, wobei jedes Mal ein zusätzliches Zugangsberechtigungsdatum definiert wird, das an die Unit übergeben wird.
Falls ein absoluter Pfad festgelegt wird, der sich auf ein Verzeichnis bezieht, dann wird jede Datei in diesem Verzeichnis (rekursiv) als eine seperate Zugangsberechtigung geladen. Die Kennung für jede Zugangsberechtigung wird die bereitgestellte Kennung sein, der »_$FILENAME« angehängt wird (z.B. »Key_file1«). Beim Laden aus einem Verzeichnis werden Symlinks ignoriert.
Der Inhalt der Datei/des Sockets können beliebige binäre oder textuelle Daten sein, einschließlich Zeilenumbruchzeichen und NUL-Bytes.
Die Einstellung LoadCredentialEncrypted= ist identisch zu LoadCredential=, außer das die Zugangsberechtigungsdaten vor der Weitergabe an den ausgeführten Prozess entschlüsselt und authentifiziert werden. Insbesondere sollte sich der referenzierte Pfad auf eine Datei oder ein Socket mit einer verschlüsselten Zugangsberechtigung beziehen, wie das von systemd-creds(1) implementiert wird. Diese Zugangsberechtigung wird geladen, entschlüsselt, authentifiziert und dann an die Anwendung in Klartextform weitergegeben, wie das auch bei einer mittels LoadCredential= festgelegten regulären Zugangsberechtigung gemacht würde. Eine auf diese Weise konfigurierte Zugangsberechtigung kann symmetrisch mit einem geheimen Schlüssel verschlüsselt/authentifiziert sein, der vom TPM2-Sicherheits-Chip des Systems abgeleitet wurde oder mit einem geheimen Schlüssel, der in /var/lib/systemd/credentials.secret gespeichert wird, oder mit beidem. Die Verwendung von verschlüsselten und authentifizierten Zugangsberechtigungen erhöht die Sicherheit, da Zugangsberechtigungen nicht im Klartext gespeichert werden und nur zu dem Zeitpunkt authentifiziert und in Klartext entschlüsselt werden, zu dem der Dienst, der sie benötigt, gestartet wird. Desweiteren könnten die Zugangsberechtigungen an die lokale Hardware und Installation gebunden werden, so dass sie nicht so leicht vom System getrennt analysiert oder extern erstellt werden können.
Der Diensteverwalter muss auf die Zugangsberechtigungs-Dateien/-Sockets zugreifen können, aber die Prozesse müsse nicht direkt darauf zugreifen können: die Zugangsberechtigungsdaten werden gelesen und getrennte, nur lesbare Kopien für die Unit werden angelegt, die von den geeignet privilegierten Prozessen gelesen werden können. Dies ist insbesondere in Kombination mit DynamicUser= nützlich, da auf diese Art privilegierte Daten für Prozesse zur Verfügung gestellt werden können, die unter einer dynamischen UID laufen (d.h. einer bisher nicht bekannten), ohne den Zugriff für alle Benutzer zu eröffnen.
Um innerhalb einer ExecStart=-Befehlszeile den Pfad zu referenzieren, unter dem eine Zugangsberechtigung gelesen werden kann, verwenden Sie »${CREDENTIALS_DIRECTORY}/mycred«, z.B. »ExecStart=cat ${CREDENTIALS_DIRECTORY}/mycred«. Um innerhalb einer Environment=-Zeile den Pfad zu referenzieren, unter dem eine Zugangsberechtigung gelesen werden kann, verwenden Sie »%d/mycred«, z.B. »Environment=MYCREDPATH=%d/mycred«.
Derzeit wird eine Größenbegrenzung für aufsummierte Zugangsberechtigungen von 1 MB pro Unit durchgesetzt.
Der Diensteverwalter selbst kann Systemzugangsberechtigungen erhalten, die an Dienste vom einem beherbergenden Container-Verwalter oder VM-Hypervisor weitergeleitet werden können. Siehe die Dokumentation zu der Container-Schnittstelle[14] zu Dokumentation zu Ersterem. Für Zweiteres, verwenden Sie qemu "fw_cfg" node "opt/io.systemd.credentials/". Beispielhafter Schalter für Qemu: »-fw_cfg name=opt/io.systemd.credentials/mycred,string=supersecret«. Sie können auch auf der Kernelbefehlszeile mittelsdes Schalters »systemd.set_credential=« (siehe systemd(1)) und über die UEFI-Firmware-Umgebung mittels systemd-stub(7) festgelegt werden.
Wird auf ein AF_UNIX-Datenstrom-Socket für die Verbindung referenziert, dann wird der Ursprung der Verbindung in einem abstrakten Namensraum-Socket liegen, der Informationen über die Unit und die Zugangsberechtigungskennung in seinem Socket-Namen enthält. Verwenden Sie getpeername(2), um diese Information abzufragen. Der zurückgelieferte Socket-Name ist als NUL ZUFALL »unit« UNIT »/« KENNUNG formatiert, d.h. ein NUL-Byte (wie für Socket-Namen aus abstrakten Namensräumen benötigt), gefolgt von einer zufälligen Zeichenkette (die aus alphadezimalen Zeichen besteht), gefolgt von der Zeichenkette »unit«, gefolgt von dem anfragenden Unit-Namen, gefolgt von dem Zeichen »/«, gefolgt von der erbetenen textuellen Zugangsberechtigungskennung. Beispiel: »\0adf9d86b6eda275e/unit/foobar.service/credx«, wobei die Zugangsberechtigung »credx« für eine Unit »foobar.service« erbeten wird. Diese Funktionalität ist nützlich, wenn ein einzelnes, auf Anfragen wartendes Socket Zugangsberechtigungen für mehrere Abnehmer bereitstellen soll.
Siehe System- und Dienste-Zugangsberechtigungen[15] für weitere Informationen.
SetCredential=KENNUNG:WERT, SetCredentialEncrypted=KENNUNG:WERT
Die Einstellung SetCredentialEncrypted= ist identisch zu SetCredential=, erwartet aber eine verschlüsselte Zugangsberechtigung in wörtlicher Form als Wert. Dies ermöglicht das sichere Einbetten von vertraulichen Zugangsberechtigungen direkt in Unit-Dateien. Verwenden Sie den Schalter -p von systemd-creds(1), um geeignete SetCredentialEncrypted=-Zeilen direkt aus den Klartext-Zugangsberechtigungen zu erstellen. Für weitere Details siehe LoadCredentialEncrypted= weiter oben.
Falls eine Zugangsberechtigung mit der gleichen Kennung sowohl in LoadCredential= als auch in SetCredential= aufgeführt ist, dann wird letzteres als Vorgabe agieren, falls ersteres nicht abgefragt werden kann. In diesem Fall wird der Fehlschlag, die in LoadCredential= festgelegte Zugangsberechtigung nicht abfragen zu können, nicht als fatal betrachtet.
SYSTEM V-KOMPATIBILITÄT¶
UtmpIdentifier=
UtmpMode=
UMGEBUNGSVARIABLEN IN ERZEUGTEN PROZESSEN¶
Durch den Diensteverwalter gestartete Prozesse werden mit einem Umgebungsvariablenblock gestartet, der aus verschiedenen Quellen zusammengesetzt ist. Prozesse, die durch den Systemdiensteverwalter gestartet werden, erben im Allgemeinen die für den Diensteverwalter selbst gesetzten Umgebungsvariablen nicht (dies kann durch PassEnvironment= geändert werden), aber Prozesse, die durch Benutzerdiensteverwalterinstanzen gestartet werden, erben im Allgemein alle für den Diensteverwalter selbst gesetzten Umgebungsvariablen.
Für jeden aufgerufenen Prozess wird die Liste der gesetzten Umgebungsvariablen aus den folgenden Quellen zusammengestellt:
Falls die gleiche Umgebungsvariable aus mehreren dieser Quellen gesetzt wird, gewinnt die letzte Quelle, wobei die Reihenfolge der obigen Liste zählt. Beachten Sie, dass als abschließender Schritt alle in UnsetEnvironment= aufgeführten Variablen aus der zusammengestellten Variablenliste entfernt werden, direkt bevor sie an den ausgeführten Prozess übergeben wird.
Die allgemeine Philosphie ist, Prozessen eine kleine, gepflegte Liste von Umgebungsvariablen offenzulegen. Vom Diensteverwalter (PID 1) gestartete Dienste werden ohne zusätzliche Dienste-spezifische Konfiguration und mit nur ein paar Umgebungsvariablen gestartet. Der Benutzerverwalter erbt Umgebungsvariablen wie jeder andere Systemdienst, kann aber ein paar zusätzliche Umgebungsvariablen von PAM und typischerweise zusätzliche importierte Variablen, wenn der Benutzer eine graphische Sitzung startet, empfangen. Es wird empfohlen, die Umgebungsblöcke sowohl im System- als auch in Benutzerverwaltern schlank zu halten. Vom Import aller durch graphische Sitzungen oder einer der Benutzer-Shells ererbten Variablen wird nachdrücklich abgeraten.
Tipp: systemd-run -P env und systemd-run --user -P env geben die wirksamen System- und Benutzerdiensteverwalter-Umgebungsblöcke aus.
Vom Diensteverwalter gesetzte oder ausgebreitete Umgebungsvariablen¶
Die folgenden Umgebungsvariablen werden für jeden durch den Diensteverwalter aufgerufenen Prozess ausgebreitet oder intern erstellt:
$PATH
$LANG
$USER, $LOGNAME, $HOME, $SHELL
$INVOCATION_ID
$XDG_RUNTIME_DIR
$RUNTIME_DIRECTORY, $STATE_DIRECTORY, $CACHE_DIRECTORY, $LOGS_DIRECTORY, $CONFIGURATION_DIRECTORY
$CREDENTIALS_DIRECTORY
$MAINPID
$MANAGERPID
$LISTEN_FDS, $LISTEN_PID, $LISTEN_FDNAMES
$NOTIFY_SOCKET
$WATCHDOG_PID, $WATCHDOG_USEC
$SYSTEMD_EXEC_PID
$TERM
$LOG_NAMESPACE
$JOURNAL_STREAM
Falls sowohl die Standardausgabe als auch der Standardfehler des ausgeführten Prozesses mit dem Journal über ein Datenstrom-Socket verbunden sind, wird diese Umgebungsvariable Informationen über den Standardfehlerdatenstrom enthalten, da dies normalerweise das bevorzugte Ziel für Protokolldaten ist. (Beachten Sie, dass typischerweise der gleiche Datenstrom sowohl für die Standardausgabe als auch den Standardfehler verwandt wird und daher die Umgebungsvariable sehr wahrscheinlich Geräte- und Inode-Informationen enthalten wird, die auf beide Datenstromdateideskriptoren passt.)
Diese Umgebungsvariable ist hauptsächlich nützlich, um Diensten zu erlauben, ihr verwandtes Protokollierungsprotokoll optional (mittels sd_journal_print(3) und anderer Funktionen) auf das native Journal-Protokoll anzuheben, falls ihre Standardausgabe oder Standardfehlerausgabe sowieso mit dem Journal verbunden ist. Damit wird die Lieferung von strukturierten Metadaten zusammen mit den protokollierten Nachrichten ermöglicht.
$SERVICE_RESULT
Tabelle 5. Definierte
$SERVICE_RESULT-Werte
Wert | Bedeutung |
"Erfolg" | Der Dienst lief erfolgreich und beendete sich ordnungsgemäß. |
"protocol" | Das Protokoll wurde verletzt: der Dienst hat nicht die von seiner Unit-Konfiguration verlangten Schritte absolviert (insbesondere was in der Einstellung Type= konfiguriert wurde). |
"timeout" | Einer der Schritte hat die Zeit überschritten. |
"exit-code" | Diensteprozess hat sich mit einen von Null verschiedenen Exit-Code beendet; siehe $EXIT_CODE unten für den tatsächlich zurückgelieferten Exit-Code. |
"signal" | Ein Diensteprozess wurde durch ein Signal regelwidrig beendet; ohne einen Speicherauszug. Siehe $EXIT_CODE unten für das tatsächliche Signal, das die Beendigung auslöste. |
"core-dump" | Ein Diensteprozess wurde durch ein Signal regelwidrig beendet und hat einen Speicherauszug ausgegeben. Siehe $EXIT_CODE unten für das Signal, das die Beendigung auslöste. |
"watchdog" | Der Totmannschalter des Watchdogs war für diesen Dienst aktiviert, aber die Frist wurde verpasst. |
"start-limit-hit" | Für die Unit war eine Startbegrenzung definiert und wurde erreicht, wodurch der Start der Unit fehlschlug. Siehe StartLimitIntervalSec= und StartLimitBurst= von systemd.unit(5) für Details. |
"resources" | Eine Auffangbedingung, falls eine Systemaktion fehlschlug. |
Diese Umgebungsvariable ist nützlich, um den Fehlschlag oder die erfolgreiche Beendigung eines Dienstes zu überwachen. Obwohl diese Variable sowohl in ExecStop= als auch ExecStopPost= verfügbar ist, ist es normalerweise eine bessere Wahl, die Überwachungswerkzeuge in Letzterer zu platzieren, da Erstere nur für Dienste aufgerufen wird, die ihren Start korrekt verwaltet haben und Letztere sowohl Dienste abdeckt, die während ihres Startens fehlschlugen als auch solche, die während ihrer Laufzeit fehlschlugen.
$EXIT_CODE, $EXIT_STATUS
Tabelle 6. Zusammenfassung der möglichen
Variablenwerte für
Diensteergebnisse
$SERVICE_RESULT | $EXIT_CODE | $EXIT_STATUS |
"Erfolg" | "killed" | »HUP«, »INT«, »TERM«, »PIPE« |
"exited" | "0" | |
"protocol" | not set | not set |
"exited" | "0" | |
"timeout" | "killed" | »TERM«, »KILL« |
"exited" | »0«, »1«, »2«, »3«, … »255« | |
"exit-code" | "exited" | »1«, »2«, »3«, …, »255« |
"signal" | "killed" | »HUP«, »INT«, »KILL«, … |
"core-dump" | "dumped" | »ABRT«, »SEGV«, »QUIT«, … |
"watchdog" | "dumped" | "ABRT" |
"killed" | »TERM«, »KILL« | |
"exited" | »0«, »1«, »2«, »3«, … »255« | |
"exec-condition" | "exited" | »1«, »2«, »3«, »4«, …, »254« |
"oom-kill" | "killed" | »TERM«, »KILL« |
"start-limit-hit" | not set | not set |
"resources" | jeder der obigen | jeder der obigen |
Beachten Sie: der Prozess kann auch durch ein Signal beendet werden, das nicht von Systemd gesandt wurde. Insbesondere kann der Prozess sich selbst in einem Handler ein beliebiges Signal für jedes der nicht maskierbaren Signale senden. Nichtsdestotrotz wurden in den Spalten »timeout« und »watchdog« nur die Signale aufgenommen, die Systemd sendet. Desweiteren können mittels SuccessExitStatus= zusätzliche Exit-Status erklärt werden, um die ordnungsgemäße Beendigung anzuzeigen, was in der Tabelle nicht wiedergegeben wird. |
$MONITOR_SERVICE_RESULT, $MONITOR_EXIT_CODE, $MONITOR_EXIT_STATUS, $MONITOR_INVOCATION_ID, $MONITOR_UNIT
Die Variablen $MONITOR_SERVICE_RESULT, $MONITOR_EXIT_CODE und $MONITOR_EXIT_STATUS akzeptieren die gleichen Werte wie für die Prozesse ExecStop= und ExecStopPost=. Die Variablen $MONITOR_INVOCATION_ID und $MONITOR_UNIT werden auf die Aufrufkennung und den Unit-Namen des Dienstes, der die Abhängigkeit auslöste, gesetzt.
Beachten Sie, dass diese Variablen nicht weitergegeben werden, wenn mehrere Dienste die gleiche Unit auslösten. In diesem Fall sollten Sie stattdessen eine Vorlage-Handhabungs-Unit verwenden: »OnFailure=handler@%n.service« für Units, die keine Vorlagen sind oder »OnFailure=handler@%p-%i.service« für Units, die Vorlagen sind.
$PIDFILE
Für Systemdienste können zusätzliche, durch Systemd definierte Umgebungsvariablen für Dienste gesetzt werden, wenn PAMName= aktiviert und pam_systemd Teil des ausgewählten PAM-Stacks ist. Dies sind insbesondere $XDG_SEAT und $XDG_VTNR, siehe pam_systemd(8) für Details.
PROZESS-EXIT-CODES¶
Beim Aufruf eines Unit-Prozesses könnte der Diensteverwalter möglicherweise nicht in der Lage sein, die mit den oben dargestellten Einstellungen konfigurierten Ausführungsparameter zu setzen. In diesem Fall wird sich der bereits erstellte Diensteprozess mit einem von Null verschiedenen Exit-Code beenden, bevor die konfigurierte Befehlszeile ausgeführt wird. (Oder, mit anderen Worten, der Kindprozess hat sich mit diesen Fehler-Codes beendet, nachdem er mit dem Systemaufruf fork(2) erstellt wurde, aber bevor der zugehörige Systemaufruf execve(2) erfolgte.) Insbesondere werden die durch die C-Bibliothek, die LSB-Spezifikation und durch den Systemd-Diensteverwalter selbst definierten Exit-Codes verwandt.
Die folgenden grundlegenden Dienste-Exit-Codes sind durch die C-Bibliothek definiert.
Tabelle 7. Grundlegende Exit-Codes der
C-Bibliothek
Exit-Code | Symbolischer Name | Beschreibung |
0 | EXIT_SUCCESS | Generischer Erfolgs-Code. |
1 | EXIT_FAILURE | Generischer Fehlschlag oder unspezifizierter Fehler. |
Die folgenden Dienste-Exit-Codes sind durch die LSB-Spezifikation[16] festgelegt.
Tabelle 8. LSB-Dienste-Exit-Codes
Exit-Code | Symbolischer Name | Beschreibung |
2 | EXIT_INVALIDARGUMENT | Ungültige oder überzählige Argumente. |
3 | EXIT_NOTIMPLEMENTED | Nicht implementierte Funktionalität. |
4 | EXIT_NOPERMISSION | Der Benutzer hat nicht genug Privilegien. |
5 | EXIT_NOTINSTALLED | Das Programm ist nicht installiert. |
6 | EXIT_NOTCONFIGURED | Das Programm ist nicht konfiguriert. |
7 | EXIT_NOTRUNNING | Das Programm läuft nicht. |
Die LSB-Spezifikation schlägt vor, dass Fehler-Code 200 und höher für Implementierungen reserviert ist. Einige von ihnen werden vom Diensteverwalter benutzt, um Probleme beim Aufrufen von Prozessen anzuzeigen.
Tabelle 9. Systemd-spezifische Exit-Codes
Exit-Code | Symbolischer Name | Beschreibung |
200 | EXIT_CHDIR | Änderung des angeforderten Arbeitsverzeichnisses schlug fehl. Siehe WorkingDirectory= oben. |
201 | EXIT_NICE | Scheduling-Priorität (Nice-Stufe) konnte nicht gesetzt werden. Siehe Nice= oben. |
202 | EXIT_FDS | Ungewünschter Dateideskriptor konnte nicht geschlossen werden oder übergebene Dateideskriptoren konnten nicht angepasst werden. |
203 | EXIT_EXEC | Die tatsächliche Ausführung des Prozesses schlug fehl (genauer, der Systemaufruf execve(2)). Höchstwahrscheinlich wird dies durch ein fehlendes oder nicht zugreifbares Programm hervorgerufen. |
204 | EXIT_MEMORY | Aufgrund von Speicherknappheit konnte eine Aktion nicht durchgeführt werden. |
205 | EXIT_LIMITS | Ressourcenbegrenzungen konnten nicht angepasst werden. Siehe LimitCPU= und verwandte Einstellungen oben. |
206 | EXIT_OOM_ADJUST | OOM-Einstellungen konnten nicht angepasst werden. Siehe OOMScoreAdjust= oben. |
207 | EXIT_SIGNAL_MASK | Prozesssignalmaske konnte nicht gesetzt werden. |
208 | EXIT_STDIN | Standardeingabe konnte nicht gesetzt werden. Siehe StandardInput= oben. |
209 | EXIT_STDOUT | Standardausgabe konnte nicht gesetzt werden. Siehe StandardOutput= oben. |
210 | EXIT_CHROOT | Wurzelverzeichnis konnte nicht geändert werden (chroot(2)). Siehe RootDirectory=/RootImage= oben. |
211 | EXIT_IOPRIO | E/A-Scheduling-Priorität konnte nicht gesetzt werden. Siehe IOSchedulingClass=/IOSchedulingPriority= oben. |
212 | EXIT_TIMERSLACK | Der Timer-Spielraum konnte nicht eingerichtet werden. Siehe TimerSlackNSec= oben. |
213 | EXIT_SECUREBITS | Prozess-Sicherheits-Bits konnten nicht gesetzt werden. Siehe SecureBits= oben. |
214 | EXIT_SETSCHEDULER | CPU-Scheduling konnte nicht eingerichtet werden. Siehe CPUSchedulingPolicy=/CPUSchedulingPriority= oben. |
215 | EXIT_CPUAFFINITY | CPU-Affinität konnte nicht eingerichtet werden. Siehe CPUAffinity= oben. |
216 | EXIT_GROUP | Gruppen-Zugangsberechtigungen konnten nicht bestimmt oder geändert werden. Siehe Group=/SupplementaryGroups= oben. |
217 | EXIT_USER | Benutzer-Zugangsberechtigungen konnten nicht bestimmt oder geändert werden oder Benutzernamensräume eingerichtet werden. Siehe User=/PrivateUsers= oben. |
218 | EXIT_CAPABILITIES | Capabilities konnten nicht abgegeben oder Umgebungs-Capabilities angewandt werden. Siehe CapabilityBoundingSet=/AmbientCapabilities= oben. |
219 | EXIT_CGROUP | Einrichten der Dienste-Control-Gruppe schlug fehl. |
220 | EXIT_SETSID | Erstellung einer neuen Prozesssitzung schlug fehl. |
221 | EXIT_CONFIRM | Ausführung wurde vom Benutzer abgebrochen. Siehe die Kernelbefehlszeileneinstellung systemd.confirm_spawn= in kernel-command-line(7) für Details. |
222 | EXIT_STDERR | Standardfehlerausgabe konnte nicht eingerichtet werden. Siehe StandardError= oben. |
224 | EXIT_PAM | PAM-Sitzung konnte nicht eingerichtet werden. Siehe PAMName= oben. |
225 | EXIT_NETWORK | Netzwerknamensräume konnten nicht eingericht werden. Siehe PrivateNetwork= oben. |
226 | EXIT_NAMESPACE | Einhänge-, UTS- oder IPC-Namensräume konnten nicht eingerichtet werden. Siehe ReadOnlyPaths=, ProtectHostname=, PrivateIPC= und verwandte Einstellungen oben. |
227 | EXIT_NO_NEW_PRIVILEGES | Neue Privilegien konnten nicht deaktiviert werden. Siehe NoNewPrivileges=yes oben. |
228 | EXIT_SECCOMP | Systemaufruffilter konnten nicht angewandt werden. Siehe SystemCallFilter= und verwandte Einstellungen oben. |
229 | EXIT_SELINUX_CONTEXT | SELinux-Kontext konnte nicht bestimmt oder geändert werden Siehe SELinuxContext= oben. |
230 | EXIT_PERSONALITY | Ausführungsdomäne (Personalität) konnte nicht eingerichtet werden. Siehe Personality= oben. |
231 | EXIT_APPARMOR_PROFILE | AppArmor konnte nicht vorbereitet werden. SIehe AppArmorProfile= oben. |
232 | EXIT_ADDRESS_FAMILIES | Adressfamilien konnten nicht beschränkt werden. Siehe RestrictAddressFamilies= oben. |
233 | EXIT_RUNTIME_DIRECTORY | Laufzeitverzeichnis konnte nicht eingerichtet werden. Siehe RuntimeDirectory= und verwandte Einstellungen oben. |
235 | EXIT_CHOWN | Socket-Eigentümerschaft konnte nicht angepasst werden. Wird nur für Socket-Units verwandt. |
236 | EXIT_SMACK_PROCESS_LABEL | SMACK-Sicherheits-Label konnte nicht gesetzt werden. Siehe SmackProcessLabel= oben. |
237 | EXIT_KEYRING | Kernel-Schlüsselbund konnte nicht eingerichtet werden. |
238 | EXIT_STATE_DIRECTORY | Zustandsverzeichnis der Unit konnte nicht eingerichtet werden. Siehe StateDirectory= oben. |
239 | EXIT_CACHE_DIRECTORY | Zwischenspeicherverzeichnis der Unit konnte nicht eingerichtet werden. Siehe CacheDirectory= oben. |
240 | EXIT_LOGS_DIRECTORY | Protokollierverzeichnis der Unit konnte nicht eingerichtet werden. Siehe LogsDirectory= oben. |
241 | EXIT_CONFIGURATION_DIRECTORY | Konfigurationsverzeichnis der Unit konnte nicht eingerichtet werden. Siehe ConfigurationDirectory= oben. |
242 | EXIT_NUMA_POLICY | NUMA-Richtlinie der Unit konnte nicht eingerichtet werden. Siehe NUMAPolicy= und NUMAMask= oben. |
243 | EXIT_CREDENTIALS | Zugangsberechtigungen der Unit konnten nicht eingerichtet werden. Siehe LoadCredential= und SetCredential= oben. |
245 | EXIT_BPF | BPF-Beschränkungen konnten nicht angewandt werden. Siehe RestrictFileSystems= oben. |
Schließlich definieren die BSD-Betriebssysteme eine Reihe von Exit-Codes, die typischerweise auch auf Linux-Systemen definiert sind:
Tabelle 10. BSD-Exit-Codes
Exit-Code | Symbolischer Name | Beschreibung |
64 | EX_USAGE | Befehlszeilenbenutzungsfehler |
65 | EX_DATAERR | Datenformatfehler |
66 | EX_NOINPUT | Eingabe kann nicht geöffnet werden |
67 | EX_NOUSER | Empfängerin unbekannt |
68 | EX_NOHOST | Rechnername unbekannt |
69 | EX_UNAVAILABLE | Dienst nicht verfügbar |
70 | EX_SOFTWARE | interner Softwarefehler |
71 | EX_OSERR | Systemfehler (z.B. Fork kann nicht ausgeführt werden) |
72 | EX_OSFILE | kritische Betriebssystemdatei fehlt |
73 | EX_CANTCREAT | (Benutzer)-Ausgabedatei kann nicht erstellt werden |
74 | EX_IOERR | Eingabe/Ausgabe-Fehler |
75 | EX_TEMPFAIL | Temporärer Fehlschlag, Benutzer sollte es noch einmal versuchen |
76 | EX_PROTOCOL | Ferner Fehler im Protokoll |
77 | EX_NOPERM | Erlaubnis verweigert |
78 | EX_CONFIG | Konfigurationsfehler |
BEISPIELE¶
Beispiel 3. $MONITOR_*-Verwendung
Ein Dienst myfailer.service, der eine Abhängigkeit OnFailure= auslösen kann.
[Unit] Description=Dienst, der eine Abhängigkeit OnFailure= auslösen kann OnFailure=myhandler.service [Service] ExecStart=/bin/meinprogramm
Ein Dienst mysuccess.service, der eine Abhängigkeit OnSuccess== auslösen kann.
[Unit] Description=Dienst, der eine Abhängigkeit OnSuccess= auslösen kann OnSuccess=myhandler.service [Service] ExecStart=/bin/meinzweitesprogramm
Ein Dienst myhandler.service, der von jedem der obigen Dienste ausgelöst werden kann.
[Unit] Description=Agiert bei fehlschlagenden oder erfolgreichen Diensten [Service] ExecStart=/bin/bash -c "echo $MONITOR_SERVICE_RESULT $MONITOR_EXIT_CODE $MONITOR_EXIT_STATUS $MONITOR_INVOCATION_ID $MONITOR_UNIT"
Falls myfailer.service ausgeführt und mit einem Fehlschlag beendet würde, dann würde myhandler.service ausgelöst und die Überwachungsvariablen wie folgt gesetzt:
MONITOR_SERVICE_RESULT=exit-code MONITOR_EXIT_CODE=exited MONITOR_EXIT_STATUS=1 MONITOR_INVOCATION_ID=cc8fdc149b2b4ca698d4f259f4054236 MONITOR_UNIT=meinfehlschlag.service
Falls mysuccess.service ausgeführt und mit einem Fehlschlag beendet würde, dann würde myhandler.service ausgelöst und die Überwachungsvariablen wie folgt gesetzt:
MONITOR_SERVICE_RESULT=success MONITOR_EXIT_CODE=exited MONITOR_EXIT_STATUS=0 MONITOR_INVOCATION_ID=6ab9af147b8c4a3ebe36e7a5f8611697 MONITOR_UNIT=meinerfolg.service
SIEHE AUCH¶
systemd(1), systemctl(1), systemd-analyze(1), journalctl(1), systemd-system.conf(5), systemd.unit(5), systemd.service(5), systemd.socket(5), systemd.swap(5), systemd.mount(5), systemd.kill(5), systemd.resource-control(5), systemd.time(7), systemd.directives(7), tmpfiles.d(5), exec(3), fork(2)
ANMERKUNGEN¶
- 1.
- Spezifikation für auffindbare Partitionen
- 2.
- Das /proc-Dateisystem
- 3.
- Benutzer-/Gruppennamen-Syntax
- 4.
- Schalter »Keine neuen Privilegien«
- 5.
- JSON-Benutzerdatensatz
- 6.
- proc.txt
- 7.
- Unicode Skalarwerte
- 8.
- Nichtzeichen
- 9.
- Byte-Reihenfolge-Markierung
- 10.
- Text ohne Anführungszeichen
- 11.
- Text in einfachen Anführungszeichen
- 12.
- Text in doppelten englischen Anführungszeichen
- 13.
- Base64
- 14.
- Container-Schnittstelle
- 15.
- System- und Dienste-Zugangsberechtigungen
- 16.
- LSB-Spezifikation
Ü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 251 |