Provided by: manpages-de_4.21.0-2_all bug

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:

       •   Units mit gesetzten WorkingDirectory=, RootDirectory=, RootImage=, RuntimeDirectory=,
           StateDirectory=, CacheDirectory=, LogsDirectory= oder ConfigurationDirectory= erhalten
           automatisch Abhängigkeiten vom Typ Requires= und After= von allen für den Zugriff auf
           die festgelegten Pfade notwendigen Einhängepunkten. Dies ist äquivalent zur expliziten
           Auflistung in RequiresMountsFor=.

       •   Ähnlich erhalten Einhänge-Units mit aktiviertem PrivateTmp= automatisch Abhängigkeiten
           von allen Einhängungen, die notwendig sind, auf /tmp/ und /var/tmp/ zuzugreifen. Sie
           werden auch automatische Abhängigkeiten After= von systemd-tmpfiles-setup.service(8)
           erhalten.

       •   Units, deren Standardausgabe oder Fehlerausgabe mit dem journal oder kmsg (oder ihrer
           Kombination mit Konsolenausgabe, siehe unten) verbunden ist, erlangen automatisch
           Abhängigkeiten vom Typ After= von systemd-journald.socket.

       •   Units, die LogNamespace= verwenden, werden automatisch Ordnungs- und
           Bedingungsabhängigkeiten auf die zwei zugeordneten Socket-Units mit
           systemd-journald@.service-Instanzen erlangen.

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=
           Akzeptiert eine Doppelpunkt-getrennte Liste von absoluten Pfaden, relativ zu denen die
           durch Eigenschaften Exec*= (z.B. ExecStart=, ExecStop=, usw.) verwandten Programme
           gefunden werden können. ExecSearchPath= setzt $PATH außer Kraft, falls $PATH nicht
           durch den Benutzer mittels Environment=, EnvironmentFile= oder PassEnvironment=
           bereitgestellt wird. Zuweisung einer leeren Zeichenkette entfernt vorherige
           Zuweisungen und mehrfaches Setzen von ExecSearchPath= auf einen Wert wird an die
           vorherigen Einstellungen anhängen.

           Hinzugefügt in Version 250.

       WorkingDirectory=
           Akzeptiert einen Verzeichnispfad, der relativ zu dem durch RootDirectory= festgelegten
           Wurzelverzeichnis des Dienstes ist, oder den besonderen Wert »~«. Setzt das
           Arbeitsverzeichnis für ausgeführte Prozesse. Falls auf »~« gesetzt, wird das
           Home-Verzeichnis des in User= festgelegten Benutzers verwandt. Falls nicht gesetzt,
           ist dies standardmäßig das Wurzelverzeichnis, falls Systemd als eine Systeminstanz
           läuft und das Home-Verzeichnis des respektiven Benutzers, falls es als Benutzer läuft.
           Falls der Einstellung das Zeichen »-« vorangestellt wird, wird ein fehlendes
           Arbeitsverzeichnis nicht als fatal betrachtet. Falls RootDirectory=/RootImage= nicht
           gesetzt ist, dann ist WorkingDirectory= relativ zu der Wurzel des Systems, das den
           Diensteverwalter betreibt. Beachten Sie, dass das Setzen dieses Parameters die
           Hinzunahme von zusätzlichen Abhängigkeiten (siehe oben) auslösen kann.

       RootDirectory=
           Akzeptiert einen Verzeichnispfad, der relativ zum Wurzelverzeichnis des Rechners (d.h.
           der Wurzel des Systems, auf dem der Diensteverwalter läuft) ist. Setzt mit dem
           Systemaufruf chroot(2) das Wurzelverzeichnis für ausgeführte Prozesse. Falls dies
           verwandt wird, muss sichergestellt werden, dass das Prozessprogramm und alle seine
           zugehörigen Dateien in dem chroot()-Gefängnis verfügbar sind. Beachten Sie, dass das
           Setzen dieses Parameters die Hinzunahme von zusätzlichen Abhängigkeiten (siehe oben)
           auslösen kann.

           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:

           Die Datei os-release(5) des Hauptsystems wird dem Dienst (schreibgeschützt) als
           /run/host/os-release bereitgestellt. Sie wird beim weichen Neustart automatisch
           aktualisiert (siehe systemd-soft-reboot.service(8)), falls der Dienst so konfiguriert
           ist, dass er dies überlebt.

           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. In diesem Fall ist
           PrivateUsers= impliziert aktiviert (benötigt im Kernel mittels des Sysctl
           »kernel.unprivileged_userns_clone=« aktivierte Unterstützung für nicht privilegierten
           Benutzernamensraum).

       RootImage=
           Akzeptiert einen Pfad zu einem Blockgeräteknoten oder einer regulären Datei als
           Argument. Dieser Aufruf ist ähnlich RootDirectory=, hängt allerdings eine
           Dateisystemhierarchie aus einem Blockgeräteknoten oder einer Loopback-Datei anstatt
           eines Verzeichnisses ein. Der Geräteknoten oder die Dateisystemabbilddatei müssen ein
           Dateisystem ohne Partitionstabelle enthalten oder ein Dateisystem innerhalb einer
           MBR/MS-DOS- oder GPT-Partitionstabelle mit nur einer einzelnen Linux-kompatiblen
           Partition oder eine Gruppe von Dateisystemen innerhalb einer GPT-Partitionstabelle,
           die der Spezifikation für auffindbare Partitionen[1] folgt.

           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.

           Die Datei os-release(5) des Hauptsystems wird dem Dienst (schreibgeschützt) als
           /run/host/os-release bereitgestellt. Sie wird beim weichen Neustart automatisch
           aktualisiert (siehe systemd-soft-reboot.service(8)), falls der Dienst so konfiguriert
           ist, dass er dies überlebt.

           Diese Option ist nur für Systemdienste verfügbar und wird nicht für Dienste, die in
           benutzerbezogenene Instanzen des Diensteverwalters laufen, unterstützt.

           Hinzugefügt in Version 233.

       RootImageOptions=
           Akzeptiert eine Kommata-getrennte Liste von Einhängeoptionen, die bei mit RootImage=
           angegebenen Plattenabbildern verwandt werden. Optional kann ein Partitionsname
           vorangestellt werden, gefolgt von einem Doppelpunkt, falls das Abbild über mehrere
           Partitionen verfügt, andernfalls wird der Partitionsname »root« angenommen. Optionen
           für mehrere Partitionen können in einer einzelnen Zeile durch Leerzeichen getrennt
           angegeben werden. Durch Zuweisung einer leeren Zeichenkette werden die vorhergehenden
           Zuweisungen entfernt. Doppelte Optionen werden ignoriert. Bitte lesen Sie mount(8) für
           eine Liste gültiger Einhängeoptionen.

           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.

           Hinzugefügt in Version 247.

       RootEphemeral=
           Akzeptiert ein logisches Argument. Falls aktiviert, werden ausgeführte Prozesse in
           einer flüchtigen Kopie des Wurzelverzeichnisses oder Wurzelabbildes laufen. Die
           flüchtige Kopie liegt in /var/lib/systemd/ephemeral-trees/ während der Dienst aktiv
           ist und wird bereinigt, wenn der Dienst gestoppt oder neu gestartet wird. Falls
           RootDirectory= verwandt wird und das Wurzelverzeichnis ein Unterdatenträger ist, wird
           die flüchtige Kopie durch Erstellen eines Schnappschusses des Unterdatenträgers
           erstellt.

           Um sicherzustellen, dass flüchtige Kopien effizient erstellt werden, sollte sich das
           Wurzelverzeichnis oder Wurzelabbild auf dem gleichen Dateisystem wie
           /var/lib/systemd/ephemeral-trees/ befinden. Bei der Verwendung von RootEphemeral= mit
           Wurzeldateisystemen, sollte btrfs(5) als Dateisystem verwandt werden und das
           Wurzeldateisystem sollte idealerweise ein Unterdatenträger sein, von dem systemd einen
           Schnappschuss zur Erstellung der flüchtigen Kopie schießen kann. Für Wurzelabbilder
           sollte ein Dateisystem mit Unterstützung für »reflinks« verwandt werden, um eine
           effiziente flüchtige Kopie sicherzustellen.

           Diese Option ist nur für Systemdienste verfügbar und wird nicht für Dienste, die in
           benutzerbezogenene Instanzen des Diensteverwalters laufen, unterstützt.

           Hinzugefügt in Version 254.

       RootHash=
           Akzeptiert einen hexadezimal angegebenen Datenintegritäts-Hash (dm-verity) für die
           Wurzel oder den Pfad zu einer Datei, die einen ASCII-hexadezimal-formatierten Hash der
           Wurzel enthält. Diese Option aktiviert Datenintegritätsüberprüfungen mittels
           dm-verity, falls das verwandte Abbild die geeigneten Integritätsdaten enthält (siehe
           oben) oder falls RootVerity= verwandt wird. Der angegebene Hash muss auf den
           Wurzel-Hash der Integritätsdaten passen und ist normalerweise 256 Bit (und damit 64
           formatierte hexadezimale Zeichen) lang (im Falle von beispielsweise SHA256). Falls
           diese Option nicht angegeben ist aber die Abbilddatei ein erweitertes Dateiattribut
           »user.verity.roothash« trägt (siehe xattr(7)), dann wird der Wurzel-Hash daraus
           gelesen, auch als hexdezimal formatierte Zeichen. Falls das erweiterte Dateiattribut
           nicht gefunden wird (oder vom zugrundeliegenden Dateisystem nicht unterstützt wird),
           aber eine Datei mit der Endung ».roothash« neben der Abbild-Datei gefunden wird, die
           anderweitig genau den gleichen Namen trägt (außer falls das Abbild die Endung ».raw«
           trägt, dann darf die Wurzel-Hash-Datei dies nicht in ihrem Namen haben), wird der
           Wurzel-Hash daraus gelesen und automatisch verwandt, auch als hexadezimal formatierte
           Zeichen.

           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.

           Hinzugefügt in Version 246.

       RootHashSignature=
           Akzeptiert eine PKCS7-Signatur der Option RootHash= als Pfad zu einer DER-kodierten
           Signatur oder als eine ASCII-Base64-Zeichenkette, die eine DER-kodierte Signatur
           kodiert, der »base64« vorangestellt ist. Der dm-verity-Datenträger wird nur geöffnet,
           falls die Signatur des Wuzel-Hashes gültig ist und von einem öffentlichen Schlüssel
           signiert wurde, der im Kernel-Schlüsselbund enthalten ist. Falls diese Option nicht
           angegeben ist, aber eine Datei mit der Endung ».roothash.p7s« neben der Abbild-Datei
           gefunden wird, die anderweitig genau den gleichen Namen trägt (außer falls das Abbild
           die Endung ».raw« trägt, dann darf die Signaturdatei dies nicht in ihrem Namen haben),
           dann wird die Signatur daraus gelesen und automatisch verwandt.

           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.

           Hinzugefügt in Version 246.

       RootVerity=
           Akzeptiert einen Pfad zu einer Datenintegritäts- (dm-verity-)Datei. Diese Option
           aktiviert Datenintegritätsüberprüfungen mittels dm-verity, falls RootImage= verwandt
           wird und ein Wurzel-Hash übergeben wird und falls das verwandte Abbild selbst keine
           Integritätsdaten enthält. Die Integritätsdaten müssen auf den Wurzel-Hash passen.
           Falls diese Option nicht angegeben ist, aber eine Datei mit der Endung ».verity« neben
           der Abbild-Datei gefunden wird, die anderweitig genau den gleichen Namen trägt (außer
           falls das Abbild die Endung ».raw« trägt, dann darf die Signaturdatei dies nicht in
           ihrem Namen haben), dann werden die Verity-Daten daraus gelesen und automatisch
           verwandt.

           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.

           Hinzugefügt in Version 246.

       RootImagePolicy=, MountImagePolicy=, ExtensionImagePolicy=
           Akzeptiert eine Abbildrichtlinienzeichenkette gemäß systemd.image-policy(7), die beim
           Einhängen eines in RootImage=, MountImage= bzw. ExtensionImage= festgelegten
           Plattenabbildes verwandt werden soll. Falls sie nicht angegeben ist, ist die folgende
           Richtlinienzeichenkette die Vorgabe für RootImagePolicy= und MountImagePolicy:

               root=verity+signed+encrypted+unprotected+absent: \
                       usr=verity+signed+encrypted+unprotected+absent: \
                       home=encrypted+unprotected+absent: \
                       srv=encrypted+unprotected+absent: \
                       tmp=encrypted+unprotected+absent: \
                       var=encrypted+unprotected+absent

           Die Vorgaberichtlinie für ExtensionImagePolicy= ist:

               root=verity+signed+encrypted+unprotected+absent: \
                       usr=verity+signed+encrypted+unprotected+absent

           Hinzugefügt in Version 254.

       MountAPIVFS=
           Akzeptiert ein logisches Argument. Falls eingeschaltet, wird ein privater
           Einhängenamensraum für die Prozesse der Unit erstellt und die API-Dateisysteme /proc/,
           /sys/, /dev/ und /run/ (als ein leeres »tmpfs«) darin eingehängt, außer sie sind
           bereits eingehängt. Beachten Sie, dass diese Option keinen Effekt zeigt, außer sie
           wird zusammen mit RootDirectory=/RootImage= verwandt, da diese vier Einhängungen im
           Allgemeinen im Rechner sowieso eingehängt sind und außer wenn das Wurzelverzeichnis
           geändert wird, der private Einhängenamensraum eine 1:1-Kopie des Rechners sein wird
           und diese vier Einhängungen enthalten wird. Beachten Sie, dass das /dev/-Dateisystem
           des Rechners mit »bind« eingehängt wird, falls diese Option ohne PrivateDevices=
           verwandt wird. Um den Dienst mit einer privaten, minimalen Version von /dev/
           auszuführen, kombinieren Sie diese Option mit PrivateDevices=.

           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.

           Hinzugefügt in Version 233.

       ProtectProc=
           Akzeptiert entweder »noaccess«, »invisible«, »ptraceable« oder »default« (die
           Vorgabe). Wenn gesetzt, steuert dies die Einhängeoption »hidepid=« der
           »procfs«-Instanz für die Unit, die steuert, welche Verzeichnisse mit
           Prozessmetainformationen (/proc/PID) sichtbar und zugreifbar sind: wird dies auf
           »noaccess« gesetzt, dann wird die Fähigkeit, auf die meisten Prozessmetadaten anderer
           Prozesse in /proc/ zuzugreifen, für Prozesse des Dienstes entfernt. Wird dies auf
           »invisible« gesetzt, dann werden die meisten Prozesse, die anderen Benutzern gehören,
           in /proc/ versteckt. Bei »ptraceable« werden alle Prozesse, die nicht mit ptrace()
           untersucht werden können, davor versteckt. Bei »default« werden keine Einschränkungen
           beim Zugriff auf /proc/ oder dessen Sichtbarkeit vorgenommen. Für weitere Details
           siehe Das /proc-Dateisystem[2]. Es wird im Allgemeinen empfohlen, die meisten
           Systemdienste so auszuführen, dass diese Option auf »invisible« gesetzt ist. Diese
           Option wird mittels Dateisystemnamensräumen implementiert und kann daher nicht mit
           Diensten verwandt werden, die in der Lage sein müssen, Einhängepunkte in der
           Dateisystemhierarchie des Wirts zu installieren. Beachten Sie, dass der Benutzer
           »root« von dieser Option nicht betroffen ist, um daher wirksam zu sein, muss sie
           zusammen mit User= oder DynamicUser=yes und auch ohne die Capability »CAP_SYS_PTRACE«
           verwandt werden, da letztere Capability es einem Prozess erlaubt, diese Funktionalität
           zu umgehen. Sie kann nicht für Dienste verwandt werden, die auf Metainformationen von
           Prozessen anderer Benutzer zugreifen müssen. Diese Option impliziert MountAPIVFS=.

           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.

           Hinzugefügt in Version 247.

       ProcSubset=
           Akzeptiert »all« (die Vorgabe) und »pid«. Falls »pid«, werden alle Dateien und
           Verzeichnisse, die nicht direkt der Prozessverwaltung und -prüfung zugeordnet sind, im
           Dateisystem /proc/, das für diese Prozesse konfiguriert wird, unsichtbar gemacht. Das
           steuert die Einhängeoption »subset=« der Instanz »procfs« für diese Unit. Für weitere
           Details siehe Das /proc-Dateisystem[2]. Beachten Sie, dass Linux verschiedene
           Kernel-APIs über /proc/ offenlegt, die durch diese Einstellung unverfügbar gemacht
           werden. Da diese APIs häufig verwandt werden, ist diese Option nur in wenigen,
           besonderen Fällen nützlich und nicht für die meisten nicht-trivialen Programme
           geeignet.

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

           Hinzugefügt in Version 247.

       BindPaths=, BindReadOnlyPaths=
           Konfiguriert Unit-spezifische Bind-Einhängungen. Eine Bind-Einhängung macht eine
           bestimmte Datei oder Verzeichnis an einem zusätzlichen Ort in der Betrachtung der Unit
           verfügbar. Alle mit dieser Option erstellten Bind-Einhängungen sind für die Unit
           spezifisch und nicht innerhalb der Einhängetabelle des Rechners sichtbar. Diese Option
           erwartet eine Leerraum-getrennte Liste von Bind-Einhängedefinitionen. Jede Definition
           besteht aus einem durch Doppelpunkte getrennten Tripel von Quellpfad, Zielpfad und
           Optionszeichenkette, wobei die letzteren zwei optional sind. Falls nur ein Quellpfad
           festgelegt wird, wird angenommen, dass Quelle und Ziel identisch sind. Die
           Optionszeichenkette kann entweder »rbind« oder »norbind« sein, um eine rekursive oder
           nichtrekursive Bind-Einhängung zu konfigurieren. Falls der Zielpfad ausgelassen wird,
           muss auch die Optionszeichenkette ausgelassen werden. Jeder Bind-Einhängungsdefinition
           kann »-« vorangestellt werden, wodurch sie ignoriert wird, falls der Quellpfad nicht
           existiert.

           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.

           Hinzugefügt in Version 233.

       MountImages=
           Diese Einstellung ist ähnlich zu RootImage=. Sie hängt eine Dateisystemhierarchie von
           einem Blockgeräteknoten oder Loopack-Geräte ein, aber das Ziel-Verzeichnis sowie die
           Einhängeoptionen können angegeben werden. Diese Option erwartet ein durch Leerraum
           getrennte Liste von Einhängedefinitionen. Jede Definition besteht aus einem
           Doppelpunkt-getrennten Tupel von Quellpfad- und -Ziel-Definitionen, optional gefolgt
           durch einen weiteren Doppelpunkt und einer Liste von Einhängeoptionen.

           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.

           Hinzugefügt in Version 247.

       ExtensionImages=
           Diese Einstellung ist ähnlich zu MountImages=. Sie hängt eine Dateisystemhierarchie
           von einem Blockgeräteknoten oder Loopack-Geräte ein, aber anstatt ein Ziel-Verzeichnis
           bereitzustellen, wird eine Überlagerung eingerichtet. Diese Option erwartet eine durch
           Leerraum getrennte Liste von Einhängedefinitionen. Jede Definition besteht aus einem
           Quellpfad, optional gefolgt von einem Doppelpunkt und einer Liste von
           Einhängeoptionen.

           Es wird ein nur lesbares OverlayFS oberhalb der Hierarchien /usr/ und /opt/ für
           Sysext-Abbilder und der Hierarchie /etc/ für Confext-Abbilder 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 Sysext-Abbilddatei muss eine Datei
           /usr/lib/extension-release.d/extension-release.IMAGE transportieren, während
           Confext-Abbilder eine Datei /etc/extension-release.d/extension-release.IMAGE
           transportieren müssen, mit den geeigneten Metadaten, die auf RootImage=/RootDirectory=
           oder den Rechner passen. Siehe os-release(5). Um die Sicherheitsüberprüfung, dass der
           Dateiname der Erweiterungs-Release-Datei auf den Namen der Abbild-Datei passt, zu
           deaktivieren, kann die Einhängeoption x-systemd.relax-extension-release-check
           angehängt werden.

           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.

           Hinzugefügt in Version 248.

       ExtensionDirectories=
           Diese Einstellung ist ähnlich zu BindReadOnlyPaths=. Sie hängt eine
           Dateisystemhierarchie von einem Verzeichnis ein, aber anstatt ein Ziel-Verzeichnis
           bereitzustellen, wird eine Überlagerung eingerichtet. Diese Option erwartet eine durch
           Leerraum getrennte Liste von Quellverzeichnissen.

           Es wird ein nur lesbares OverlayFS oberhalb der Hierarchien /usr/ und /opt/ für
           Sysext-Abbilder und oberhalb der Hierarchie /etc/ für Confext-Abbilder 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.

           Jedes Sysext-Verzeichnis muss eine Datei
           /usr/lib/extension-release.d/extension-release.IMAGE enthalten, während jedes
           Confext-Verzeichnis eine Datei /etc/extension-release.d/extension-release.IMAGE
           enthalten muss, 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. In diesem Fall ist
           PrivateUsers= impliziert aktiviert (benötigt im Kernel mittels des Sysctl
           »kernel.unprivileged_userns_clone=« aktivierte Unterstützung für nicht privilegierten
           Benutzernamensraum).

           Hinzugefügt in Version 251.

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=
           Setzt den UNIX-Benutzer oder die -Gruppe, unter der der Prozess ausgeführt wird.
           Akzeptiert einen einzelnen Benutzer- oder Gruppennamen oder eine numerische Kennung
           als Argument. Für Systemdienste (Dienste, die vom Systemdiensteverwalter, d.h. PID 1,
           ausgeführt werden) und für Benutzerdienste des Benutzers root (Dienste, die von der
           Instanz von root von systemd --user verwaltet werden) ist die Vorgabe »root«, aber
           User= kann zur Angabe eines anderen Benutzers verwandt werden. Für Benutzerdienste von
           allen anderen Benutzern ist das Umschalten auf eine andere Benutzeridentität nicht
           erlaubt, daher ist die einzige gültige Einstellung der Benutzer, unter dem der
           Diensteverwalter selbst läuft. Falls keine Gruppe gesetzt ist, wird die Vorgabegruppe
           des Benutzers verwandt. Diese Einstellung beeinflusst keine Befehle, deren
           Befehlszeile ein »+« vorangestellt ist.

           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=
           Akzeptiert einen logischen Parameter. Falls gesetzt, wird ein
           UNIX-Benutzer-/Gruppenpaar dynamisch beim Start der Unit erstellt und wieder
           freigegeben, sobald die Unit beendet wird. Der Benutzer und die Gruppe wird nicht zu
           /etc/passwd oder /etc/group hinzugefügt, sondern zur Laufzeit vorübergehend verwaltet.
           Das Glibc-NSS-Modul nss-systemd(8) stellt eine Integration dieser dynamischen
           Benutzer/Gruppen in die Benutzer- und Gruppendatenbanken des Systems bereit. Die
           Benutzer- und Gruppennamen können mit User= und Group= (siehe oben) konfiguriert
           werden. Falls diese Optionen nicht verwandt werden und dynamische
           Benutzer-/Gruppenzuweisung für eine Unit aktiviert ist, wird der Name des dynamischen
           Benutzers/der dynamischen Gruppe implizit vom Unit-Namen abgeleitet. Falls der
           Unit-Name ohne die Typ-Endung als gültiger Benutzername geeignet ist, wird er direkt
           verwandt, andernfalls wird ein Name, der einen Hash davon integriert, verwandt. Falls
           ein statisch zugewiesener Benutzer oder eine statisch zugewiesene Gruppe des
           konfigurierten Namens bereits existiert, wird diese verwandt und kein dynamischer
           Benutzer/keine dynamische Gruppe wird zugewiesen. Beachten Sie, dass es notwendig ist,
           dass der statische Benutzer mit dem Namen bereits existiert, falls User= angegeben
           wurde und die statische Gruppe mit dem Namen bereits existiert. Entsprechend ist es
           notwendig, dass die statische Gruppe mit dem Namen bereits existiert, falls Group=
           angegeben wurde und der statische Benutzer mit dem Namen bereits existiert. Dynamische
           Benutzer/Gruppen werden aus dem UID/GID-Bereich 61184…65519 zugewiesen. Es wird
           empfohlen, diesen Bereich für reguläre System- oder Anmeldebenutzer zu vermeiden. Zu
           jedem Zeitpunkt ist eine UID/GID aus diesem Bereich nur keinem oder einem/einer
           verwandten Benutzer/Gruppe dynamisch zugewiesen. Nachdem eine Unit beendet wurde,
           werden allerdings UIDs/GIDs wiederbenutzt. Es sollte Vorsicht walten gelassen werden,
           dass jeder Prozess, der als Teil einer Unit läuft, für die dynamische Benutzer/Gruppen
           aktiviert sind, keine Dateien oder Verzeichnisse, die diesen Benutzern/Gruppen
           gehören, zurücklässt, da eine andere Unit später die gleiche UID/GID zugewiesen
           bekommen kann, und daher Zugriff auf diese Dateien oder Verzeichnisse erlangen kann.
           Die Aktivierung von DynamicUser= impliziert RemoveIPC= und PrivateTmp= (was nicht
           deaktiviert werden kann). Dies stellt sicher, dass die Lebensdauer von IPC-Objekten
           und temporären Dateien, die von dem ausgeführten Prozess erstellt wurden, an die
           Laufzeit des Dienstes gebunden ist, und damit die Lebensdauer des dynamischen
           Benutzers/der dynamischen Gruppe. Da /tmp/ und /var/tmp/ normalerweise die einzigen
           global schreibbar Verzeichnisse auf einem System sind, stellt dies sicher, dass eine
           Unit, die dynamische Benutzer-/Gruppenzuweisungen einsetzt, keine Dateien nach der
           Beendigung hinterlassen kann. Desweiteren werden NoNewPrivileges= und
           RestrictSUIDSGID= implizit aktiviert (und können nicht deaktiviert werden), um
           sicherzustellen, dass aufgerufene Prozesse nicht aus SUID/SGID-Dateien oder
           Verzeichnissen Nutzen ziehen oder diese erstellen können. Darüberhinaus sind
           ProtectSystem=strict und ProtectHome=read-only impliziert, die damit verhindern, dass
           der Dienst an beliebige Dateisystemstellen schreibt. Um dem Dienst das Schreiben in
           bestimmte Verzeichnisse zu erlauben, müssen diese mittels ReadWritePaths= explizit
           erlaubt werden; dabei ist drauf zu achten, dass die Wiederbenutzung von UIDs/GIDs
           keine Sicherheitsprobleme mit vom Dienst erstellten Dateien hervorruft. Verwenden Sie
           RuntimeDirectory= (siehe unten), um dem Dienst ein schreibbares Laufzeitverzeichnis
           zuzuweisen, das von dem dynamischen Benutzer/der dynamischen Gruppe besessen und
           automatisch beim Beenden der Unit entfernt wird. Verwenden Sie StateDirectory=,
           CacheDirectory= und LogsDirectory=, um eine Gruppe an schreibbaren Verzeichnissen für
           einen bestimmten Zweck dem Dienst zuzuweisen und dabei sicherzustellen, dass sie vor
           Schwachstellen aufgrund der UID-Wiederbenutzung geschützt sind (siehe unten). Falls
           diese Option aktiviert ist, sollte aufgepasst werden, dass die Prozesse der Unit
           keinen Zugriff auf Verzeichnisse außerhalb dieser explizit konfigurierten und
           verwalteten bekommen. Verwenden Sie inbesondere nicht BindPaths= und seien Sie
           vorsichtig mit der Übergabe von AF_UNIX-Dateideskriptoren für
           Verzeichnisdateideskriptoren, da dieses Prozessen erlauben würde, Dateien oder
           Verzeichnisse zu erstellen, die dem dynamischen Benutzer/der dynamischen Gruppe
           gehören und nicht dem Lebenszyklus und den Zugriffsgarantien des Dienstes unterliegen.
           Beachten Sie, dass diese Option derzeit inkompatibel zu D-Bus-Richtlinien ist. Daher
           könnte ein Dienst, der diese Option verwendet, derzeit keinen D-Bus-Dienstenamen
           reservieren. Beachten Sie, dass dies nicht den Aufruf anderer D-Bus-Dienste
           beeinträchtigt. Standardmäßig »off«.

           Hinzugefügt in Version 232.

       SupplementaryGroups=
           Setzt die zusätzlichen Gruppen, unter denen die Prozesse ausgeführt werden. Dies
           akzeptiert eine Leerzeichen-getrennte Liste von Gruppennamen oder -Kennungen. Diese
           Option kann mehr als einmal angegeben werden, dann werden alle aufgeführten Gruppen
           als zusätzliche Gruppen gesetzt. Wird die leere Zeichenkette zugewiesen, dann wird die
           Liste der zusätzlichen Gruppen zurückgesetzt und alle Zuweisungen davor werden
           unwirksam. Auf jeden Fall setzt diese Option nicht die Liste der in der
           Systemgruppendatenbank für den Benutzer konfigurierten zusätzlichen Gruppen außer
           Kraft sondern erweitert sie. Dies betrifft nicht Befehle, denen »+« vorangestellt ist.

       SetLoginEnvironment=
           Dieser logische Parameter steuert, ob die Umgebungsvariablen $HOME, $LOGNAME und
           $SHELL gesetzt werden. Falls nicht gesetzt, wird dies dadurch gesteuert, ob User=
           gesetzt ist. Falls wahr, werden sie für Systemdienste immer gesetzt, d.h. selbst wenn
           der Standardbenutzer »root« verwandt wird. Falls falsch, werden die aufgeführten
           Variablen durch Systemd nicht gesetzt, unabhängig davon, ob User= verwandt wird oder
           nicht. Diese Option hat bei Benutzerdiensten normalerweise keine Auswirkung, da diese
           Variablen sowieso typischerweise von der eigenen Umgebung des Benutzerverwalters
           geerbt werden.

           Hinzugefügt in Version 255.

       PAMName=
           Setzt den PAM-Dienstenamen, um darunter eine Sitzung einzurichten. Falls gesetzt, wird
           der ausgeführte Prozess als eine PAM-Sitzung unter dem festgelegten Dienstenamen
           registriert. Dies ist nur in Zusammenspiel mit der Einstellung User= nützlich und wird
           sonst ignoriert. Falls nicht gesetzt, wird keine PAM-Sitzung für den ausgeführten
           Prozess eröffnet. Siehe pam(8) für Details.

           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. In diesem Fall ist PrivateUsers=
       implizit aktiviert (benötigt Unterstützung für nicht privilegierte Benutzernamensräume im
       Kernel mittels des Sysctl ».kernel.unprivileged_userns_clone=«).

       CapabilityBoundingSet=
           Steuert, welche Capabilities in der Capability-Begrenzungsmenge für den ausgeführten
           Prozess aufgenommen werden. Siehe capabilities(7) für Details. Akzeptiert eine
           Leerzeichen-getrennte Liste von Capability-Namen, z.B. CAP_SYS_ADMIN,
           CAP_DAC_OVERRIDE, CAP_SYS_PTRACE. Aufgeführte Capabilities werden in die
           Begrenzungsmenge aufgenommen, alle anderen werden entfernt. Falls der Liste von
           Capabilities »~« vorangestellt wird, werden alle bis auf die aufgeführten Capabilities
           aufgenommen, die Wirkung der Zuweisung invertiert. Beachten Sie, dass diese Option
           auch die respektiven Capabilities in der effektiven, erlaubten und vererbbaren
           Capability-Menge betrifft. Falls diese Option nicht verwandt wird, wird die
           Capability-Begrenzungsmenge bei der Prozessausführung nicht verändert, daher werden
           keine Begrenzungen bezüglich der Capabilities des Prozesses erzwungen. Diese Option
           kann mehr als einmal auftauchen, die Begrenzungsmengen werden mit ODER zusammengeführt
           oder mit UND, falls den Zeilen »~« vorangestellt wird (siehe unten). Falls dieser
           Option die leere Zeichenkette zugewiesen wird, wird die Begrenzungsmenge auf die leere
           Capability-Menge zurückgesetzt und alle vorhergehenden Einstellungen haben keine
           Wirkung. Falls auf »~« (ohne weiteres Argument) gesetzt, wird die Begrenzungsmenge auf
           die komplette Menge der verfügbaren Capabilities zurückgesetzt und alle vorhergehenden
           Einstellungen zurückgenommen. Dies betrifft nicht Befehle, denen »+« vorangestellt
           wurde.

           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=
           Steuert, welche Capabilities in der Umgebungs-Capability-Menge für den ausgeführten
           Prozess aufgenommen werden. Akzeptiert eine Leerzeichen-getrennte Liste von
           Capability-Namen, z.B. CAP_SYS_ADMIN, CAP_DAC_OVERRIDE, CAP_SYS_PTRACE. Diese Option
           kann mehr als einmal auftauchen, die Umgebungsmengen werden zusammengeführt (siehe
           Beispiele oben in CapabilityBoundingSet=). Falls der Liste von Capabilities »~«
           vorangestellt wird, werden alle bis auf die aufgeführten Capabilities aufgenommen, die
           Wirkung der Zuweisung invertiert. Falls die leere Zeichenkette dieser Option
           zugewiesen wird, wird die Umgebungsmenge auf die leere Capability-Menge zurückgesetzt
           und alle vorhergehenden Einstellungen haben keine Wirkung. Falls auf »~« (ohne
           weiteres Argument) gesetzt, wird die Umgebungsmenge auf die komplette Menge der
           verfügbaren Capabilities zurückgesetzt und alle vorhergehenden Einstellungen
           zurückgenommen. Beachten Sie, dass die Hinzunahme von Capabilities in die
           Umgebungsmenge sie auch zu der vererbbaren Menge des Prozesses hinzufügt.

           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.

           Hinzugefügt in Version 229.

