oracular (5) systemd.exec.5.gz

Provided by: manpages-de_4.23.1-1_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 pivot_root(2) oder
           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 der neuen
           Wurzel 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

           Anstelle des Verzeichnispfades kann ein versioniertes Verzeichnis ».v/« angegeben werden, siehe
           systemd.v(7) zu Details.

           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.

           Anstelle des Abbildpfades kann ein versioniertes Verzeichnis ».v/« angegeben werden, siehe
           systemd.v(7) zu Details.

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

           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 unterstützt, die in
           benutzerbezogenen Instanzen des Diensteverwalters laufen.

           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 unterstützt, die in
           benutzerbezogenen Instanzen des Diensteverwalters laufen.

           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 unterstützt, die in
           benutzerbezogenen Instanzen des Diensteverwalters laufen.

           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 unterstützt, die in
           benutzerbezogenen Instanzen des Diensteverwalters laufen.

           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 unterstützt, die in
           benutzerbezogenen Instanzen des Diensteverwalters laufen.

           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 unterstützt, die in
           benutzerbezogenen Instanzen des Diensteverwalters laufen.

           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.

           Die Verwendung dieser Option impliziert, dass der Einhängenamensraum der Unit zugewiesen ist, d.h.
           sie impliziert die Wirkung von PrivateMounts= (siehe unten).

           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 unterstützt, die in
           benutzerbezogenen Instanzen des Diensteverwalters laufen.

           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.

           Anstelle des Abbildpfades kann ein versioniertes Verzeichnis ».v/« angegeben werden, siehe
           systemd.v(7) zu Details.

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

           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.

           Anstelle des Verzeichnispfades kann ein versioniertes Verzeichnis ».v/« angegeben werden, siehe
           systemd.v(7) zu Details.

           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, ist die Vorgabe wahr und falls User=, DynamicUser= oder PAMName= gesetzt
           sind, andernfalls falsch. Falls auf wahr gesetzt, werden die Variablen für Systemdienste immer
           gesetzt, d.h. selbst wenn der Standardbenutzer »root« verwandt wird. Falls auf falsch gesetzt, werden
           die aufgeführten Variablen durch den Systemverwalter nicht gesetzt, unabhängig davon, ob User=,
           DynamicUser= oder PAMName= verwandt wird oder nicht. Diese Option hat bei Diensten des
           benutzerbezogenen Diensteverwalters normalerweise keine Auswirkung, da in diesem Fall 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.

       Beachten Sie, dass verschiedene Optionen, die Verzeichnisse nur lesbar machen (wie ProtectSystem=,
       ReadOnlyPaths=, …) keine Auswirkung auf die Fähigkeit von Programmen haben, sich mit AF_UNIX-Sockets in
       diesen Verzeichnissen zu verbinden. Daher können diese Optionen nicht zum Begrenzen von Zugriff auf
       IPC-Dienste verwandt werden.

       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. Ähnlich schließen StateDirectory=,
           LogsDirectory= und zugehörige Verzeichniseinstellungen (siehe unten) die konkreten Verzeichnisse von
           der Wirkung von ProtectSystem= aus. 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 Pfad vonUnterhalb vom Pfad vonUmgebungsvariablenmenge  │
           │                        │ System-UnitsBenutzer-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 unterstützt, die in
           benutzerbezogenen Instanzen des Diensteverwalters laufen.

           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 unterstützt, die in
           benutzerbezogenen Instanzen des Diensteverwalters laufen.

           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 Wirts abgeschaltet sind. Dies bedeutet, dass alle vom Prozess
           etablierten oder entfernten Dateisystemeinhängepunkte für diese privat und nicht im Wirtsystem
           sichtbar sind. Allerdings werden Dateisystemeinhängepunkte, die auf dem Wirt 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 Wirtsystem 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 — PrivateTmp=, PrivateDevices=, ProtectSystem=,
           ProtectHome=, ReadOnlyPaths=, InaccessiblePaths=, ReadWritePaths=, BindPaths=, BindReadOnlyPaths=, …
           — 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 Wirtsystem 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 Wirtsystem 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 (werden mit den Privilegien des Benutzers, der den Systemd-Prozess ausführt,
           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.

           Beachten Sie, dass diese Funktionalität derzeit nur für Systemdienste verfügbar ist, nicht für
           benutzerbezogene Dienste.

           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 sofort
           ohne Berücksichtigung der Erlaubt-Mustern verworfen. Die verbliebenen Protokollmeldungen werden 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.

           Beachten Sie, dass diese Funktionalität derzeit nur für Systemdienste verfügbar ist, nicht für
           benutzerbezogene Dienste.

           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 unterstützt, die in
           benutzerbezogenen Instanzen des Diensteverwalters laufen.

           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.

           Beachten Sie, dass eine fehlende Zugangsberechtigung nicht als fatal betrachtet wird, falls der Pfad
           nicht angegeben ist oder ein gültiger Zugangsberechtigungs-Kennzeichner angegeben ist, d.h. in einem
           der obigen Fälle.

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

           Beachten Sie, dass verschlüsselte Zugangsberechtigungen, die für den benutzerbezogenen
           Diensteverwalter gedacht sind, mit systemd-creds encrypt --user verschlüsselt sein müssen, und solche
           für den System-Diensteverwalter ohne den Schalter --user. Verschlüsselte Zugangsberechtigungen sind
           immer für einen bestimmten Benutzer oder das System als Ganzes gedacht und es wird sichergestellt,
           dass benutzerbezogene Diensteverwalter keine Geheimnisse entschlüsseln können, die für das System
           oder andere Benutzer gedacht sind.

           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"  │ Der Dienst wurde nicht ausgeführt, da │
           │                  │ ExecCondition= fehlschlug.            │
           ├──────────────────┼───────────────────────────────────────┤
           │"oom-kill"        │ Ein Diensteprozess wurde durch den    │
           │                  │ Speicherknappheit- (OOM-)Killer       │
           │                  │ beendet.                              │
           ├──────────────────┼───────────────────────────────────────┤
           │"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⟩.