SICHERHEIT

       NoNewPrivileges=
           Akzeptiert ein logisches Argument. Falls wahr, wird sichergestellt, dass der
           Diensteprozess und sämtliche seiner Kindprozesse niemals mittels execve() neue
           Privilegien erlangen können (z.B. mittels Setuid- oder Setgid-Bits oder
           Dateisystem-Capabilities). Dies ist die einfachste und effektivste Art,
           sicherzustellen, dass ein Prozess und seine Kinder niemals wieder Privilegien erhöhen
           können. Standardmäßig falsch. Auf jeden Fall wird der Dienst in einem neuen
           Einhängenamensraum und deaktiviertem SELinux ausgeführt, und alle Dateisysteme werden
           mit dem Schalter MS_NOSUID eingehängt. Siehe auch Schalter »Keine neuen
           Privilegien«[4].

           Beachten Sie, dass diese Einstellung nur Auswirkungen auf die Prozesse der Unit selbst
           hat (oder alle anderen Prozesse, die direkt oder indirekt von ihnen per Fork erzeugt
           wurden). Sie hat keine Auswirkung auf Prozesse, die möglicherweise auf Anforderungen
           von ihnen mittels Werkzeugen wie at(1), crontab(1), systemd-run(1) oder beliebigen
           IPC-Diensten erzeugt wurden.

           Hinzugefügt in Version 187.

       SecureBits=
           Steuert die Menge der sicheren Bits für den ausgeführten Prozess. Akzeptiert eine
           durch Leerzeichen getrennte Kombination von Optionen aus der folgenden Liste:
           keep-caps, keep-caps-locked, no-setuid-fixup, no-setuid-fixup-locked, noroot und
           noroot-locked. Diese Option darf mehr als einmal auftauchen, dann werden die sicheren
           Bits ODER-verknüpft. Falls der Option die leere Zeichenkette zugewiesen wird, werden
           die Bits auf 0 zurückgesetzt. Dies betrift keine Befehle, denen »+« vorangestellt ist.
           Siehe capabilities(7) für Details.

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=
           Setzt den SELinux-Sicherheitskontext des ausgeführten Prozesses. Falls gesetzt, wird
           dies den automatischen Domain-Übergang außer Kraft setzen. Allerdings muss die Policy
           den Übergang erlauben. Diese Anweisung wird ignoriert, falls SELinux deaktiviert ist.
           Falls »-« vorangestellt ist, wird ein Fehlschlag, den SELinux-Sicherheitskontext zu
           setzen, ignoriert; es ist aber weiterhin möglich, dass nachfolgende execve()
           fehlschlagen, falls die Richtlinie keine Überleitung für die nicht außer Kraft
           gesetzten Kontexte erlaubt. Dies betrifft keine Befehle, denen »+« vorangestellt ist.
           Siehe setexeccon(3) für Details.

           Hinzugefügt in Version 209.

       AppArmorProfile=
           Akzeptiert einen Profilnamen als Argument. Der von der Unit ausgeführte Prozess wird
           beim Start in dieses Profil umschalten. Profile müssen bereits in den Kernel geladen
           sein oder die Unit schlägt fehl. Falls ein »-« vorangestellt ist, werden alle Fehler
           ignoriert. Diese Einstellung hat keine Auswirkung, falls AppArmor nicht aktiviert ist.
           Diese Einstellung betrifft keine Befehle, denen »+« vorangestellt ist.

           Hinzugefügt in Version 210.

       SmackProcessLabel=
           Akzeptiert ein SMACK64-Sicherheits-Label als Argument. Der durch diese Unit
           ausgeführte Prozess wird unter diesem Label gestartet und SMACK wird darauf basierend
           entscheiden, ob die Ausführung des Prozesses erlaubt ist. Der Prozess wird weiter
           unter dem hier angegebenen Label laufen, außer falls das Programm seinen eigenen
           SMACK64EXEC-Label hat, in welchem Falle der Prozess dazu übergehen wird, unter diesem
           Label zu laufen. Falls nicht angegeben, wird der Label verwandt, unter dem Systemd
           läuft. Diese Anweisung wird ignoriert, falls SMACK deaktiviert ist.

           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.

           Hinzugefügt in Version 218.

PROZESSEIGENSCHAFTEN

       LimitCPU=, LimitFSIZE=, LimitDATA=, LimitSTACK=, LimitCORE=, LimitRSS=, LimitNOFILE=,
       LimitAS=, LimitNPROC=, LimitMEMLOCK=, LimitLOCKS=, LimitSIGPENDING=, LimitMSGQUEUE=,
       LimitNICE=, LimitRTPRIO=, LimitRTTIME=
           Setzt die weichen und harten Beschränkungen für verschiedene Ressourcen für
           ausgeführte Prozesse. Siehe setrlimit(2) für Details über das
           Prozessressourcen-Begrenzungskonzept. Prozessressourcenbegrenzungen können in zwei
           Formaten festgelegt werden: entweder als einzelner Wert, um eine bestimmte weiche und
           harte Begrenzung auf den gleichen Wert zu setzen, oder als Doppelpunkt-getrenntes Paar
           weich:hart, um beide Begrenzungen individuell zu setzen (z.B. »LimitAS=4G:16G«).
           Verwenden Sie die Zeichenkette infinity, um keine Begrenzung für eine bestimmte
           Ressource zu konfigurieren. Die multiplikativen Endungen K, M, G, T, P und E (auf
           Basis 1024) können für Ressourcenbegrenzungen, die in Bytes gemessen werden, verwandt
           werden (z.B. »LimitAS=16G«). Für Begrenzungen, die sich auf Zeitwerte beziehen, können
           die im Englischen normalen Zeiteinheiten ms, s, min, h und so weiter verwandt werden
           (siehe systemd.time(7) für Details). Beachten Sie, dass die Standardzeiteinheit als
           Sekunden impliziert ist, falls keine Zeiteinheit für LimitCPU= angegeben ist. Für
           LimitRTTIME= wird als Standardeinheit Mikrosekunden impliziert. Beachten Sie, dass die
           effektive Granularität der Begrenzungen ihre Durchsetzung beeinflussen könnte.
           Beispielsweise werden für LimitCPU= festgelegte Zeitbeschränkungen implizit auf
           Vielfache von 1s aufgerundet. Für LimitNICE= kann der Wert in zwei Syntaxen festgelegt
           werden: falls ihm »+« oder »-« vorangestellt wird, wird der Wert als regulärer
           Linux-Nice-Wert im Bereich -20…19 interpretiert. Falls ihm so etwas nicht
           vorangestellt wird, wird der Wert als roher Ressourcenbegrenzungsparameter im Bereich
           0…40 (wobei 0 äquivalent zu 1 ist) verstanden.

           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
           ┌─────────────────┬───────────────────┬─────────────────────┬──────────────────────────────┐
           │Anweisungulimit-ÄquivalentEinheitHinweise                     │
           ├─────────────────┼───────────────────┼─────────────────────┼──────────────────────────────┤
           │LimitCPU=        │ ulimit -t         │ Sekunden            │ -                            │
           ├─────────────────┼───────────────────┼─────────────────────┼──────────────────────────────┤
           │LimitFSIZE=      │ ulimit -f         │ Bytes               │ -                            │
           ├─────────────────┼───────────────────┼─────────────────────┼──────────────────────────────┤
           │LimitDATA=       │ ulimit -d         │ Bytes               │ Nicht verwenden.             │
           │                 │                   │                     │ Diese beschränkt             │
           │                 │                   │                     │ den erlaubten                │
           │                 │                   │                     │ Adressbereich,               │
           │                 │                   │                     │ nicht die                    │
           │                 │                   │                     │ Speicherverwendung!          │
           │                 │                   │                     │ Standardmäßig                │
           │                 │                   │                     │ unbeschränkt und             │
           │                 │                   │                     │ sollte nicht                 │
           │                 │                   │                     │ gesenkt werden. Um           │
           │                 │                   │                     │ die                          │
           │                 │                   │                     │ Speicherverwendung           │
           │                 │                   │                     │ zu beschränken,              │
           │                 │                   │                     │ siehe MemoryMax= in          │
           │                 │                   │                     │ systemd.resource-control(5). │
           ├─────────────────┼───────────────────┼─────────────────────┼──────────────────────────────┤
           │LimitSTACK=      │ ulimit -s         │ Bytes               │ -                            │
           ├─────────────────┼───────────────────┼─────────────────────┼──────────────────────────────┤
           │LimitCORE=       │ ulimit -c         │ Bytes               │ -                            │
           ├─────────────────┼───────────────────┼─────────────────────┼──────────────────────────────┤
           │LimitRSS=        │ ulimit -m         │ Bytes               │ Nicht verwenden. Hat unter   │
           │                 │                   │                     │ Linux keine Auswirkung.      │
           ├─────────────────┼───────────────────┼─────────────────────┼──────────────────────────────┤
           │LimitNOFILE=     │ ulimit -n         │ Anzahl an           │ Nicht verwenden. Seien Sie   │
           │                 │                   │ Dateideskriptoren   │ beim Anheben der weichen     │
           │                 │                   │                     │ Begrenzung über 1024         │
           │                 │                   │                     │ vorsichtig, da unter Linux   │
           │                 │                   │                     │ select(2) nicht mit          │
           │                 │                   │                     │ Dateideskriptoren über 1023  │
           │                 │                   │                     │ umgehen kann. Heutzutage ist │
           │                 │                   │                     │ die harte Begrenzung 524288. │
           │                 │                   │                     │ Verglichen mit  historischen │
           │                 │                   │                     │ Vorgaben ist dies ein sehr   │
           │                 │                   │                     │ hoher Wert. Typische         │
           │                 │                   │                     │ Anwendungen sollten ihre     │
           │                 │                   │                     │ weiche Begrenzung            │
           │                 │                   │                     │ selbständig auf die harte    │
           │                 │                   │                     │ Begrenzung anheben, falls    │
           │                 │                   │                     │ sie mit Dateideskriptoren    │
           │                 │                   │                     │ oberhalb von 1023 umgehen    │
           │                 │                   │                     │ können, d.h. nicht select(2) │
           │                 │                   │                     │ verwenden. Beachten Sie,     │
           │                 │                   │                     │ dass Dateideskriptoren       │
           │                 │                   │                     │ heutzutage wie jede andere   │
           │                 │                   │                     │ Form an Speicher verwaltet   │
           │                 │                   │                     │ werden und es daher keinen   │
           │                 │                   │                     │ Bedarf zum Absenken der      │
           │                 │                   │                     │ harten Begrenzung geben      │
           │                 │                   │                     │ sollte. Verwenden Sie        │
           │                 │                   │                     │ MemoryMax=, um die           │
           │                 │                   │                     │ Gesamtspeicherverwendung von │
           │                 │                   │                     │ Diensten zu steuern,         │
           │                 │                   │                     │ einschließlich des Speichers │
           │                 │                   │                     │ für Dateideskriptoren.       │
           ├─────────────────┼───────────────────┼─────────────────────┼──────────────────────────────┤
           │LimitAS=         │ ulimit -v         │ Bytes               │ Nicht verwenden. Diese       │
           │                 │                   │                     │ beschränkt den erlaubten     │
           │                 │                   │                     │ Adressbereich, nicht die     │
           │                 │                   │                     │ Speicherverwendung!          │
           │                 │                   │                     │ Standardmäßig unbeschränkt   │
           │                 │                   │                     │ und sollte nicht gesenkt     │
           │                 │                   │                     │ werden. Um die               │
           │                 │                   │                     │ Speicherverwendung zu        │
           │                 │                   │                     │ beschränken, siehe           │
           │                 │                   │                     │ MemoryMax= in                │
           │                 │                   │                     │ systemd.resource-control(5). │
           ├─────────────────┼───────────────────┼─────────────────────┼──────────────────────────────┤
           │LimitNPROC=      │ ulimit -u         │ Anzahl an Prozessen │ Diese Beschränkung wird      │
           │                 │                   │                     │ basierend auf der Anzahl der │
           │                 │                   │                     │ dem Benutzer gehörenden      │
           │                 │                   │                     │ Prozesse durchgesetzt.       │
           │                 │                   │                     │ Normalerweise ist es besser, │
           │                 │                   │                     │ die Prozesse pro Dienst      │
           │                 │                   │                     │ nachzuverfolgen, d.h.        │
           │                 │                   │                     │ Verwendung von TasksMax=,    │
           │                 │                   │                     │ siehe                        │
           │                 │                   │                     │ systemd.resource-control(5). │
           ├─────────────────┼───────────────────┼─────────────────────┼──────────────────────────────┤
           │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=     │ ulimit -R         │ Mikrosekunden       │ -                            │
           └─────────────────┴───────────────────┴─────────────────────┴──────────────────────────────┘

       UMask=
           Steuert die Dateimoduserstellungsmaske. Akzeptiert einen Zugriffsmodus in oktaler
           Notation. Siehe umask(2) für Details. Standardmäßig 0022 für System-Units. Für
           Benutzer-Units wird der Vorgabewert von dem benutzerbezogenen Diensteverwalter geerbt
           (dessen Vorgabewert wiederum vom Systemdiensteverwalter geerbt wird, und daher
           typischerweise auch 0022 ist — außer dies wurde von einem PAM-Modul außer Kraft
           gesetzt). Um die benutzerbezogene Maske für alle Benutzerdienste zu ändern, sollten
           Sie stattdessen die Einstellung UMask= in der Systemdiensteinstanz user@.service des
           Benutzers setzen. Die benutzerbezogene Umask kann auch mittels des Feldes umask in dem
           JSON-Benutzerdatensatz[5] eines Benutzers gesetzt werden (für Benutzer, die mittels
           systemd-homed.service(8) verwaltet werden, kann dieses Feld auch über homectl --umask=
           gesteuert werden). Es kann auch mittels eines PAM-Moduls wie pam_umask(8) gesetzt
           werden.

       CoredumpFilter=
           Steuert, welche Arten von Speicher-Mappings gesichert werden, falls der Prozess einen
           Speicherauszug durchführt (mittels der Datei /proc/PID/coredump_filter). Akzeptiert
           eine Leerraum-getrennte Kombination von Mapping-Typnamen oder -nummern (mit der
           Vorgabebasis 16). Mapping-Typ-Namen sind private-anonymous, shared-anonymous,
           private-file-backed, shared-file-backed, elf-headers, private-huge, shared-huge,
           private-dax, shared-dax und der besondere Wert all (alle Typen) und default (die
           Vorgabe des Kernels »private-anonymous shared-anonymous elf-headers private-huge«).
           Siehe core(5) für die Bedeutung der Mapping-Typen. Falls mehrfach angegeben, werden
           alle angegebenen Masken mit ODER verbunden. Wenn nicht gesetzt oder der leere Wert
           zugewiesen wurde, wird der ererbte Wert nicht geändert.

           Beispiel 2. DAX-Seiten zum Speicherauszugsfilter hinzufügen

               CoredumpFilter=default private-dax shared-dax

           Hinzugefügt in Version 246.

       KeyringMode=
           Steuert, wie der Kernelsitzungsschlüsselbund für den Dienst eingerichtet wird (siehe
           session-keyring(7) für Details über den Sitzungsschlüsselbund). Akzeptiert einen aus
           inherit, private, shared. Falls auf inherit gesetzt, wird keine besondere
           Schlüsselbundeinrichtung vorgenommen und das Standardverhalten des Kernels wird
           angewandt. Falls private verwandt wird, wird ein neuer Sitzungsschlüsselbund
           bereitgestellt, wenn ein Diensteprozess aufgerufen wird und dieser nicht mit einem
           Benutzerschlüsselbund verbunden ist. Dies ist die für Systemdienste empfohlene
           Einstellung, da sie sicherstellt, dass mehrere Dienste, die unter der gleichen
           Systembenutzerkennung laufen (insbesondere des Benutzers root) ihr Schlüsselmaterial
           nicht gemeinsam benutzen. Falls shared verwandt wird, wird ein neuer Schlüsselbund wie
           für private reserviert, aber der Benutzerschlüsselbund des mit User= konfigurierten
           Benutzers wird mit eingebunden, so dass die dem Benutzer zugeordneten Schlüssel von
           den Prozessen der Unit angefragt werden können. In diesem Modus können mehrere Units,
           die Prozesse unter der selben Benutzerkennung ausführen, Schlüsselmaterial gemeinsam
           benutzen. Außer bei der Auswahl von inherit wird die eindeutige Aufrufkennung für die
           Unit (siehe unten) als geschützter Schlüssel unter dem Namen »invocation_id« zu dem
           neu erstellten Sitzungsschlüsselbund hinzugefügt. Standardmäßig private für Dienste
           des Systemdiensteverwalters und inherit für nicht Dienste-Units und für Dienste des
           Benutzerdiensteverwalters.

           Hinzugefügt in Version 235.

       OOMScoreAdjust=
           Setzt den Anpassungswert für die Speicherknappheit- (OOM-)Killer-Bewertung des Kernels
           für ausgeführte Prozesse. Akzeptiert eine Ganzzahl zwischen -1000 (um das OOM-Töten
           von Prozessen dieser Unit zu deaktivieren) und 1000 (womit das Töten von Prozessen
           dieser Unit bei Speicherdruck sehr wahrscheinlich wird). Siehe Das
           /proc-Dateisystem[6] für Details. Falls nicht angegeben, ist die Vorgabe die
           OOM-Bewertungsanpassungsstufe des Diensteverwalters selbst, die normalerweise auf 0
           gesetzt ist.

           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=
           Setzt den Timer-Spielraum in Nanosekunden für den ausgeführten Prozess). Der
           Timer-Spielraum steuert die Genauigkeit der durch Systemd-Timer ausgelösten
           Aufwachaktionen. Siehe prctl(2) für weitere Informationen. Beachten Sie, dass im
           Gegensatz zu den meisten anderen Zeitdauerdefinitionen dieser Parameter einen
           Ganzzahlwert in Nanosekunden akzeptiert, falls keine Einheit angegeben ist. Es werden
           auch die normalen Zeiteinheiten verstanden.

       Personality=
           Steuert, welche Kernelarchitektur uname(2) melden soll, wenn es von Unit-Prozessen
           aufgerufen wird. Akzeptiert eine der Architekturkennungen arm64, arm64-be, arm,
           arm-be, x86, x86-64, ppc, ppc-le, ppc64, ppc64-le, s390 oder s390x. Welche
           Personalitätsarchitekturen unterstützt werden, hängt von der nativen Architektur des
           Kernels ab. Normalerweise unterstützen die 64-Bit-Versionen der verschiedenen
           Systemarchitekturen die direkte Entsprechung der 32-Bit-Personalitätsarchitektur, aber
           keine anderen. Beispielsweise unterstützen x86-64-Systeme die x86-64- und
           x86-Personalitäten, aber keine anderen. Die Personalitätsfunktionalität ist nützlich,
           wenn 32-Bit-Dienste auf einem 64-Bit-System ausgeführt werden. Falls nicht angegeben,
           wird die Personalität nicht verändert und spiegelt daher die Personalität des
           Systemkernels wider. Diese Option ist auf Architekturen nicht nützlich, für die nur
           eine native Wortbreite jemals verfügbar war, wie m68k (nur 32 bit) oder alpha (nur 64
           bit).

           Hinzugefügt in Version 209.

       IgnoreSIGPIPE=
           Akzeptiert ein logisches Argument. Falls wahr, wird SIGPIPE in dem ausgeführten
           Prozess ignoriert. Standardmäßig wahr, da SIGPIPE im Allgemeinen nur in Shell-Pipes
           nützlich ist.

SCHEDULING

       Nice=
           Setzt den Vorgabe-Nice-Wert (Scheduling-Priorität) für ausgeführte Prozesse.
           Akzeptiert eine Ganzzahl zwischen -20 (höchste Priorität) und 19 (niedrigste
           Priorität). Im Falle von Ressourcenkonflikten bedeuten kleinere Werte, dass mehr
           Ressourcen für die Prozesse der Unit zur Verfügung gestellt werden und größere Werte,
           dass weniger Ressourcen zur Verfügung gestellt werden. Siehe setpriority(2) für
           Details.

       CPUSchedulingPolicy=
           Setzt die CPU-Scheduling-Richtlinie für ausgeführte Prozesse. Akzeptiert eines aus
           other, batch, idle, fifo, rr. Siehe sched_setscheduler(2) für Details.

       CPUSchedulingPriority=
           Setzt die CPU-Scheduling-Priorität für ausgeführte Prozesse. Der verfügbare
           Prioritätenbereich hängt von der ausgewählten CPU-Scheduling-Richtlinie (siehe oben)
           ab. Für Echtzeit-Scheduling-Richtlinien kann eine Ganzzahl zwischen 1 (niedrigste
           Priorität) und 99 (höchste Priorität) verwandt werden. Im Falle von
           CPU-Ressourcenkonflikten bedeuten kleinere Werte, dass weniger CPU-Zeit dem Dienst zur
           Verfügung gestellt wird und größere Werte bedeuten mehr. Siehe sched_setscheduler(2)
           für Details.

       CPUSchedulingResetOnFork=
           Akzeptiert ein logisches Argument. Falls wahr, werden erhöhte
           CPU-Scheduling-Prioritäten und -Richtlinien zurückgesetzt, wenn ausgeführte Prozesse
           fork(2) aufrufen und können daher nicht an Kindprozesse durchsickern. Siehe
           sched_setscheduler(2) für Details. Standardmäßig falsch.

       CPUAffinity=
           Steuert die CPU-Affinität des ausgeführten Prozesses. Akzeptiert eine durch Leerraum
           oder Kommata getrennte Liste von CPU-Indizes oder -Bereichen. Alternativ wird der
           besondere Wert »numa« akzeptiert. In diesem Fall leitet Systemd die erlaubten
           CPU-Bereiche basierend auf der Option NUMAMask= automatisch ab. CPU-Bereiche werden
           durch den unteren und oberen CPU-Index, getrennt durch einen Bindestrich, festgelegt.
           Diese Option kann mehr als einmal angegeben werden; in diesem Fall werden die
           festgelegten CPU-Affinitätsmasken zusammengeführt. Falls die leere Zeichenkette
           zugewiesen wird, wird die Maske zurückgesetzt und alle vorherigen Zuweisungen haben
           keinen Effekt. Siehe sched_setaffinity(2) für Details.

       NUMAPolicy=
           Steuert die NUMA-Speicherrichtlinie des ausgeführten Prozesses. Akzeptiert einen
           Richtlinientyp, einer aus: default, preferred, bind, interleave und local. Eine Liste
           von NUMA-Knoten, die der Richtlinie zugeordnet werden sollen, muss in NUMAMask=
           festgelegt werden. Für weitere Details über jede Richtlinie lesen Sie bitte
           set_mempolicy(2). Für einen allgemeinen Überblick über die NUMA-Unterstützung in
           Linux, siehe numa(7).

           Hinzugefügt in Version 243.

       NUMAMask=
           Steuert die NUMA-Knotenliste, die zusammen mit der ausgewählten NUMA-Richtlinie
           angewandt wird. Akzeptiert eine Liste von NUMA-Knoten und hat die gleiche Syntax wie
           eine Liste von CPUs für die Option CPUAffinity= oder den besonderen Wert »all«, der
           alle verfügbaren NUMA-Knoten in der Maske enthält. Beachten Sie, dass für die
           Richtlinien default und local keine Liste von NUMA-Knoten benötigt und für die
           Richtlinie preferred ein einzelner NUMA-Knoten erwartet wird.

           Hinzugefügt in Version 243.

       IOSchedulingClass=
           Setzt die E/A-Scheduling-Klasse für ausgeführte Prozesse. Akzeptiert eine der
           Zeichenketten realtime, best-effort oder idle. Die Vorgabe-Scheduling-Klasse des
           Kernels ist best-effort mit Priorität 4. Falls dieser Option die leere Zeichenkette
           zugewiesen wird, haben alle vorhergehenden Zuweisungen zu IOSchedulingClass= und
           IOSchedulingPriority= keinen Effekt. Siehe ioprio_set(2) für Details.

       IOSchedulingPriority=
           Setzt die E/A-Scheduling-Priorität für ausgeführte Prozesse. Akzeptiert eine Ganzzahl
           zwischen 0 (höchste Priorität) und 7 (niedrigste Priorität). Im Falle von
           E/A-Konflikten bedeuten kleinere Werte, dass den Prozessen der Unit mehr
           E/A-Bandbreite zur Verfügung gestellt wird und größere Werte bedeuten weniger
           Bandbreite. Die verfügbaren Prioritäten hängen von der ausgewählten
           E/A-Scheduling-Klasse (siehe oben) ab. Falls dieser Option die leere Zeichenkette
           zugewiesen wird, haben alle vorhergehenden Zuweisungen zu IOSchedulingClass= und
           IOSchedulingPriority= keinen Effekt. Für die Vorgabe-Scheduling-Klasse des Kernels
           (best-effort) ist dies standardmäßig 4. Siehe ioprio_set(2) für Details.

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=
           Akzeptiert ein logisches Argument oder die besonderen Werte »full« oder »strict«.
           Falls wahr, werden die Verzeichnisse /usr/ und die des Systemstartprogramms (/boot and
           /efi) für von dieser Unit aufgerufene Prozesse nur lesbar eingehängt. Falls auf »full«
           gesetzt, wird auch das Verzeichnis /etc/ nur lesbar eingehängt. Falls auf »strict«
           gesetzt, wird die gesamte Dateisystemhierarchie nur lesbar eingehängt, außer der
           API-Dateisystemunterbäume /dev/, /proc/ und /sys/ (schützen Sie diese Verzeichnisse
           mittels PrivateDevices=, ProtectKernelTunables=, ProtectControlGroups=). Diese
           Einstellung stellt sicher, dass alle Änderungen an dem vom Lieferanten
           bereitgestellten Betriebssystem (und optional seiner Konfiguration und lokaler
           Einhängungen) für den Dienst verboten sind. Es wird empfohlen, diese Einstellung für
           alle langlaufenden Dienste zu aktivieren, außer sie sind an Systemaktualisierungen
           beteiligt oder müssen das Betriebssystem auf eine andere Art verändern. Falls diese
           Option verwandt wird, kann ReadWritePaths= verwandt werden, um bestimmte Verzeichnisse
           von dem nur lesbaren Verhalten auszunehmen. 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. Standardmäßig aus.

           Hinzugefügt in Version 214.

       ProtectHome=
           Akzeptiert ein logisches Argument oder die besonderen Werte »read-only« oder »tmpfs«.
           Falls wahr, wird der Zugriff auf die Verzeichnisse /home/, /root und /run/user
           entzogen, sie erscheinen für von der Unit aufgerufene Prozesse leer. Falls auf
           »read-only« gesetzt, werden die drei Verzeichnisse stattdessen nur lesbar gesetzt.
           Falls auf »tmpfs« gesetzt, werden temporäre Dateisysteme auf diesen drei
           Verzeichnissen im nur-lesbaren Modus eingehängt. Der Wert »tmpfs« ist nützlich, um
           Home-Verzeichnisse, die für die von der Unit aufgerufenen Prozesse nicht relevant
           sind, zu verstecken, während gleichzeitig notwendige Verzeichnisse weiterhin sichtbar
           gemacht werden können, indem sie mit BindPaths= oder BindReadOnlyPaths= aufgelistet
           werden.

           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. In diesem Fall ist
           PrivateUsers= impliziert aktiviert (benötigt im Kernel mittels des Sysctl
           »kernel.unprivileged_userns_clone=« aktivierte Unterstützung für nicht privilegierten
           Benutzernamensraum).

           Hinzugefügt in Version 214.

       RuntimeDirectory=, StateDirectory=, CacheDirectory=, LogsDirectory=,
       ConfigurationDirectory=
           Diese Optionen akzeptieren eine Leerraum-getrennte Liste von Verzeichnisnamen. Die
           angegebenen Verzeichnisnamen müssen relativ sein und dürfen »..« nicht enthalten.
           Falls beim Starten der Unit gesetzt, werden ein oder mehrere Verzeichniss(e) mit den
           angegebenen Namen unterhalb der in der nachfolgenden Tabelle definierten Orte erstellt
           (einschließlich ihrer Eltern), wenn die Unit gestartet wird. Auch wird die
           entsprechende Umgebungsvariable mit dem vollständigen Pfad der Verzeichnisse
           definiert. Falls mehrere Verzeichnisse gesetzt sind, dann werden die Pfade in der
           Umgebungsvariablen mit dem Doppelpunkt (»:«) verkettet.

           Tabelle 2. Automatische Verzeichniserstellung und Umgebungsvariablen
           ┌────────────────────────┬────────────────────┬──────────────────────┬──────────────────────────┐
           │VerzeichnisUnterhalb vom PfadUnterhalb vom PfadUmgebungsvariablenmenge  │
           │                        │ von System-Unitsvon Benutzer-Units   │                          │
           ├────────────────────────┼────────────────────┼──────────────────────┼──────────────────────────┤
           │RuntimeDirectory=/run/$XDG_RUNTIME_DIR$RUNTIME_DIRECTORY       │
           ├────────────────────────┼────────────────────┼──────────────────────┼──────────────────────────┤
           │StateDirectory=/var/lib/$XDG_STATE_HOME$STATE_DIRECTORY         │
           ├────────────────────────┼────────────────────┼──────────────────────┼──────────────────────────┤
           │CacheDirectory=/var/cache/$XDG_CACHE_HOME$CACHE_DIRECTORY         │
           ├────────────────────────┼────────────────────┼──────────────────────┼──────────────────────────┤
           │LogsDirectory=/var/log/$XDG_STATE_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.

           Hinzugefügt in Version 211.

       RuntimeDirectoryMode=, StateDirectoryMode=, CacheDirectoryMode=, LogsDirectoryMode=,
       ConfigurationDirectoryMode=
           Legt die Zugriffsmodi der in RuntimeDirectory=, StateDirectory=, CacheDirectory=,
           LogsDirectory= bzw. ConfigurationDirectory= angegebenen Verzeichnisse in einer oktalen
           Zahl fest. Standardmäßig 0755. Siehe »Permissions« in path_resolution(7) für eine
           Diskussion über die Benennung der Berechtigungs-Bits.

           Hinzugefügt in Version 234.

       RuntimeDirectoryPreserve=
           Akzeptiert ein logisches Argument oder restart. Falls auf die Vorgabe no gesetzt,
           werden die in RuntimeDirectory= festgelegten Verzeichnisse immer entfernt, wenn der
           Dienst beendet wird. Falls auf restart gesetzt, werden die Verzeichnisse erhalten,
           wenn der Dienst sowohl automatisch als auch manuell neu gestartet wird. Hier bedeutet
           der automatische Neustart die in Restart= festgelegte Aktion und manueller Neustart
           bedeutet die durch systemctl restart foo.service ausgelöste. Falls auf yes gesetzt,
           werden die Verzeichnisse nicht entfernt, wenn der Dienst beendet wird. Beachten Sie,
           dass die in RuntimeDirectory= festgelegten Verzeichnisse entfernt werden, wenn das
           System neu gestartet wird, da das Laufzeitverzeichnis /run/ ein »tmpfs«-Einhängepunkt
           ist.

           Hinzugefügt in Version 235.

       TimeoutCleanSec=
           Konfiguriert für die mittels systemctl clean  erbetene Aufräumaktion eine
           Zeitüberschreitung, siehe systemctl(1) für Details. Akzeptiert die gewöhnlichen
           Zeitwerte und ist standardmäßig infinity, d.h. standardmäßig wird keine
           Zeitüberschreitung angewandt. Falls eine Zeitüberschreitung konfiguriert ist, wird die
           Aufräumaktion zwangsweise beendet, wenn die Zeitüberschreitung erreicht ist,
           möglicherweise verbleiben dann Ressourcen auf der Platte.

           Hinzugefügt in Version 244.

       ReadWritePaths=, ReadOnlyPaths=, InaccessiblePaths=, ExecPaths=, NoExecPaths=
           Richtet einen neuen Dateisystemnamensraum für ausgeführte Prozesse ein. Diese Optionen
           können zur Begrenzung des Zugriffs eines Prozesses auf das Dateisystem verwandt
           werden. Jede Einstellung akzeptiert eine Leerzeichen-getrennte Liste von Pfaden, die
           relativ zum Wurzelverzeichnis des Rechners (d.h. des Systems, das den Diensteverwalter
           ausführt) ist. Beachten Sie, dass die Pfade relativ zu dem mit
           RootDirectory=/RootImage= gesetzten Wurzelverzeichnis aufgelöst werden, falls sie
           Symlinks enthalten.

           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. Beachten
           Sie, dass ReadWritePaths= nicht zum Erlangen von Schreibzugriff auf ein Dateisystem
           verwandt werden kann, dessen Superblock schreibgeschützt eingehängt ist. Unter Linux
           wird für jeden Einhängepunkt der Schreibzugriff nur erlaubt, falls der Einhängepunkt
           selbst und der ihm zugrundeliegende Dateisystemsuperblock nicht als schreibgeschützt
           markiert sind. ReadWritePaths= steuert nur ersteres und nicht letzteres, daher bleibt
           ein schreibgeschützter Dateisystemsuperblock geschützt.

           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.

           Seien Sie besonders vorsichtig, wenn Sie diese Optionen für API-Dateisysteme verwenden
           (eine Liste dieser können Sie unter MountAPIVPS= finden), da sie für grundlegende
           Systemfunktionalität notwendig sein können. Desweitern muss /run/ schreibbar sein, um
           Einhängenamensräume und Weiterleitung einzurichten.

           Beispiel für eine einfache Erlaubnisliste mittels dieser Direktiven:

               [Service]
               ReadOnlyPaths=/
               ReadWritePaths=/var /run
               InaccessiblePaths=-/lost+found
               NoExecPaths=/
               ExecPaths=/usr/sbin/mein_Daemon /usr/lib /usr/lib64

           Diese Optionen sind nur für Systemdienste verfügbar oder für Dienste, die in
           benutzerbezogenen Instanzen des Diensteverwalters laufen. In diesem Fall ist
           PrivateUsers= implizit aktiviert (benötigt Unterstützung für nicht privilegierte
           Benutzernamensräume im Kernel mittels des Sysctl
           ».kernel.unprivileged_userns_clone=«).

           Hinzugefügt in Version 231.

       TemporaryFileSystem=
           Akzeptiert eine Leerzeichen-getrennte Liste von Einhängepunkten für temporäre
           Dateisysteme (tmpfs). Falls gesetzt, wird ein neuer Dateisystemnamensraum für
           ausgeführte Prozesse eingerichtet und in jeden Einhängepunkt ein temporäres
           Dateisystem eingehängt. Diese Option kann mehr als einmal angegeben werden, dann
           werden an allen aufgeführten Einhängepunkten temporäre Dateisysteme eingehängt. Falls
           dieser Option die leere Zeichenkette zugewiesen wird, wird die Liste zurückgesetzt und
           alle vorherigen Zuweisungen haben keinen Effekt. Jedem Einhängepunkt darf optional ein
           Doppelpunkt (»:«) und Einhängeoptionen wie »size=10%« oder »ro« angehängt werden.
           Standardmäßig wird jedes temporäre Dateisystem mit »nodev,strictatime,mode=0755«
           eingehängt. Dies kann durch explizite Angabe der entsprechenden Einhängeoptionen
           deaktiviert werden, z.B. »dev« oder »nostrictatime«.

           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. In diesem Fall ist
           PrivateUsers= impliziert aktiviert (benötigt im Kernel mittels des Sysctl
           »kernel.unprivileged_userns_clone=« aktivierte Unterstützung für nicht privilegierten
           Benutzernamensraum).

           Hinzugefügt in Version 238.

       PrivateTmp=
           Akzeptiert ein logisches Argument. Falls wahr, wird ein neuer Dateisystemnamensraum
           für den ausgeführten Prozess eingerichtet und private /tmp/- und
           /var/tmp/-Verzeichnisse darin eingehängt, die nicht mit Prozessen außerhalb des
           Namensraums gemeinsam genutzt werden. Dies ist nützlich, um Zugriff auf temporäre
           Dateien des Prozesses abzusichern, allerdings ist die gemeinsame Benutzung von
           Inhalten über /tmp/ oder /var/tmp/ mit anderen Prozessen unmöglich. Falls »wahr«,
           werden alle durch einen Dienst in diesen Verzeichnissen erstellten temporären Dateien
           entfernt, nachdem der Dienst gestoppt ist. Standardmäßig falsch. Es ist möglich, zwei
           oder mehr Units mit dem gleichen privaten /tmp/- und /var/tmp/-Namensraum durch
           Verwendung der Anweisung JoinsNamespaceOf= zu benutzen, siehe systemd.unit(5) für
           Details. Diese Einstellung ist impliziert, falls DynamicUser= gesetzt ist. Für diese
           Einstellung gelten die gleichen Beschränkungen bezüglich Einhängeausbreitung und
           Privilegien wie für ReadOnlyPaths= und verwandte Aufrufe, siehe oben. Aktivieren
           dieser Einstellung hat den Seiteneffekt des Hinzufügens der Abhängigkeiten Requires=
           und After= zu allen für den Zugriff auf /tmp/ und /var/tmp/ notwendigen
           Einhänge-Units. Desweiteren wird eine implizite After=-Ordnung auf
           systemd-tmpfiles-setup.service(8) hinzugefügt.

           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. In diesem Fall ist
           PrivateUsers= impliziert aktiviert (benötigt im Kernel mittels des Sysctl
           »kernel.unprivileged_userns_clone=« aktivierte Unterstützung für nicht privilegierten
           Benutzernamensraum).

       PrivateDevices=
           Akzeptiert ein logisches Argument. Falls wahr, wird eine neue /dev/-Einhängung für den
           ausgeführten Prozess eingerichtet und nur API-Pseudogeräte wie /dev/null, /dev/zero
           oder /dev/random (sowie das Pseudo-TTY-Untersystem) hinzugefügt, aber keine physischen
           Geräte wie /dev/sda, Systemspeicher /dev/mem, System-Ports /dev/port und andere. Dies
           ist nützlich, um Zugriff auf physische Geräte für ausgeführte Prozesse abzustellen.
           Standardmäßig falsch.

           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.

           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. In diesem Fall ist
           PrivateUsers= impliziert aktiviert (benötigt im Kernel mittels des Sysctl
           »kernel.unprivileged_userns_clone=« aktivierte Unterstützung für nicht privilegierten
           Benutzernamensraum).

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

           Hinzugefügt in Version 209.

       PrivateNetwork=
           Akzeptiert ein logisches Argument. Falls wahr, wird ein Netzwerknamensraum für die
           ausgeführten Prozesse eingerichtet und darin nur das Loopback-Netzwerkgerät »lo«
           konfiguriert. Dem ausgeführten Prozess wird kein anderes Netzwerkgerät zur Verfügung
           stehen. Dies ist nützlich, um den ausgeführten Prozessen den Netzwerkzugriff zu
           verweigern. Standardmäßig falsch. Es ist möglich, zwei oder mehr Units mit dem
           gleichen privaten Netzwerknamensraum durch Verwendung der Anweisung JoinsNamespaceOf=
           zu benutzen, siehe systemd.unit(5) für Details. Beachten Sie, dass diese Option alle
           Socket-Einrichtungen, einschließlich AF_NETLINK und AF_UNIX, vom Rechner trennen wird.
           Effektiv bedeutet das für AF_NETLINK, dass von systemd-udevd.service(8) empfangene
           Gerätekonfigurationsereignisse nicht zu den Prozessen der Unit ausgeliefert werden.
           Und für AF_UNIX hat dies den Effekt, dass AF_UNIX-Sockets in dem abstrakten Namensraum
           des Rechners für Prozesse der Unit unverfügbar werden (allerdings werden solche im
           Dateisystem weiterhin zugreifbar sein).

           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 aktiviert ist, wird PrivateMounts= impliziert, außer es ist explizit
           deaktiviert und /sys wird neu eingehängt, um es mit dem neuen Netzwerknamensraum zu
           assoziieren.

           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. In diesem Fall ist
           PrivateUsers= impliziert aktiviert (benötigt im Kernel mittels des Sysctl
           »kernel.unprivileged_userns_clone=« aktivierte Unterstützung für nicht privilegierten
           Benutzernamensraum).

       NetworkNamespacePath=
           Akzeptiert einen absoluten Dateisystempfad, der sich auf eine
           Linux-Netzwerknamensraum-Pseudodatei bezieht (d.h. einer Datei wie /proc/$PID/ns/net
           oder einer Bind-Einhängung oder einem Symlink darauf). Ist dies gesetzt, dann werden
           aufgerufene Prozesse zu dem durch diesen Pfad referenzierten Netzwerknamensraum
           hinzugefügt. Der Pfad muss zum Zeitpunkt des Aufrufs von »fork« auf eine gültige
           Netzwerknamensraumdatei zeigen. Falls diese Option verwandt wird, hat PrivateNetwork=
           keine Wirkung. Falls diese Option zusammen mit JoinsNamespaceOf= verwandt wird, dann
           hat sie nur eine Wirkung, falls diese Unit gestartet wird, bevor alle der aufgeführten
           Units, die PrivateNetwork= oder NetworkNamespacePath= konfiguriert haben, gestartet
           wird, da andernfalls der Netzwerknamensraum dieser Units neu verwendet wird.

           Wenn diese Option aktiviert ist, wird PrivateMounts= impliziert, außer es ist explizit
           deaktiviert und /sys wird neu eingehängt, um es mit dem neuen Netzwerknamensraum zu
           assoziieren.

           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. In diesem Fall ist
           PrivateUsers= impliziert aktiviert (benötigt im Kernel mittels des Sysctl
           »kernel.unprivileged_userns_clone=« aktivierte Unterstützung für nicht privilegierten
           Benutzernamensraum).

           Hinzugefügt in Version 242.

       PrivateIPC=
           Akzeptiert ein logisches Argument. Falls wahr, wird ein neuer IPC-Namensraum für den
           ausgeführten Prozess eingerichtet. Jeder IPC-Namensraum hat seine eigene Gruppe an
           System-V-IPC-Kennzeichnern und sein eigenes
           POSIX-Nachrichtenwarteschlangen-Dateisystem. Dies ist zur Vermeidung von
           Namens-Kollisionen bei IPC-Kennzeichnern nützlich. Standardmäßig falsch. Es ist
           möglich, zwei oder mehr Units innerhalb des gleichen privaten IPC-Namensraum
           auszuführen, indem die Direktive JoinsNamespaceOf= verwandt wird, siehe
           systemd.unit(5) für Details.

           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. In diesem Fall ist
           PrivateUsers= impliziert aktiviert (benötigt im Kernel mittels des Sysctl
           »kernel.unprivileged_userns_clone=« aktivierte Unterstützung für nicht privilegierten
           Benutzernamensraum).

           Hinzugefügt in Version 248.

       IPCNamespacePath=
           Akzeptiert einen absoluten Dateisystempfad, der sich auf eine
           Linux-IPC-Namensraum-Pseudodatei bezieht (d.h. einer Datei wie /proc/$PID/ns/ipc oder
           einer Bind-Einhängung oder einem Symlink darauf). Ist dies gesetzt, dann werden
           aufgerufene Prozesse zu dem durch diesen Pfad referenzierten Netzwerknamensraum
           hinzugefügt. Der Pfad muss zum Zeitpunkt des Aufrufs von »fork« auf eine gültige
           Netzwerknamensraumdatei zeigen. Falls diese Option verwandt wird, hat PrivateIPC=
           keine Wirkung. Falls diese Option zusammen mit JoinsNamespaceOf= verwandt wird, dann
           hat sie nur eine Wirkung, falls diese Unit gestartet wird, bevor alle der aufgeführten
           Units, die PrivateIPC= oder IPCNamespacePath= konfiguriert haben, gestartet wird, da
           andernfalls der Netzwerknamensraum dieser Units neu verwendet wird.

           Diese Option ist nur für Systemdienste verfügbar oder für Dienste, die in
           benutzerbezogenen Instanzen des Diensteverwalters laufen. In diesem Fall ist
           PrivateUsers= impliziert aktiviert (benötigt im Kernel mittels des Sysctl
           »kernel.unprivileged_userns_clone=« aktivierte Unterstützung für nicht privilegierten
           Benutzernamensraum).

           Hinzugefügt in Version 248.

       MemoryKSM=
           Akzeptiert ein logisches Argument. Wenn gesetzt, aktiviert es KSM (Zusammenführung
           gleicher Seiten des Kernels) für den Prozess. KSM ist eine speichersparende
           Deduplizierungsfunktionalität. Anonyme Speicherseiten mit identischem Inhalt können
           durch eine einzelne, schreibgeschützte Seite ersetzt werden. Diese Funktionalität
           sollte nur für Aufträge aktiviert werden, die in der gleichen Sicherheitsdomäne sind.
           Zu Details siehe Kernel Samepage Merging[7] in der Kerneldokumentation.

           Beachten Sie, dass diese Funktionalität nicht verfügbar sein könnte, beispielsweise
           falls KSM im Kernel deaktiviert wurde oder der Kernel die Steuerung von KSM auf der
           Prozessebene mittels prctl(2) nicht unterstützt.

           Hinzugefügt in Version 254.

       PrivateUsers=
           Akzeptiert ein logisches Argument. Falls wahr, richtet es einen neuen
           Benutzernamensraum für den ausgeführten Prozess ein und konfiguriert eine minimale
           Benutzer- und Gruppenabbildung, die den Benutzer und die Gruppe »root« sowie den
           Benutzer und die Gruppe der Unit auf sich selbst und alles andere auf den Benutzer und
           die Gruppe »nobody« abbildet. Dies ist nützlich, um die von der Unit verwandte
           Benutzer- und Gruppendatenbank sicher vom Rest des Systems abzutrennen und daher eine
           effektive Sandbox-Umgebung zu erstellen. Alle Dateien, Verzeichnisse, Prozesse,
           IPC-Objekte und andere Ressourcen, die nicht »root« (Benutzer/Gruppe) oder der
           Unit-eigenen gehören, bleiben von innerhalb der Unit sichtbar, scheinen aber dem
           Benutzer und der Gruppe »nobody« zu gehören. Falls dieser Modus aktiviert ist, werden
           alle Unit-Prozesse ohne Privilegien in dem Systembenutzernamensraum ausgeführt
           (unabhängig davon, ob der Benutzer / die Gruppe der Unit »root« ist oder nicht). Dies
           bedeutet insbesondere, dass der Prozess über keine Prozess-Capabilities im
           Systembenutzerraum, aber über volle Capabilities innerhalb des Benutzernamensraums des
           Dienstes verfügen wird. Einstellungen wie CapabilityBoundingSet= beeinflussen nur
           Letzteren und es gibt keine Möglichkeit, zusätzliche Capabilities im Benutzerraum des
           Systems zu erlangen. Standardmäßig aus.

           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.

           Hinzugefügt in Version 232.

       ProtectHostname=
           Akzeptiert ein logisches Argument. Wenn gesetzt, wird ein neuer UTS-Namensraum für den
           ausgeführten Prozess eingerichtet. Zusätzlich wird die Veränderung des »hostname« oder
           »domainname« verhindert. Standardmäßig »off«.

           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.

           Diese Option ist nur für Systemdienste verfügbar oder für Dienste, die in
           benutzerbezogenen Instanzen des Diensteverwalters laufen. In diesem Fall ist
           PrivateUsers= impliziert aktiviert (benötigt im Kernel mittels des Sysctl
           »kernel.unprivileged_userns_clone=« aktivierte Unterstützung für nicht privilegierten
           Benutzernamensraum).

           Hinzugefügt in Version 242.

       ProtectClock=
           Akzeptiert ein logisches Argument. Falls wahr, werden Schreibzugriffe auf die
           Hardware- oder System-Uhr verweigert. Standardmäßig aus. Aktivierung dieser Option
           entfernt CAP_SYS_TIME und CAP_WAKE_ALARM aus der Capability-Begrenzungsmenge für diese
           Unit, installiert einen Systemaufruffilter, um Systemaufruf zu blockieren, die die Uhr
           stellen und DeviceAllow=char-rtc r ist impliziert. Beachten Sie, dass die
           Systemaufrufe insgesamt blockiert sind, der Filter berücksichtigt nicht, dass einige
           der Aufrufe zum Lesen des Uhrzustandes mit einigen Parameterkombinationen verwandt
           werden können. Effektiv werden dadurch /dev/rtc0, /dev/rtc1 usw. für den Dienst nur
           lesbar. Siehe systemd.resource-control(5) für die Details von DeviceAllow=.

           Für die meisten Dienste, die die Uhr nicht verändern oder ihren Zustand prüfen müssen,
           wird empfohlen, dies einzuschalten.

           Diese Option ist nur für Systemdienste verfügbar oder für Dienste, die in
           benutzerbezogenen Instanzen des Diensteverwalters laufen. In diesem Fall ist
           PrivateUsers= impliziert aktiviert (benötigt im Kernel mittels des Sysctl
           »kernel.unprivileged_userns_clone=« aktivierte Unterstützung für nicht privilegierten
           Benutzernamensraum).

           Hinzugefügt in Version 245.

       ProtectKernelTunables=
           Akzeptiert ein logisches Argument. Falls wahr, sind die durch /proc/sys/, /sys/,
           /proc/sysrq-trigger, /proc/latency_stats, /proc/acpi, /proc/timer_stats, /proc/fs und
           /proc/irq verfügbaren Kernelvariablen für alle Prozesse der Unit nur lesbar.
           Normalerweise sollten einstellbare Kernelvariablen nur zum Systemstartzeitpunkt
           initialisiert werden, beispielsweise über den Mechanismus sysctl.d(5). Zur Laufzeit
           müssen wenige Dienste diese schreiben, es wird daher empfohlen, dies für die meisten
           Dienste einzuschalten. Für diese Einstellung gelten die gleichen Einschränkungen
           bezüglich Einhängeausbreitung und Privilegien wie für ReadOnlyPaths= und verwandte
           Aufrufe, siehe oben. Standardmäßig aus. Beachten Sie, dass diese Option keine
           indirekten Änderungen an Kerneleinstellungen, die durch IPC-Aufrufe an andere Prozesse
           erfolgen, verhindert. Allerdings kann InaccessiblePaths= verwandt werden, um die
           relevanten IPC-Dateisystemobjekte unzugreifbar zu machen. Falls ProtectKernelTunables=
           gesetzt ist, wird MountAPIVFS=yes impliziert.

           Diese Option ist nur für Systemdienste verfügbar oder für Dienste, die in
           benutzerbezogenen Instanzen des Diensteverwalters laufen. In diesem Fall ist
           PrivateUsers= impliziert aktiviert (benötigt im Kernel mittels des Sysctl
           »kernel.unprivileged_userns_clone=« aktivierte Unterstützung für nicht privilegierten
           Benutzernamensraum).

           Hinzugefügt in Version 232.

       ProtectKernelModules=
           Akzeptiert ein logisches Argument. Falls wahr, wird das explizite Laden von Modulen
           verweigert. Dies erlaubt es, das Modulladen und -entladen für modulare Kernel
           abzuschalten. Es wird empfohlen, dieses für die meisten Dienste, die keine besonderen
           Dateisysteme oder zusätzliche Kernelmodule für ihre Arbeit benötigen, einzuschalten.
           Standardmäßig aus. Einschalten dieser Option entfernt CAP_SYS_MODULE aus der
           Capability-Begrenzungsmenge für die Unit und installiert einen Systemaufruffilter, um
           Modulsystemaufrufe zu blockieren; sie macht auch /usr/lib/modules unzugreifbar. Für
           diese Einstellungen gelten die gleichen Einschränkungen bezüglich Einhängeausbreitung
           und Privilegien wie für ReadOnlyPaths= und verwandte Aufrufe, siehe oben. Beachten
           Sie, dass begrenztes automatisches Modulladen aufgrund von Benutzerkonfiguration oder
           Kernelabbildungstabellen als Seiteneffekt von angefragten Benutzeraktionen, sowohl
           privilegiert als auch unprivilegiert, weiterhin vorkommen kann. Um die Funktionalität
           des automatischen Modulladens zu deaktivieren, lesen Sie bitte die Dokumentation zum
           Mechanismus kernel.modules_disabled von sysctl.d(5) und
           /proc/sys/kernel/modules_disabled.

           Diese Option ist nur für Systemdienste verfügbar oder für Dienste, die in
           benutzerbezogenen Instanzen des Diensteverwalters laufen. In diesem Fall ist
           PrivateUsers= impliziert aktiviert (benötigt im Kernel mittels des Sysctl
           »kernel.unprivileged_userns_clone=« aktivierte Unterstützung für nicht privilegierten
           Benutzernamensraum).

           Hinzugefügt in Version 232.

       ProtectKernelLogs=
           Akzeptiert ein logisches Argument. Falls wahr, wird der Zugriff auf den
           Kernelprotokollringpuffer verweigert. Für die meisten Dienste, die den
           Kernelprotokollringpuffer weder lesen noch schreiben müssen, wird empfohlen, dies
           einzuschalten. Aktivierung dieser Option entfernt CAP_SYSLOG aus der
           Capability-Begrenzungsmenge für diese Unit und installiert einen Systemaufruffilter,
           um den Systemaufruf syslog(2) (der nicht mit der Libc-API syslog(3) für
           Benutzerprotokollierung durcheinandergebracht werden darf) blockiert. Der Kernel legt
           seinen Protokollpuffer mittels /dev/kmsg und /proc/kmsg offen. Falls aktiviert, werden
           diese für alle Prozesse der Unit nicht mehr zugreifbar sein.

           Diese Option ist nur für Systemdienste verfügbar oder für Dienste, die in
           benutzerbezogenen Instanzen des Diensteverwalters laufen. In diesem Fall ist
           PrivateUsers= impliziert aktiviert (benötigt im Kernel mittels des Sysctl
           »kernel.unprivileged_userns_clone=« aktivierte Unterstützung für nicht privilegierten
           Benutzernamensraum).

           Hinzugefügt in Version 244.

       ProtectControlGroups=
           Akzeptiert ein logisches Argument. Falls wahr, werden die über /sys/fs/cgroup/
           erreichbaren »Linux Control Groups« (cgroups(7))-Hierarchien für alle der Prozesse nur
           lesbar sein. Außer für Container-Verwalter sollte kein Dienst Schreibzugriff auf diese
           Control-Gruppenhierarchie benötigen; es wird daher empfohlen, dies für die meisten
           Dienste einzuschalten. Für diese Einstellungen gelten die gleichen Einschränkungen
           bezüglich Einhängeausbreitung und Privilegien wie für ReadOnlyPaths= und verwandte
           Aufrufe, siehe oben. Standardmäßig aus. Falls ProtectControlGroups= gesetzt ist, wird
           MountAPIVFS=yes impliziert.

           Diese Option ist nur für Systemdienste verfügbar und wird nicht für Dienste, die in
           benutzerbezogenene Instanzen des Diensteverwalters laufen, unterstützt.

           Hinzugefügt in Version 232.

       RestrictAddressFamilies=
           Beschränkt die Gruppe der Socket-Adressfamilien, auf die Prozesse dieser Unit
           zugreifen können. Akzeptiert »none« oder eine Leerzeichen-getrennte Liste von
           freizugebenden Adressfamiliennamen, wie AF_UNIX, AF_INET oder AF_INET6. Wird »none«
           festgelegt, dann werden alle Adressfamilien verboten. Wird der Liste »~«
           vorangestellt, wird die Liste der Adressfamilien als Ausschlussliste angewandt,
           andernfalls als Freigabeliste. Beachten Sie, dass dies nur Zugriff auf den
           Systemaufruf socket(2) beschränkt. Sockets, die auf anderem Wege in die Unit
           hereingegeben werden (beispielsweise durch Verwendung von Socket-Aktivierung mit
           Socket-Units, siehe systemd.socket(5)) sind davon nicht betroffen. Auch Sockets, die
           mit socketpair() (was nur verbundene AF_UNIX-Sockets erstellt) erstellt werden, sind
           nicht betroffen. Beachten Sie, das diese Option keinen Effekt auf 32-Bit X86, S390,
           S390x, MIPS, MIPS-le, PPC, PPC-le, PPC64, PPC64-le hat und ignoriert wird
           (funktioniert aber auf anderen ABIs, einschließlich x86-64, korrekt). 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.
           Standardmäßig werden keine Einschränkungen angewandt, Prozesse können auf alle
           Adressfamilien zugreifen. Falls die leere Zeichenkette zugewiesen wird, werden alle
           vorherigen Änderungen der Einschränkung der Adressfamilie zurückgenommen. Diese
           Einstellung betrifft keine Befehle, denen »+« vorangestellt sind.

           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.

           Hinzugefügt in Version 211.

       RestrictFileSystems=
           Beschränkt die Menge der Dateisysteme, auf denen Prozesse dieser Unit Dateien öffnen
           können. Akzeptiert eine Doppelpunkt-getrennte Liste von Dateisystemnamen. Alle
           aufgeführten Dateisysteme werden für die Prozesse der Unit zugreifbar gemacht, Zugriff
           auf nicht aufgeführte Dateisysteme wird verboten (Erlaubnisliste). Falls das erste
           Zeichen der Liste »-« ist, wird die Auswirkung invertiert: Zugriff auf die
           aufgeführten Dateisystem wird verboten (Ausschlussliste). Falls die leere Zeichenkette
           zugewiesen wird, wird der Zugriff auf Dateisysteme nicht beschränkt.

           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
           ┌──────────────────┬──────────────────────────────────┐
           │GruppeBeschreibung                     │
           ├──────────────────┼──────────────────────────────────┤
           │@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.

           Diese Option kann nicht durch Voranstellen von »+« vor den Ausführungspfad in der
           Dienste-Unit umgangen werden, da sie für die gesamte Control-Gruppe gilt.

           Hinzugefügt in Version 250.

       RestrictNamespaces=
           Begrenzt Zugriff auf die Linux-Namensraumfunktionalität für die Prozesse dieser Unit.
           Für Details über Linux-Namensräume siehe namespaces(7). Akzeptiert entweder ein
           logisches Argument oder eine Leerraum-getrennte Liste von Namensraumtypkennzeichnern.
           Falls falsch (die Vorgabe), erfolgen keine Beschränkungen bezüglich
           Namensraumerstellung und -umschaltung. Andernfalls muss eine Leerzeichen-getrennte
           Liste von Namensraumtypkennzeichnern festgelegt werden, die aus einer Kombination von
           cgroup, ipc, net, mnt, pid, user und uts bestehen. Jeder aufgeführte Namensraumtyp
           wird den Prozessen der Unit zugreifbar gemacht, Zugriff auf nicht aufgeführte
           Namensräume sind verboten (Freigabeliste). Durch Voranstellen des Tilde-Zeichens (»~«)
           kann der Effekt invertiert werden: nur die aufgeführten Namensraumtypen werden nicht
           zugreifbar gemacht, alle nicht aufgeführten sind erlaubt (Verbotsliste). Falls die
           leere Zeichenkette zugewiesen wird, werden die Vorgabe-Namensraumeinschränkungen
           angewandt, was zu falsch äquivalent ist. Diese Option kann mehr als einmal auftauchen.
           In diesem Fall werden die Namensraumtypen mit ODER (oder mit UND, falls den Zeilen »~«
           vorangestellt wird) zusammengefasst (siehe nachfolgende Beispiele). Intern begrenzt
           diese Einstellung Zugriff auf die Systemaufrufe unshare(2), clone(2) und setns(2) und
           berücksichtigt dabei die festgelegten Schalterparameter. Beachten Sie, dass bei
           Verwendung dieser Option zusätzlich zur Begrenzung der Erstellung und Umschaltung der
           festgelegten Namensraumtypen (oder allen von ihnen, falls wahr) Zugriff auf den
           Systemaufruf setns() mit einem Nullschalterparameter verboten ist. Diese Einstellung
           wird nur auf X86, X86-64, MIPS, MIPS-le, MIPS64, MIPS64-le, MIPS64-n32, MIPS64-le-n32,
           PPC64, PPC64-le, S390 und S390x unterstützt und erwirkt auf anderen Architekturen
           keine Einschränkungen.

           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.

           Hinzugefügt in Version 233.

       LockPersonality=
           Akzeptiert ein logisches Argument. Falls gesetzt, sperrt es den Systemaufruf
           personality(2), so dass die Kernel-Ausführungsdomäne nicht mehr von der Vorgabe oder
           von der mit der Anweisung Personality= ausgewählten Personalität geändert werden kann.
           Dies kann zur Verbesserung der Sicherheit nützlich sein, da merkwürdige
           Personalitätsemulationen schlecht getestet und eine Quelle von Schwachstellen sein
           können.

           Hinzugefügt in Version 235.

       MemoryDenyWriteExecute=
           Akzeptiert ein logisches Argument. Falls gesetzt, werden Versuche, Speicher-Mappings
           zu erstellen, die gleichzeitig schreib- und ausführbar sind oder bestehende
           Speicher-Mappings zu ändern, dass sie ausführbar werden oder gemeinsame
           Speichersegmente als ausführbar zu mappen, verboten. Insbesondere wird ein
           Systemaufruffilter hinzugefügt (oder, bevorzugt, wird eine äquivalente
           Kernelüberprüfung mittels prctl(2) aktiviert), der mmap(2)-Systemaufrufe mit sowohl
           gesetztem PROT_EXEC als auch gesetztem PROT_WRITE, mprotect(2)- oder
           pkey_mprotect(2)-Systemaufrufe mit gesetztem PROT_EXEC und shmat(2)-Systemaufrufe mit
           gesetztem SHM_EXEC zurückgewiesen. Beachten Sie, dass diese Option mit Programmen und
           Bibliotheken, die Code dynamisch zur Laufzeit erstellen, inkompatibel ist. Zu dieser
           Gruppe gehören JIT-Ausführungsmaschinen, ausführbare Stacks und
           Code-»Trampolin«-Funktionalitäten verschiedener C-Compiler. Diese Option verbessert
           die Sicherheit, da es Software-Exploits erschwert, dynamisch laufenden Code zu ändern.
           Allerdings kann der Schutz umgangen werden, falls der Dienst in ein Dateisystem
           schreiben kann, das nicht mit der Option noexec eingehängt ist (wie /dev/shm) oder er
           memfd_create() verwenden kann. Dies kann verhindert werden, indem solche Dateisysteme
           für den Dienst unzugreifbar gemacht (z.B. InaccessiblePaths=/dev/shm) und weitere
           Systemaufruffilter (SystemCallFilter=~memfd_create) installiert werden. Beachten Sie,
           dass diese Funktionalität komplett auf X86-64 und teilweise auf X86 verfügbar ist.
           Insbesondere der shmat()-Schutz ist auf X86 nicht verfügbar. Beachten Sie, dass auf
           Systemen, die mehrere ABIs unterstützen (wie X86/X84-64), es empfohlen wird,
           alternative ABIs für Dienste auszuschalten, so dass diese nicht zur Umgehung der
           Einschränkungen durch diese Option verwandt werden können. Insbesondere wird
           empfohlen, diese Option mit SystemCallArchitectures=native oder ähnlichem zu
           kombinieren.

           Hinzugefügt in Version 231.

       RestrictRealtime=
           Akzeptiert ein logisches Argument. Falls gesetzt, werden alle Versuche,
           Echtzeit-Scheduling für einen Prozess der Unit zu aktivieren, abgelehnt. Damit wird
           Zugriff auf die Echtzeitprogramm-Scheduling-Richtlinien wie SCHED_FIFO, SCHED_RR oder
           SCHED_DEADLINE begrenzt. Siehe sched(7) für Details über diese Scheduling-Richtlinien.
           Echtzeit-Scheduling-Richtlinien können zur Monopolisierung von CPU-Zeit für längere
           Zeitperioden verwandt werden und können daher dazu verwandt werden, das System zu
           sperren oder anderweitige Diensteverweigerungssituationen auf dem System auszulösen.
           Es wird daher empfohlen, den Zugriff auf Echtzeit-Scheduling auf die wenigen
           Programme, die dies tatsächlich benötigen, zu begrenzen. Standardmäßig aus.

           Hinzugefügt in Version 231.

       RestrictSUIDSGID=
           Akzeptiert ein logisches Argument. Falls gesetzt, werden alle Versuche, die Bits
           »set-user-ID« (SUID) oder »set-group-ID« (SGID) auf Dateien oder Verzeichnissen zu
           setzen, verweigert (für Details über diese Bits siehe inode(7)). Da SUID/SGID ein
           Mechanismus zur Erhöhung der Rechte ist und Benutzern erlaubt, die Identität anderer
           Benutzer zu erlangen, wird empfohlen, die Erstellung von SUID/SGID-Dateien auf die
           wenigen Programme zu beschränken, die dies tatsächlich benötigen. Beachten Sie, dass
           dies die Markierung jeder Art von Dateisystemobjekt mit diesen Bits beschränkt,
           einschließlich regulärer Dateien und Verzeichnisse (auf denen das Bit SGID eine andere
           Bedeutung als bei Dateien hat, siehe Dokumentation). Diese Option ist impliziert,
           falls DynamicUser= aktiviert ist. Standardmäßig »off«.

           Hinzugefügt in Version 242.

       RemoveIPC=
           Akzeptiert ein logisches Argument. Falls gesetzt, werden alle System-V- und
           POSIX-IPC-Objekte, die dem Benutzer und der Gruppe, unter der diese Unit läuft,
           gehören, entfernt, wenn die Unit gestoppt wird. Diese Einstellung hat nur einen
           Effekt, falls eines aus User=, Group= oder DynamicUser= verwandt wird. Es hat keinen
           Effekt für IPC-Objekte, die dem Benutzer »root« gehören. Insbesondere entfernt dies
           System-V-Semaphoren sowie gemeinsam benutzte Segmente und Nachrichten-Warteschlangen
           gemäß System V und POSIX. Falls mehrere Units die gleichen Benutzer oder Gruppen
           verwenden, werden die IPC-Objekte entfernt, wenn die letzte dieser Units gestoppt
           wird. Diese Einstellung ist impliziert, falls DynamicUser= gesetzt ist.

           Diese Option ist nur für Systemdienste verfügbar und wird nicht für Dienste, die in
           benutzerbezogenene Instanzen des Diensteverwalters laufen, unterstützt.

           Hinzugefügt in Version 232.

       PrivateMounts=
           Akzeptiert einen logischen Parameter. Falls gesetzt, wird diese Unit in ihrem eigenen
           privaten Dateisystem (Einhänge-)Namensraum betrieben, wobei alle Einhängeausbreitungen
           von dem Prozess in Richtung des Hauptdateisystems des Rechners abgeschaltet sind. Dies
           bedeutet, dass alle vom Prozess etablierten oder entfernten Dateisystemeinhängepunkte
           für diese privat und nicht im Hauptsystem sichtbar sind. Allerdings werden
           Dateisystemeinhängepunkte, die auf dem System etabliert oder entfernt werden, sich zu
           den Prozessen der Unit ausbreiten. Siehe mount_namespaces(7) für Details bezüglich
           Dateisystemnamensräumen. Standardmäßig aus.

           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. In diesem Fall ist
           PrivateUsers= impliziert aktiviert (benötigt im Kernel mittels des Sysctl
           »kernel.unprivileged_userns_clone=« aktivierte Unterstützung für nicht privilegierten
           Benutzernamensraum).

           Hinzugefügt in Version 239.

       MountFlags=
           Akzeptiert eine Einhängeausbreitungseinstellung: shared, slave oder private, die
           steuert, ob Dateisystemeinhängepunkte, die für die Prozesse dieser Unit in dem
           Dateisystemnamensraum eingerichtet wurden, Einhängungen oder Aushängungen aus anderen
           Dateisystemnamensräumen empfangen oder ausbreiten. Siehe mount(2) für Details über
           Einhängeausbreitungen und insbesondere die drei Ausbreitungsschalter.

           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. In diesem Fall ist
           PrivateUsers= impliziert aktiviert (benötigt im Kernel mittels des Sysctl
           »kernel.unprivileged_userns_clone=« aktivierte Unterstützung für nicht privilegierten
           Benutzernamensraum).

SYSTEMAUFRUFFILTERUNG

       SystemCallFilter=
           Akzeptiert eine Leerzeichen-getrennte Liste von Systemaufrufenamen. Falls diese
           Einstellung verwandt wird, werden alle Systemaufrufe, die durch die Prozesse der Unit
           ausgeführt werden, zu sofortiger Beendigung mit dem Signal SIGSYS führen, falls sie
           nicht aufgeführt sind (Freigabeliste). (Siehe SystemCallErrorNumber= zur Änderung der
           Standardaktion). Falls das erste Zeichen der Liste »~« ist, wird die Wirkung
           invertiert: nur die aufgeführten Systemaufrufe führen zu einer sofortigen
           Prozessbeendigung (Verbotsliste). Freigegebenen Systemaufrufen und Systemaufrufgruppen
           kann optional ein Doppelpunkt (»:«) und »errno«-Fehlernummern (zwischen 0 und 4095)
           oder Fehlernummernamen wie EPERM, EACCES oder EUCLEAN (siehe errno(3) für eine
           komplette Liste) angehängt werden. Dieser Wert wird zurückgeliefert, wenn ein
           verbotener Systemaufruf ausgelöst wird, statt den Prozess sofort zu beenden. Die
           besondere Einstellung »kill« kann zur expliziten Angabe des Tötens verwandt werden.
           Dieser Wert hat vor dem in SystemCallErrorNumber= angegebenen Vorrang, siehe unten.
           Diese Funktionalität verwendet die Schnittstelle »Secure Computing Mode 2« des Kernels
           (»Seccomp-Filterung«) und ist nützlich, um eine minimale Sandboxing-Umgebung zu
           erzwingen. Beachten Sie, dass die Systemaufrufe execve(), exit(), exit_group(),
           getrlimit(), rt_sigreturn(), sigreturn() und die Systemaufrufe zur Abfrage der Zeit
           und zum Schlafen implizit auf der Freigabeliste sind und nicht explizit aufgelistet
           werden müssen. Diese Option kann mehr als einmal angegeben werden, die Filtermasken
           werden in diesem Fall zusammengeführt. Falls die leere Zeichenkette zugewiesen wird,
           wird der Filter zurückgesetzt und alle vorherigen Zuweisungen haben keine Wirkung.
           Diese betrifft Befehle, denen »+« vorangestellt ist, nicht.

           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
           ┌────────────────┬──────────────────────────────────┐
           │GruppeBeschreibung                     │
           ├────────────────┼──────────────────────────────────┤
           │@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), …)   │
           ├────────────────┼──────────────────────────────────┤
           │@pkey           │ Systemaufrufe, die sich um       │
           │                │ Speicherschutzschlüssel          │
           │                │ (pkeys(7)) kümmern               │
           ├────────────────┼──────────────────────────────────┤
           │@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),   │
           │                │ …)                               │
           ├────────────────┼──────────────────────────────────┤
           │@sandbox        │ Systemaufrufe für                │
           │                │ sandboxed-Programme (seccomp(2), │
           │                │ Landlock-Systemaufrufe, …)       │
           ├────────────────┼──────────────────────────────────┤
           │@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=.

           Hinzugefügt in Version 187.

       SystemCallErrorNumber=
           Akzeptiert eine »errno«-Fehlernummer (zwischen 1 und 4095) oder einen Errno-Namen wie
           EPERM, EACCES oder EUCLEAN, der zurückgeliefert werden soll, wenn der mit
           SystemCallFilter= konfigurierte Systemaufruffilter ausgelöst wird, statt den Prozess
           sofort zu beenden. Siehe errno(3) für eine vollständige Liste der Fehlercodes. Wenn
           diese Einstellung nicht benutzt wird, oder wenn ihm die leere Zeichenkette oder die
           besondere Einstellung »kill« zugewiesen wird, wird der Prozess sofort beendet, wenn
           der Filter ausgelöst wird.

           Hinzugefügt in Version 209.

       SystemCallArchitectures=
           Akzeptiert eine Leerzeichen-getrennte Liste von Architekturkennungen, die in den
           Systemaufrufilter einbezogen werden sollen. Die bekannten Architekturkennungen sind
           die gleichen wie für das in systemd.unit(5) beschriebene ConditionArchitecture=, sowie
           x32, mips64-n32, mips64-le-n32 und die besondere Kennung native. Die besondere Kennung
           native wird implizit auf die native Architektur des Systems abgebildet (oder genauer:
           auf die Architektur, für die der Systemverwalter kompiliert wurde). Standardmäßig wird
           diese Option auf die leere Liste gesetzt, d.h. keine Filterung erfolgt.

           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.

           Hinzugefügt in Version 209.

       SystemCallLog=
           Akzeptiert eine Leerzeichen-getrennte Liste von Systemaufrufenamen. Falls diese
           Einstellung verwandt wird, werden alle aufgeführten Systemaufrufe, die durch die
           Prozesse der Unit ausgeführt werden, protokolliert. Falls das erste Zeichen der Liste
           »~« ist, wird die Wirkung invertiert: alle außer den aufgeführten Systemaufrufen
           werden protokolliert. Diese Funktionalität verwendet die Schnittstelle »Secure
           Computing Mode 2« des Kernels (»Seccomp-Filterung«) und ist nützlich, um die
           Sandboxing-Umgebung zu auditieren oder einzurichten. Diese Option kann mehr als einmal
           angegeben werden, die Filtermasken werden in diesem Fall zusammengeführt. Falls die
           leere Zeichenkette zugewiesen wird, wird der Filter zurückgesetzt und alle vorherigen
           Zuweisungen haben keine Wirkung. Diese betrifft Befehle, denen »+« vorangestellt ist,
           nicht.

           Hinzugefügt in Version 247.

UMGEBUNGSVARIABLEN

       Environment=
           Setzt Umgebungsvariablen für ausgeführte Prozesse. Bei jeder Zeile wird der Schutz
           gemäß der im Abschnitt »Schützen« in systemd.syntax(7) beschriebenen Regeln aufgehoben
           und wird dadurch eine Liste von Variablenzuweisungen. Falls Sie einer Variable einen
           Wert zuweisen müssen, der Leer- oder Gleichheitszeichen enthält, umschließen Sie die
           gesamte Zuweisung mit englischen Anführungszeichen. Innerhalb der Zeichenketten
           erfolgt keine Variablenexpandierung und das Zeichen »$« hat keine besondere Bedeutung.
           Kennzeichnerexpandierung wird durchgeführt, siehe den Abschnitt »Kennzeichner« in
           systemd.unit(5).

           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=
           Ähnlich zu Environment=, liest aber die Umgebungsvariablen aus einer Textdatei. Die
           Textdatei sollte durch Zeilenumbrüche getrennte Variablenzuweisungen enthalten. Leere
           Zeilen, Zeilen ohne einen »=«-Trenner und Zeilen, die mit »;« oder »#« beginnen,
           werden ignoriert. Letzteres kann zur Kommentierung verwandt werden. Die Datei muss in
           UTF-8 kodiert sein. Gültige Werte sind Unicode Skalarwerte[8] außer
           Unicode-Nichtzeichen[9], U+0000 NUL und U+FEFF
           Unicode-Byte-Reihenfolge-Markierung[10]. Steuerzeichen außer NUL sind erlaubt.

           In der Datei wird ein Wert nach dem »=« außerhalb von Anführungszeichen mit den
           gleichen Rückwärts-Schrägstrich-Regeln wie POSIX-Shell-Text ohne Anführungszeichen[11]
           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
           POSIX-Shell-Text in einfachen Anführungszeichen[12]. 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 POSIX-Shell-Text in doppelten englischen
           Anführungszeichen[13] 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=
           Übergibt für den Diensteverwalter gesetzte Umgebungsvariablen an ausgeführte Prozesse.
           Akzeptiert eine Leerzeichen-getrennte Liste von Variablennamen. Diese Option kann mehr
           als einmal angegeben werden, dann werden alle aufgeführten Variablen übergeben. Falls
           dieser Option die leere Zeichenkette zugewiesen wird, wird die Liste der zu
           übergebenden Umgebungsvariablen zurückgesetzt, alle vorherigen Zuweisungen haben keine
           Wirkung. Festgelegte Variablen, die für den Systemverwalter nicht gesetzt sind, werden
           nicht übergeben und werden ohne Rückmeldung ignoriert. Beachten Sie, dass diese Option
           nur für den Systemdiensteverwalter relevant ist, da Systemdienste standardmäßig keine
           Umgebungsvariablen, die für den Diensteverwalter gesetzt sind, erben. Im Falle des
           Benutzerdiensteverwalters werden alle Umgebungsvariablen sowieso an den ausgeführten
           Prozess übergeben, daher hat diese Option für Benutzerdiensteverwalter keine Wirkung.

           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.

           Hinzugefügt in Version 228.

       UnsetEnvironment=
           Setzt die Variablenzuweisungen, die normalerweise von dem Diensteverwalter an den
           aufgerufenen Prozess dieser Unit weitergegeben würden, zurück. Akzeptiert eine
           Lerraum-getrennte Liste von Variablennamen oder Variablenzuweisungen. Diese Option
           kann mehr als einmal angegeben werden, dann werden alle aufgeführten
           Variablen/Zuweisungen zurückgesetzt. Falls der Option die leere Zeichenkette
           zugewiesen wird, wird die Liste der Umgebungsvariablen/Zuweisungen, die zurückgesetzt
           werden sollen, zurückgesetzt. Falls eine Variablenzuweisung festgelegt ist (das heißt:
           einem Variablennamen, dem ein »=« und sein Wert folgt), dann wird jede
           Umgebungsvariable, die exakt auf diese Zuweisung passt, entfernt. Falls ein
           Variablennname festgelegt ist (das ist ein Variablenname, dem kein »=« oder ein Wert
           folgt), dann wird jede Zuweisung, die auf diesen Variablennamen passt, entfernt,
           unabhängig von dessen Wert. Beachten Sie, dass die Wirkung von UnsetEnvironment= als
           abschließender Schritt angewandt wird, wenn die an den auszuführenden Prozess zu
           übergebende Umgebungsliste zusammengestellt wird. Das bedeutet, dass es Zuweisungen
           von jeder Konfigurationsquelle rückgängig machen könnte, einschließlich Zuweisungen,
           die mittels Environment= oder EnvironmentFile= erfolgten, die von der globalen Menge
           der Umgebungsvariablen des Systemverwalters geerbt wurden, die vom Diensteverwalter
           selbst gesetzt wurden (wie $NOTIFY_SOCKET und ähnliche) oder die durch ein PAM-Modul
           gesetzt wurden (falls PAMName= benutzt wird).

           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.

           Hinzugefügt in Version 235.

PROTOKOLLIERUNG UND STANDARD-EIN-/-AUSGABE

       StandardInput=
           Steuert, womit der Dateideskriptor 0 (STDIN) des ausgeführten Prozesses verbunden ist.
           Akzeptiert null, tty, tty-force, tty-fail, data, file:Pfad, socket oder fd:Name.

           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
           (Umgebungsvariablen $LISTEN_FDS (und verwandte) werden nicht weitergegeben, wenn der
           Wert socket konfiguriert ist).

           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=
           Steuert, womit der Dateideskriptor 1 (Stdout) des ausgeführten Prozesses verbunden
           ist. Akzeptiert entweder inherit, null, tty, journal, kmsg, journal+console,
           kmsg+console, file:Pfad, append:Pfad, truncate:Pfad, socket oder fd:Name.

           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 Nullbytes (NUL)
           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.

           Falls StandardInput= auf entweder tty, tty-force, tty-fail, socket oder fd:Name
           gesetzt ist, die die Vorgabe für diese Einstellung inherit.

           In anderen Fällen ist der Vorgabewert dieser Einstellung 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=
           Steuert, womit Dateideskriptor 2 (Stderr) des ausgeführten Prozesses verbunden ist.
           Die verfügbaren Optionen sind identisch zu denen von StandardOutput= mit einigen
           Ausnahmen: falls auf inherit gesetzt, wird der für die Standardausgabe verwandte
           Dateideskriptor für die Standardfehlerausgabe dupliziert, während fd:Name den
           vorgegebenen Dateideskriptornamen von »stderr« verwenden wird.

           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=
           Konfiguriert beliebige textuelle oder binäre Daten, die mittels Dateideskriptor 0
           (STDIN) an den ausgeführten Prozess übergeben werden sollen. Diese Einstellung hat
           keine Wirkung, außer StandardInput= ist auf data gesetzt (dies ist die Vorgabe, falls
           StandardInput= nicht anderweitig gesetzt ist, aber
           StandardInputText=/StandardInputData= verwandt wird). Verwenden Sie diese Option, um
           Prozesseingabedaten direkt in die Unit-Datei einzubetten.

           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[14] 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
               …

           Hinzugefügt in Version 236.

       LogLevelMax=
           Konfiguriert eine Filterung gemäß Protokollierstufe der durch diese Unit erstellten
           Protokollnachrichten. Akzeptiert eine syslog-Protokollstufe, entweder emerg
           (niedrigste Protokollierstufe, nur Nachrichten höchster Priorität), alert, crit, err,
           warning, notice, info oder debug (höchste Protokollierstufe, auch Nachrichten
           niedrigster Priorität). Siehe syslog(3) für Details. Standardmäßig wird keine
           Filterung angewandt (d.h. die maximale Protokollierstufe ist standardmäßig debug).
           Verwenden Sie diese Option, um das Protokolliersystem zu konfigurieren, damit es
           Protokollnachrichten eines bestimmten Dienstes oberhalb der festgelegten Stufe
           verwirft. Setzen Sie beispielsweise LogLevelMax=info, um die Fehlersuchprotokollierung
           eines bestimmten, gesprächigen Dienstes auszuschalten. Beachten Sie, dass die
           konfigurierte Stufe auf alle versandten Protokollnachrichten aller zu diesem Dienst
           gehörenden Prozesse sowie allen vom Systemverwalterprozess (PID 1) geschriebenen
           Protokollnachrichten mit Referenz auf diese Unit auf allen unterstützten
           Protokollierungsprotokollen angewandt wird. Die Filterung erfolgt frühzeitig in der
           Protokollierungspipeline, bevor jegliche Art weiterer Verarbeitung erfolgt.
           Desweiteren könnten Nachrichten, die erfolgreich durch diesen Filter kommen, dennoch
           durch angewandte Filter in einer späteren Stufe im Protokollierungsuntersystem
           verworfen werden. Beispielsweise könnte ein in journald.conf(5) konfiguriertes
           MaxLevelStore= verbieten, Nachrichten von höheren Protokollierstufen auf Platte zu
           speichen, selbst wenn das Unit-bezogene LogLevelMax= die Verarbeitung erlaubte.

           Hinzugefügt in Version 236.

       LogExtraFields=
           Konfiguriert zusätzliche Protokollmetadatenfelder, die in alle Protokolldatensätze
           aufgenommen werden, die von Prozessen, die dieser Unit zugeordnet sind (einschließlich
           Systemd), erstellt werden. Diese Einstellung akzeptiert eine oder mehrere
           Journal-Feldzuweisungen im Format »FELD=WERT«, getrennt durch Leerraumzeichen. Siehe
           systemd.journal-fields(7) für Details zum Journal-Feldkonzept. Obwohl die
           zugrundeliegende Journal-Implementierung binäre Feldnamen erlaubt, akzeptiert diese
           Einstellung nur gültige UTF-8-Werte. Um Leerzeichen in einem Journal-Feldwert
           aufzunehmen, schließen Sie die Zuweisung in doppelte Anführungszeichen (") ein. Die
           normalen Kennzeichner werden in allen Zuweisungen expandiert (siehe unten). Beachten
           Sie, dass diese Einstellung nicht nur für das Anhängen von zusätzlichen Metadaten an
           Protokolldatensätzen einer Unit nützlich ist. Da alle Felder und Werte indiziert sind,
           kann dies auch für Unit-übergreifenden Protokolldatensatzabgleich verwandt werden.
           Wird eine leere Zeichenkette zugewiesen, wird die Liste zurückgesetzt.

           Hinzugefügt in Version 236.

       LogRateLimitIntervalSec=, LogRateLimitBurst=
           Konfiguriert die Ratenbegrenzung, die auf von dieser Unit erstellte
           Protokollnachrichten angewandt wird. Falls in dem durch LogRateLimitIntervalSec=
           definierten Intervall mehr als in LogRateLimitBurst= festgelegte Nachrichten durch den
           Dienst protokolliert werden, werden alle weiteren Nachrichten in dem Intervall
           verworfen, bis das Intervall vorüber ist. Es wird eine Meldung über die verworfenen
           Nachrichten erstellt. Die Zeitspezifikation für LogRateLimitIntervalSec= kann in einer
           der folgenden Einheiten erfolgen: »s«, »min«, »h«, »ms«, »us«. Siehe systemd.time(7)
           für Details. Die Voreinstellungen erfolgen durch die in journald.conf(5)
           konfigurierten RateLimitIntervalSec= und RateLimitBurst=. Beachten Sie, dass das nur
           auf Protokollnachrichten angewandt wird, die vom Protokollsubsystem verarbeitet
           werden, d.h. durch systemd-journald.service(8). Das bedeutet, dass die Ratenbegrenzung
           nicht angewandt werden, falls Sie Stderr eines Dienstes über StandardOutput=file:…
           oder einer ähnlichen Einstellung direkt mit einer Datei verbinden (aber sie wird für
           mittels syslog(3) oder ähnlichen Funktionen erstellten Meldungen durchgesetzt).

           Hinzugefügt in Version 240.

       LogFilterPatterns=
           Definiert einen erweiterten regulären Ausdruck, um Protokollmeldungen basierend auf
           dem Feld MESSAGE= der strukturierten Nachricht zu filtern. Falls das erste Zeichen des
           Musters »~« ist, sollen Protokollnachrichten, die auf das Muster passen, verworfen
           werden. Diese Option akzeptiert ein einzelnes Muster als Argument, kann aber mehrfach
           verwandt werden, um eine Liste der erlaubten und verbotenen Muster zu erstellen. Falls
           die leere Zeichenkette zugewiesen wird, wird der Filter zurückgesetzt und alle
           vorherigen Zuweisungen haben keine Auswirkung.

           Da das Zeichen »~« zur Definition von Verbotsmuster verwandt wird, muss es durch
           »\x7e« ersetzt werden, um Nachrichten zu erlauben, die mit »~« beginnen.
           Beispielsweise würde »~foobar« ein Muster hinzufügen, das »foobar« zu der Verbotsliste
           hinzufügt, während »\x7efoobar« ein Muster, das auf »~foobar« passt, zu der
           Erlaubt-Liste hinzufügt.

           Protokollmeldungen werden gegen Verbotsmuster geprüft (falls vorhanden), dann gegen
           Erlaubt-Muster (falls vorhanden). Falls eine Protokollmeldung auf eines der
           Verbotsmuster passst, wird sie verworfen, unabhängig von den Erlaubt-Mustern. Dann
           werden die verbliebenen Protokollmeldungen gegen die Erlaubt-Muster geprüft.
           Meldungen, die auf keines der Erlaubt-Muster passen, werden verworfen. Falls keine
           Erlaubt-Muster definiert sind, dann werden alle Meldungen direkt verarbeitet, nachdem
           sie durch die Verbotsfilter gelaufen sind.

           Filterung basiert auf der Unit, für die LogFilterPatterns= definiert ist. Das
           bedeutet, dass von systemd(1) stammende Protokollmeldungen über die Unit nicht
           berücksichtigt werden. Gefilterte Protokollmeldungen werden nicht zu traditionellen
           Syslog-Daemons, dem Kernelprotokollpuffer (kmsg), der Systemd-Konsole weitergeleitet
           oder als Wall-Meldungen an alle angemeldeten Benutzer gesandt.

           Hinzugefügt in Version 253.

       LogNamespace=
           Führt die Prozesse der Unit in dem angegebenen Journal-Namensraum aus. Erwartet eine
           kurze, benutzerdefinierte Zeichenkette, die den Namensraum kennzeichnet. Falls nicht
           verwandt, werden die Prozesse des Dienstes im Vorgabe-Journal-Namensraum ausgeführt,
           d.h. ihr Protokolldatenstrom wird durch systemd-journald.service gesammelt und
           verarbeitet. Falls diese Option verwandt wird, werden sämtliche von Prozessen dieser
           Unit erstellte Protokolldaten (unabhängig, ob diese mittels syslog(), nativer
           Journal-Protokollierung oder Stdout/Stderr-Protokollierung erfolgen) durch eine
           Instanz der Vorlagen-Unit systemd-journald@.service gesammelt und verarbeitet, die den
           festgelegten Namensraum verwaltet. Die Protokolldaten werden ein einem Datenspeicher
           gelagert, der unabhängig vom Datenspeicher des Vorgabe-Protokoll-Namensraums ist.
           Siehe systemd-journald.service(8) für Details über Journal-Namensräume.

           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 oben beschriebene Einstellungen 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.

           Hinzugefügt in Version 245.

       SyslogIdentifier=
           Setzt den Prozessnamen (»syslog-Markierung«), der allen an das Protokollierungssystem
           oder den Kernelpuffer gesandten langen Zeilen vorangestellt werden soll. Falls nicht
           gesetzt, ist die Vorgabe der Prozessname des ausgeführten Prozesses. Diese Option ist
           nur nützlich, wenn StandardOutput= oder StandardError= auf journal oder kmsg gesetzt
           ist (oder die gleichen Einstellungen in Kombination mit +console). Sie wird nur auf
           Protokollnachrichten, die nach Stdout oder Stderr geschrieben werden, angewandt.

       SyslogFacility=
           Setzt den syslog-Einrichtungskennzeichner, der beim Protokollieren verwandt werden
           soll. Entweder kern, user, mail, daemon, auth, syslog, lpr, news, uucp, cron,
           authpriv, ftp, local0, local1, local2, local3, local4, local5, local6 oder local7.
           Siehe syslog(3) für Details. Diese Option ist nur nützlich, wenn StandardOutput= oder
           StandardError= auf journal oder kmsg gesetzt ist (oder die gleichen Einstellungen in
           Kombination mit +console). Sie wird nur auf Protokollnachrichten, die nach Stdout oder
           Stderr geschrieben werden, angewandt. Standardmäßig daemon.

       SyslogLevel=
           Die Vorgabe-syslog-Protokollierstufe, die beim Protokollieren zum
           Protokollierungssystem oder Kernelprotokollpuffer verwandt werden soll. Entweder
           emerg, alert, crit, err, warning, notice, info oder debug. Siehe syslog(3) für
           Details. Diese Option ist nur nützlich, wenn StandardOutput= oder StandardError= auf
           journal oder kmsg gesetzt ist (oder die gleichen Einstellungen in Kombination mit
           +console). Sie wird nur auf Protokollnachrichten, die nach Stdout oder Stderr
           geschrieben werden, angewandt. Beachten Sie, dass individuellen Zeilen, die von
           ausgeführten Prozessen ausgegeben werden, eine andere Protokollierungsstufe
           vorangestellt werden kann, die dazu verwandt werden kann, die hier festgelegte
           Vorgabeprotokollstufe außer Kraft zu setzen. Die Auswertung dieser vorangestellten
           Werte kann mit SyslogLevelPrefix= deaktiviert werden, siehe unten. Für Details siehe
           sd-daemon(3). Standardmäßig info.

       SyslogLevelPrefix=
           Akzeptiert ein logisches Argument. Falls wahr und StandardOutput= oder StandardError=
           auf journal oder kmsg gesetzt ist (oder die gleichen Einstellungen in Kombination mit
           +console), wird Protokollzeilen, die durch die ausgeführten Prozesse geschrieben
           werden, denen eine Protokollierungsstufe vorangestellt ist, verarbeitet, wobei die
           vorangestellte Protokollierungsstufe entfernt wird. Falls auf falsch gesetzt, wird die
           Auswertung dieser vorangestellten Werte deaktiviert und die protokollierten Zeilen
           unverändert weitergegeben. Dies gilt nur für Protokollnachrichten, die nach Stdout
           oder Stderr geschrieben werden. Für Details bezüglich des Voranstellens siehe
           sd-daemon(3). Standardmäßig wahr.

       TTYPath=
           Setzt den zu verwendenden Terminalgeräteknoten, falls die Standardeingabe, -ausgabe
           oder -fehlerausgabe mit einem TTY verbunden ist (siehe oben). Standardmäßig
           /dev/console.

       TTYReset=
           Setzt das mit TTYPath= festgelegte Terminalgerät vor und nach der Ausführung zurück.
           Standardmäßig »no«.

       TTYVHangup=
           Trennt alle Clients, die das mit TTYPath= festgelegte Terminalgerät vor und nach der
           Ausführung geöffnet haben. Standardmäßig »no«.

       TTYRows=, TTYColumns=
           Konfiguriert die Größe des mit TTYPath= festgelegten TTYs. Falls nicht oder auf die
           leere Zeichenkette gesetzt, wird die Vorgabe des Kernels verwandt.

           Hinzugefügt in Version 250.

       TTYVTDisallocate=
           Falls das mit TTYPath= festgelegte Terminalgerät ein virtuelles Konsolenterminal ist,
           wird vor und nach der Ausführung versucht, die Zuordnung aufzuheben. Dies sorgt dafür,
           dass der Bildschirm und der Scrollback-Puffer (Puffer mit vorherigen Ein-/Ausgaben)
           gelöscht werden. Standardmäßig »no«.

ZUGANGSDATEN

       LoadCredential=KENNUNG[:PFAD], LoadCredentialEncrypted=KENNUNG[:PFAD]
           Übergibt ein Zugangsberechtigungsdatum an die Unit. Zugangsberechtigungsdaten sind
           binäre oder textuelle Objekte begrenzter Größe, die an Prozesse von Units übergeben
           werden können. Sie werden hauptsächlich zur Weitergabe kryptographischer Schlüssel
           (sowohl öffentlicher als auch privater) oder Zertifikaten, Benutzerkontoinformationen
           oder Identitätsinformationen vom Rechner an Dienste verwandt. Von den Prozessen der
           Unit kann auf diese Daten mittels des Dateisystems zugegriffen werden, an einem rein
           lesbaren Ort der (falls möglich und erlaubt) durch Speicher, der nicht ausgelagert
           werden darf, hinterlegt ist. Auf die Daten kann nur durch den Benutzer, der der Unit
           über die Einstellung User=/DynamicUser= zugeordnet ist, zugegriffen werden (sowie dem
           Systemverwalter). Wenn verfügbar, wird der Ort der Zugangsberechtigungsdaten in der
           Umgebungsvariable $CREDENTIALS_DIRECTORY für die Prozesse der Unit exportiert.

           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 Nullbytes (NUL).

           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. Wenn DevicePolicy= auf
           »closed« oder »strict« gesetzt ist oder wenn sie auf »auto« gesetzt und DeviceAllow=
           gesetzt ist oder wenn PrivateDevices= gesetzt ist, dann fügt diese Einstellung
           /dev/tpmrm0 mit dem Modus rw zu DeviceAllow= hinzu. Siehe systemd.resource-control(5)
           für Details über DevicePolicy= oder DeviceAllow=.

           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«. Für Systemdienste kann der Pfad
           auch als »/run/credentials/UNITNAME« referenziert werden, wenn keine Interpolation
           möglich ist, d.h. die Konfigurationsdateien der Software Zugangsberechtigungen noch
           nicht nativ unterstützen. $CREDENTIALS_DIRECTORY wird allerdings als die
           Hauptschnittstelle zur Suche nach Zugangsberechtigungen betrachtet, da es auch für
           Benutzerdienste funktioniert.

           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[15] zu Dokumentation zu
           Ersterem. Für Zweiteres, übergeben Sie DMI/SMBIOS[16]
           OEM-Zeichenketten-Tabelleneinträge (Feldtyp 11) mit einem Präfix
           »io.systemd.credential:« oder »io.systemd.credential.binary:«. In beiden Fällen wird
           ein durch »=« getrenntes Schlüssel-Wert-Paar erwartet, in letzterem Fall ist die
           rechte Seite mit Base64 kodiert, wenn sie ausgewertet wird (womit die Hereingabe von
           binären Daten ermöglicht wird). Der Schalter für qemu[17] lautet beispielsweise
           »-smbios type=11,value=io.systemd.credential:xx=yy« oder »-smbios
           type=11,value=io.systemd.credential.binary:rick=TmV2ZXIgR29ubmEgR2l2ZSBZb3UgVXA=«.
           Alternativ verwenden Sie den »fw_cfg«-Knoten »opt/io.systemd.credentials/« von
           qemu(1). Beispielhafter Schalter für Qemu: »-fw_cfg
           name=opt/io.systemd.credentials/mycred,string=supersecret«. Sie können auch von der
           UEFI-Firmware-Umgebung mittels systemd-stub(7), von der Initrd (siehe systemd(1)) oder
           auf der Kernelbefehlszeile mittels der Schalters »systemd.set_credential=« und
           »systemd.set_credential_binary=« (siehe systemd(1) – dies wird nicht empfohlen, da
           nicht privilegierter Benutzerraum die Kernelbefehlszeile lesen kann) 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 Nullbyte (NUL) (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[18] für weitere Informationen.

           Hinzugefügt in Version 247.

       ImportCredential=GLOB
           Übergibt eine oder mehrere Zugangsbereichtigungen an die Unit. Akzeptiert einen
           Zugangsberechtigungsnamen für den versucht wird, 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 der Zugangsberechtigungsname ein Glob ist, werden
           alle Zugangsberechtigungen, die auf diesen Glob passen, an die Unit übergeben. Es wird
           in den System-Zugangsberechtigungen, den verschlüsselten System-Zugangsberchtigungen
           und unter /etc/credstore/, /run/credstore/, /usr/lib/credstore/,
           /run/credstore.encrypted/, /etc/credstore.encrypted/ und /usr/lib/credstore.encrypted/
           in dieser Reihenfolge nach passenden Zugangsberechtigungen gesucht. Wenn mehrere
           Zugangsberechtigungen mit dem gleichen Namen gefunden werden, wird die erste gefundene
           verwandt.

           Der Globbing-Ausdruck implementiert eine einschränkende Teilmenge von glob(7): nur ein
           einzelner, abschließender »*«-Platzhalter darf festgelegt werden. Sowohl »?«- als auch
           »[]«-Platzhalter sind nicht erlaubt, genau wie »*«-Platzhalter, die niergendwo anders
           außer am Ende des Glob-Ausdrucks erlaubt sind.

           Wenn mehrere Zugangsberechtigungen mit gleichem Namen gefunden werden, haben durch
           LoadCredential= und LoadCredentialEncrypted= gefundene Zugangsberechtigungen Priorität
           gegenüber durch ImportCredential= gefundene Zugangsberechtigungen.

           Hinzugefügt in Version 254.

       SetCredential=KENNUNG:WERT, SetCredentialEncrypted=KENNUNG:WERT
           Die Einstellung SetCredential= ist ähnlich zu LoadCredential=, akzeptiert aber einen
           buchstäblichen Wert, der als Daten für die Zugangsberechtigungen verwandt werden soll,
           statt eines Dateisystempfades, aus dem die Daten gelesen werden sollen. Verwenden Sie
           diese Option nicht für Daten, die geheim gehalten werden sollen, da nicht
           privilegierte Benutzer darauf mittels IPC zugreifen können. Es ist nur sicher, dies
           für Benutzerkennungen, öffentliches Schlüsselmaterial und ähnliche, nicht sensiblen
           Daten zu verwenden. Verwenden Sie für alles andere LoadCredential=. Um binäre Daten in
           die Zugangsberechtigungsdaten einzubetten, verwenden Sie C-artige Maskierungen (d.h.
           »\n«, um einen Zeilenumbruch einzubetten oder »\x00«, um ein Nullbyte (NUL)
           einzubetten).

           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.

           Werden mehrere Zugangsberechtigungen mit dem gleichen Namen gefunden, haben mittels
           LoadCredential=, LoadCredentialEncrypted= und ImportCredential= gefundene
           Zugangsberechtigungen Priorität gegenüber mittels SetCredential= gefundene
           Zugangsberechtigungen. Somit agiert SetCredential= als Vorgabe, falls mittels der
           anderen keine Zugangsberchtigungen gefunden werden. In diesem Fall wird der
           Fehlschlag, die in LoadCredential= oder LoadCredentialEncrypted= festgelegte
           Zugangsberechtigung nicht abfragen zu können, nicht als fatal betrachtet.

           Hinzugefügt in Version 247.

SYSTEM V-KOMPATIBILITÄT

       UtmpIdentifier=
           Akzeptiert eine Kennzeichnungszeichenkette aus vier Zeichen für einen utmp(5)- und
           Wtmp-Eintrag für diesen Dienst. Dies sollte nur für Dienste wie
           getty-Implementierungen (wie agetty(8)) gesetzt werden, bei denen Utmp/Wtmp-Einträge
           erstellt und vor und nach der Ausführung bereinigt werden müssen oder für Dienste, die
           so ausgeführt werden sollen, als ob sie durch einen getty-Prozess ausgeführt würden
           (siehe unten). Falls die Konfigurationszeichenkette länger als vier Zeichen ist, wird
           sie gekürzt und die vier Zeichen am Ende werden verwandt. Diese Einstellung
           interpretiert %I-artige Zeichenkettenersetzungen. Diese Einstellung ist standardmäßig
           nicht gesetzt, d.h. dass für diesen Dienst keine Utmp-/Wtmp-Einträge erstellt oder
           bereinigt werden.

       UtmpMode=
           Akzeptiert entweder »init«, »login« oder »user«. Falls UtmpIdentifier= gesetzt ist,
           steuert dies die Art der für diesen Dienst erstellten utmp(5)/wtmp-Einträge. Diese
           Einstellung ist wirkungslos, außer UtmpIdentifier= ist auch gesetzt. Falls »init«
           gesetzt ist, wird nur ein INIT_PROCESS-Eintrag erstellt und der aufgerufene Prozess
           muss eine getty-kompatible Utmp/Wtmp-Logik implementieren. Falls »login« gesetzt ist,
           wird zuerst ein INIT_PROCESS-Eintrag, gefolgt von einem LOGIN_PROCESS-Eintrag
           erstellt. In diesem Fall muss der aufgerufene Prozess eine login(1)-kompatible
           Utmp/Wtmp-Logik implementieren. Falls »user« festgelegt ist, wird zuerst ein
           INIT_PROCESS-Eintrag, dann ein LOGIN_PROCESS-Eintrag und schließlich ein
           USER_PROCESS-Eintrag erstellt. In diesem Fall kann der Prozess jeder Prozess sein, der
           zum Betrieb als Sitzungsleiter geeignet ist. Standardmäßig »init«.

           Hinzugefügt in Version 225.

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:

       •   Variablen, die global für den Diensteverwalter mittels der Einstellung
           DefaultEnvironment= in systemd-system.conf(5), der Kernelbefehlszeilenoption
           systemd.setenv= von systemd(1) verstanden werden oder mittels des Unterbefehls
           set-environment von systemctl gesetzt werden.

       •   Durch den Diensteverwalter selbst definierte Variablen (siehe nachfolgende Liste).

       •   Variablen, die durch den Umgebungsvariablenblock des Diensteverwalters selbst gesetzt
           sind (abhängig von PassEnvironment= für den Systemdiensteverwalter).

       •   Mittels Environment= in der Unit-Datei gesetzte Variablen.

       •   Aus mit EnvironmentFile= in der Unit-Datei festgelegten Dateien gelesene Variablen.

       •   Falls PAMName= wirksam ist, siehe pam_env(8), durch alle PAM-Module gesetzte
           Variablen.

       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
           Doppelpunkt-getrennte Liste von Verzeichnissen, die beim Starten von Programmen
           verwandt werden. systemd verwendet einen festgelegten Wert von
           »/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin« im Systemverwalter. Im Falle des
           Benutzerverwalters kann durch die Distribution ein anderer Pfad konfiguriert sein. Es
           wird empfohlen, sich auf die Reihenfolge der Einträge nicht zu verlassen, und nur ein
           Programm mit einem vorgegebenen Namen in $PATH zu haben.

           Hinzugefügt in Version 208.

       $LANG
           Locale. Kann in locale.conf(5) oder auf der Kernelbefehlszeile gesetzt werden (siehe
           systemd(1) und kernel-command-line(7)).

           Hinzugefügt in Version 208.

       $USER, $LOGNAME, $HOME, $SHELL
           Benutzername (zweimal), Home-Verzeichnis und die Anmelde-Shell. $USER wird
           bedingungslos gesetzt, während $HOME, $LOGNAME und $SHELL nur für die Units gesetzt
           werden, die User= gesetzt und SetLoginEnvironment= nicht oder auf wahr gesetzt haben.
           Für Benutzerdienste werden diese Variablen typischerweise aus dem Verwalter selbst
           geerbt. Siehe passwd(5).

           Hinzugefügt in Version 208.

       $INVOCATION_ID
           Enthält eine zufällige, eindeutige, 128-Bit-Kennzeichnung, die jeden Laufzeitzyklus
           der Unit identifiziert. Sie ist als hexadezimale Zeichenkette mit 32 Zeichen
           formatiert. Jedes Mal, wenn die Unit sich vom inaktiven Zustand in einen aktivierenden
           oder aktiven Zustand ändert, wird eine neue Kennung zugewiesen. Sie kann zur
           Kennzeichnung dieses bestimmten Laufzeitzyklus verwandt werden, insbesondere in
           gespeicherten Daten wie dem Journal. Die gleiche Kennung wird an alle als Teil der
           Unit ausgeführten Prozesse übergeben.

           Hinzugefügt in Version 232.

       $XDG_RUNTIME_DIR
           Das Verzeichnis, das für Laufzeitobjekte (wie IPC-Objekte) und flüchtige Zustände
           verwandt werden soll. Wird für alle von der Benutzer-systemd-Instanz ausgeführten
           Prozesse sowie von allen Systemdiensten, die PAMName= mit einem PAM-Stack, der
           pam_systemd enthält, verwandt wird, gesetzt. Siehe unten und pam_systemd(8) für
           weitere Informationen.

           Hinzugefügt in Version 208.

       $RUNTIME_DIRECTORY, $STATE_DIRECTORY, $CACHE_DIRECTORY, $LOGS_DIRECTORY,
       $CONFIGURATION_DIRECTORY
           Absolute Pfade zu den in RuntimeDirectory=, StateDirectory=, CacheDirectory=,
           LogsDirectory= und ConfigurationDirectory= definierten Verzeichnissen, wenn diese
           Einstellungen verwandt werden.

           Hinzugefügt in Version 244.

       $CREDENTIALS_DIRECTORY
           Ein absoluter Pfad zu einem Unit-spezifischen Verzeichnis mit Zugangsberechtigungen,
           die mittels ImportCredential=/LoadCredential=/SetCredential= konfiguriert wurden. Das
           Verzeichnis ist als rein lesbar markiert und auf nicht auslagerbaren Speicher abgelegt
           (falls unterstützt und erlaubt) und kann nur von der UID aus zugegriffen werden, die
           der Unit via User= oder DynamicUser= zugeordnet ist (und dem Systemverwalter).

           Hinzugefügt in Version 247.

       $MAINPID
           Die PID des Hauptprozesses der Unit, falls bekannt. Dies wird nur für durch
           ExecReload= und Ähnliches aufgerufene Steuerprozesse gesetzt.

           Hinzugefügt in Version 209.

       $MANAGERPID
           Die PID der Benutzer-systemd-Instanz, gesetzt für davon erzeugte Prozesse.

           Hinzugefügt in Version 208.

       $LISTEN_FDS, $LISTEN_PID, $LISTEN_FDNAMES
           Informationen über Dateideskriptoren, die an einen Dienst für Socket-Aktivierung
           weitergegeben wurden. Siehe sd_listen_fds(3).

           Hinzugefügt in Version 208.

       $NOTIFY_SOCKET
           Das Socket, mit dem sd_notify() kommuniziert. Siehe sd_notify(3).

           Hinzugefügt in Version 229.

       $WATCHDOG_PID, $WATCHDOG_USEC
           Informationen über Watchdog-Aufrechterhaltungsbenachrichtigungen. Siehe
           sd_watchdog_enabled(3).

           Hinzugefügt in Version 229.

       $SYSTEMD_EXEC_PID
           Die PID des Unit-Prozesses (z.B. des durch ExecStart= aufgerufenen Prozesses). Der
           Kind-Prozess kann diese Informationen dazu verwenden, um zu ermitteln, ob der Prozess
           direkt vom Diensteverwalter oder indirekt als Kind eines anderen Prozesses erzeugt
           wurde, indem er diesen Wert mit der aktuellen PID vergleicht (ähnlich des von
           sd_listen_fds(3) mit $LISTEN_PID und $LISTEN_FDS verwandten Schemas).

           Hinzugefügt in Version 248.

       $TERM
           Terminaltyp, nur für mit einem Terminal verbundene Units gesetzt (StandardInput=tty,
           StandardOutput=tty oder StandardError=tty). Siehe termcap(5).

           Hinzugefügt in Version 209.

       $LOG_NAMESPACE
           Enthält den Namen des ausgewählten Protokollierungsnamensraums, wenn die Einstellung
           LogNamespace= verwandt wird.

           Hinzugefügt in Version 246.

       $JOURNAL_STREAM
           Falls die Standardausgabe oder Standardfehlerausgabe des ausgeführten Prozesses mit
           dem Journal verbunden ist (beispielsweise durch Setzen von StandardError=journal),
           enthält $JOURNAL_STREAM das Gerät und die Inode-Nummer des verbindenden
           Dateideskriptors, dezimal formatiert, getrennt durch einen Doppelpunkt (»:«). Dies
           erlaubt es aufgerufenen Prozessen, sicher zu überprüfen, ob ihre Standardausgabe oder
           Standardfehlerausgabe mit dem Journal verbunden sind. Das Gerät und die Inode-Nummer
           des Dateideskriptors sollte mit den in der Umgebungsvariable gesetzten Werten
           verglichen werden, um zu bestimmen, ob die Prozessausgabe immer noch mit dem Journal
           verbunden ist. Beachten Sie, dass es im Allgemeinen nicht ausreicht, zu prüfen, ob
           $JOURNAL_STREAM überhaupt gesetzt ist, da Dienste externe Prozesse aufrufen könnten,
           die ihre Standardausgabe oder Fehlerausgabe ersetzen könnten, ohne dabei die
           Umgebungsvariable zurückzusetzen.

           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.

           Hinzugefügt in Version 231.

       $SERVICE_RESULT
           Diese Variable, die nur für den Dienste-Unit-Typ verwandt wird, wird an alle
           ExecStop=- und ExecStopPost=-Prozesse weitergegeben und kodiert das »Ergebnis« des
           Prozesses. Derzeit sind die folgenden Werte definiert:

           Tabelle 5. Definierte $SERVICE_RESULT-Werte
           ┌──────────────────┬──────────────────────────────────┐
           │WertBedeutung                        │
           ├──────────────────┼──────────────────────────────────┤
           │"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.                        │
           ├──────────────────┼──────────────────────────────────┤
           │"exec-condition"  │ Service did not run because      │
           │                  │ ExecCondition= failed.           │
           ├──────────────────┼──────────────────────────────────┤
           │"oom-kill"        │ A service process was terminated │
           │                  │ by the Out-Of-Memory (OOM)       │
           │                  │ killer.                          │
           ├──────────────────┼──────────────────────────────────┤
           │"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.

           Hinzugefügt in Version 232.

       $EXIT_CODE, $EXIT_STATUS
           Diese Umgebungsvariablen, die nur für den Dienste-Unit-Typ definiert sind, werden an
           alle Prozesse aus ExecStop= und ExecStopPost= übergeben und enthalten
           Exit-Status/Code-Informationen über den Hauptprozess des Dienstes. Für die genaue
           Definition des Exit-Codes und -Status, siehe wait(2). $EXIT_CODE ist entweder
           »exited«, »killed« oder »dumped«. $EXIT_STATUS enthält den als Zeichenkette
           formatierten numerischen Exit-Code, falls $EXIT_CODE »exited« enthält und andernfalls
           den Signalnamen. Beachten Sie, dass diese Umgebungsvariablen nur gesetzt sind, falls
           es dem Diensteverwalter gelang, den Hauptprozess des Dienstes zu starten und zu
           identifizieren.

           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.                                         │
           └──────────────────────────────────────────────────────────────────────────┘
           Hinzugefügt in Version 232.

       $MONITOR_SERVICE_RESULT, $MONITOR_EXIT_CODE, $MONITOR_EXIT_STATUS, $MONITOR_INVOCATION_ID,
       $MONITOR_UNIT
           Diese Umgebungsvariablen, die nur für den Dienste-Unit-Typ definiert sind, werden an
           alle ExecStart=- und ExecStartPre=-Prozesse weitergegeben, die in von OnFailure=- oder
           OnSuccess=-Abhängigkeiten ausgelösten Diensten ausgeführt werden.

           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.

           Hinzugefügt in Version 251.

       $PIDFILE
           Der Pfad zu der konfigurierten PID-Datei, falls der Prozess im Auftrag des Dienstes,
           der die Einstellung PIDFile= verwendet, einen Fork durchgeführt hat, siehe
           systemd.service(5) für Details. Dienste-Code kann diese Umgebungsvariable verwenden,
           um automatisch eine PID-Datei am durch die Unit-Datei konfigurierten Ort zu erstellen.
           Dieses Feld ist auf einen absoluten Pfad in dem Dateisystem gesetzt.

           Hinzugefügt in Version 242.

       $REMOTE_ADDR, $REMOTE_PORT
           Falls dies eine Unit ist, die mittels verbindungsbezogener Socket-Aktivierung
           gestartet wurde (d.h. mittels einer Socket-Unit mit Accept=yes), dann enthalten diese
           Umgebungsvariablen die IP-Adresse und die Port-Nummer der fernen Gegenstelle der
           Socket-Verbindung.

           Hinzugefügt in Version 254.

       $TRIGGER_UNIT, $TRIGGER_PATH, $TRIGGER_TIMER_REALTIME_USEC, $TRIGGER_TIMER_MONOTONIC_USEC
           Falls die Unit dynamisch aktiviert wurde (z.B. durch eine entsprechende Pfad- oder
           Timer-Unit), dann werden die Unit, die sie auslöste und andere Typ-abhängige
           Informationen über diese Variablen hereingegeben. Beachten Sie, dass diese
           Informationen so gut wie möglich bereitgestellt werden. Zum Beispiel werden mehrere
           Trigger, die nacheinander passieren, verbunden und nur einer wird berichtet und ohne
           Garantie, welcher davon. Daher ist diese Variable in den meisten Fällen eher
           informativ, d.h. nützlich zur Fehlersuche, verlustbehaftet und sollte nicht als
           Grundlage verwandt werden, um einen umfassenden Grund für die Aktivierung
           weiterzugeben.

           Hinzugefügt in Version 252.

       $MEMORY_PRESSURE_WATCH, $MEMORY_PRESSURE_WRITE
           Falls Speicherdrucküberwachung für diese Dienste-Unit aktiviert ist, ist dies der zu
           beobachtende Pfad und die Daten, die darein geschrieben werden sollen. Siehe Umgang
           mit Speicherdruck[19] zu Details über diese Variablen und die Diensteprotokolldaten,
           die diese transportieren.

           Hinzugefügt in Version 254.

       $FDSTORE
           Die maximale Anzahl an Dateideskriptoren, die in dem Verwalter für diesen Dienst
           gespeichert werden kann. Diese Variable ist gesetzt, wenn der Dateideskriptorspeicher
           für den Dienst aktiviert ist, d.h. FileDescriptorStoreMax= auf einen von Null
           verschiedenen Wert gesetzt ist (siehe systemd.service(5) zu Details). Anwendungen
           können diese Umgebungsvariable prüfen, bevor sie Dateideskriptoren mittels
           sd_pid_notify_with_fds(3) an den Diensteverwalter senden.

           Hinzugefügt in Version 254.

       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-CodeSymbolischer NameBeschreibung           │
       ├──────────┼───────────────────┼────────────────────────┤
       │0         │ EXIT_SUCCESS      │ Generischer            │
       │          │                   │ Erfolgs-Code.          │
       ├──────────┼───────────────────┼────────────────────────┤
       │1         │ EXIT_FAILURE      │ Generischer Fehlschlag │
       │          │                   │ oder unspezifizierter  │
       │          │                   │ Fehler.                │
       └──────────┴───────────────────┴────────────────────────┘

       Die folgenden Dienste-Exit-Codes sind durch die LSB-Spezifikation[20] festgelegt.

       Tabelle 8. LSB-Dienste-Exit-Codes
       ┌──────────┬──────────────────────┬────────────────────────┐
       │Exit-CodeSymbolischer NameBeschreibung           │
       ├──────────┼──────────────────────┼────────────────────────┤
       │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-CodeSymbolischer NameBeschreibung                                │
       ├──────────┼──────────────────────────────┼─────────────────────────────────────────────┤
       │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            │
       │          │                              │ ImportCredential=, 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-CodeSymbolischer NameBeschreibung                  │
       ├──────────┼───────────────────┼───────────────────────────────┤
       │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
           https://uapi-group.org/specifications/specs/discoverable_partitions_specification

        2. Das /proc-Dateisystem
           https://docs.kernel.org/filesystems/proc.html#mount-options

        3. Benutzer-/Gruppennamen-Syntax
           https://systemd.io/USER_NAMES

        4. Schalter »Keine neuen Privilegien«
           https://docs.kernel.org/userspace-api/no_new_privs.html

        5. JSON-Benutzerdatensatz
           https://systemd.io/USER_RECORD

        6. Das /proc-Dateisystem
           https://docs.kernel.org/filesystems/proc.html

        7. Kernel Samepage Merging
           https://docs.kernel.org/admin-guide/mm/ksm.html

        8. Unicode Skalarwerte
           https://www.unicode.org/glossary/#unicode_scalar_value

        9. Unicode-Nichtzeichen
           https://www.unicode.org/glossary/#noncharacter

       10. Unicode-Byte-Reihenfolge-Markierung
           https://www.unicode.org/glossary/#byte_order_mark

       11. POSIX-Shell-Text ohne Anführungszeichen
           https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_02_01

       12. POSIX-Shell-Text in einfachen Anführungszeichen
           https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_02_02

       13. POSIX-Shell-Text in doppelten englischen Anführungszeichen
           https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_02_03

       14. Base64
           https://tools.ietf.org/html/rfc2045#section-6.8

       15. Container-Schnittstelle
           https://systemd.io/CONTAINER_INTERFACE

       16. DMI/SMBIOS
           https://www.dmtf.org/standards/smbios

       17. Qemu
           https://www.qemu.org/docs/master/system/index.html

       18. System- und Dienste-Zugangsberechtigungen
           https://systemd.io/CREDENTIALS

       19. Umgang mit Speicherdruck
           https://systemd.io/MEMORY_PRESSURE

       20. LSB-Spezifikation
           https://refspecs.linuxbase.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html

Ü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 ⟨https://www.gnu.org/licenses/gpl-3.0.html⟩ 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 ⟨debian-l10n-german@lists.debian.org⟩.