systemd.exec

SYSTEMD.EXEC(5)                   systemd.exec                   SYSTEMD.EXEC(5)



BEZEICHNUNG
       systemd.exec - Konfiguration der Ausführungsumgebung

ÜBERSICHT
       Dienst.service, Socket.socket, Einhängung.mount, Auslagerung.swap

BESCHREIBUNG
       Unit-Konfigurationsdateien für Dienste, Sockets, Einhängepunkte und
       Auslagerungsgeräte nutzen eine Teilmenge der Konfigurationsoptionen, die
       die Ausführungsumgebung von gestarteten Prozessen definieren.

       Diese Handbuchseite listet die Konfigurationsoptionen auf, die von diesen
       vier Unit-Typen gemeinsam benutzt werden. Siehe systemd.unit(5) für die
       Konfiguration der von allen Unit-Typen gemeinsam benutzten Optionen und
       systemd.service(5), systemd.socket(5), systemd.swap(5) und
       systemd.mount(5) für weitere Informationen über die
       Konfigurationsdateioptionen, die für jeden Unit-Typen spezifisch sind.
       Die ausführungsspezifischen Konfigurationsoptionen werden in den
       Abschnitten [Service], [Socket], [Mount] oder [Swap] konfiguriert,
       abhängig vom Unit-Typ.

       Zusätzlich werden Optionen, die verfügbare Ressourcen mittels Linux
       Control Groups (cgroups) steuern, in systemd.resource-control(5)
       aufgeführt. Diese Optionen ergänzen die hier aufgeführten Optionen.

IMPLIZITE ABHÄNGIGKEITEN
       Einige Ausführungsparameter führen zur Ergänzung von zusätzlichen,
       automatischen Abhängigkeiten:

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

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

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

           Die Einstellungen MountAPIVFS= und PrivateUsers= sind inbesondere im
           Zusammenhang mit RootDirectory= nützlich. Für Details siehe unten.

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

       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.

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

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

           Tabelle 1. Akzeptierte Partitionsnamen
           ┌───────────────┐
           │Partitionsname │
           ├───────────────┤
           │root           │
           ├───────────────┤
           │root-secondary │
           ├───────────────┤
           │home           │
           ├───────────────┤
           │srv            │
           ├───────────────┤
           │esp            │
           ├───────────────┤
           │xbootldr       │
           ├───────────────┤
           │tmp            │
           ├───────────────┤
           │var            │
           ├───────────────┤
           │usr            │
           └───────────────┘
           Diese Option ist nur für Systemdienste verfügbar und wird nicht für
           Dienste, die in benutzerbezogenene Instanzen des Diensteverwalters
           laufen, unterstützt.

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

           Falls das Plattenabbild eine separate Partition für /usr/ enthält,
           könnte sie auch Verity-geschützt sein. In diesem Fall könnte der
           Wurzel-Hash auch über ein erweitertes Attribut »user.verity.usrhash«
           oder eine Datei .usrhash in der Nähe des Plattenabbildes konfiguriert
           sein. Derzeit gibt es keine Option, um den Wurzel-Hash für das
           Dateisystem /usr/ mittels der Unit-Datei direkt zu konfigurieren.

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

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

           Falls das Plattenabbild eine separate Partition für /usr/ enthält,
           könnte sie auch Verity-geschützt sein. In diesem Fall könnte die
           Signatur für den Wurzel-Hash auch über eine Datei .usrhash.p7s in der
           Nähe des Plattenabbildes konfiguriert sein. Derzeit gibt es keine
           Option, um die Wurzel-Hash-Signatur für das Dateisystem /usr/ mittels
           der Unit-Datei direkt zu konfigurieren.

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

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

           Diese Option wird nur für Plattenabbilder unterstützt, die ein
           einzelnes Dateisystem, ohne umhüllende Partitionstabelle, enthalten.
           Abbilder, die eine GPT-Partitionstabelle enthalten, sollten
           stattdessen sowohl ein Wurzeldateisystem als auch passende
           Verity-Daten im gleichen Abbild enthalten, und damit die
           Spezifikation für auffindbare Partitionen[1] umsetzen.

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

       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/ und /dev/ 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 drei 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 drei 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=.

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

       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. Sie kann auch nicht für Dienste verwandt werden, die
           auf Metainformationen von Prozessen anderer Benutzer zugreifen
           müssen. Diese Option impliziert MountAPIVFS=.

           Falls der Kernel keine einhängepunktbezogenen Einhängeoptionen
           hidepid= unterstützt, dann bleibt diese Einstellung ohne Auswirkung
           und die Prozesse der Unit werden in der Lage sein, andere Prozesse zu
           sehen und auf sie zuzugreifen, als ob diese Option nicht verwandt
           worden wäre.

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

       ProcSubset=
           Akzeptiert »all« (die Vorgabe) und »pid«. In letzterem Fall 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..

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

           BindPaths= erstellt reguläre, schreibbare Bind-Einhängungen (außer
           die Quelldateisystemeinhängung ist bereits nur-lesbar markiert),
           während BindReadOnlyPaths= nur-lesbare Bind-Einhängungen erstellt.
           Diese Einstellungen können mehr als einmal verwandt werden, jede
           Verwendung hängt sich an die Liste der Bind-Einhängungen der Unit an.
           Falls zu einer dieser zwei Optionen die leere Zeichenkette zugewiesen
           wird, wird die gesamte Liste an vorher definierten Bind-Einhängungen
           dazu zurückgesetzt. Beachten Sie, dass in diesem Fall sowohl die
           nur-lesbaren als auch die regulären Bind-Einhängungen zurückgesetzt
           werden, unabhängig davon, welche der zwei Einhängungen verwandt wird.

           Diese Option ist besonders nützlich, wenn RootDirectory=/RootImage=
           verwandt wird. In diesem Fall bezieht sich der Quellpfad auf einen
           Pfad im Dateisystem des Rechners, während der Zielpfad sich auf einen
           Pfad unterhalb des Wurzelverzeichnisses der Unit bezieht.

           Beachten Sie, dass das Zielverzeichnis existieren oder Systemd in der
           Lage sein muss, es zu erstellen. Daher ist es nicht möglich, diese
           Option für Einhängepunkte, die unterhalb von in InaccessiblePaths=
           oder unter /home/ und anderen geschützten Verzeichnissen
           verschachtelt sind, zu verwenden, falls ProtectHome=yes angegeben
           ist. Stattdessen sollte TemporaryFileSystem= mit »:ro« oder
           ProtectHome=tmpfs verwandt werden.

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

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

           Einhängeoptionen können als eine durch einzelne Kommata getrennte
           Liste von Optionen definiert werden. In diesem Fall werden sie
           implizit auf die Wurzelpartition auf dem Abbild angewandt. Alternativ
           kann eine Reihe von Doppelpunkt-getrennten Tupeln von Partitionsnamen
           und Einhängeoptionen angegeben werden. Gültige Partitionsnamen und
           -Einhängeoptionen sind zu der oben beschriebenen Einstellung
           RootImageOptions= identisch.

           Jeder Einhängedefinition darf ein »-« vorangestellt werden. In diesem
           Fall wird sie ignoriert, falls sein Quellpfad nicht existiert. Das
           Quellargument ist ein Pfad zu einem Blockgeräteknoten oder einer
           regulären Datei. Falls die Quelle oder das Ziel ein »:« enthält, muss
           dieses mit »\:« maskiert werden. Der Geräteknoten oder das
           Dateisystemabbild muss den gleichen Regeln folgen, wie diese für
           RootImage= spezifiziert sind. Alle Einhängungen, die mit dieser
           Option erstellt sind, sind spezifisch für die Unit, und können in der
           Einhängetabelle des Rechners nicht gesehen werden.

           Diese Einstellung kann mehr als einmal verwandt werden. Jede
           Verwendung wird an die Liste der Einhängepfade der Unit angehängt.
           Falls die leere Zeichenkette zugewiesen wird, wird die gesamte Liste
           der Einhängepfade, die vorher definiert wurde, zurückgesetzt.

           Beachten Sie, dass das Zielverzeichnis existieren oder Systemd in der
           Lage sein muss, es zu erstellen. Daher ist es nicht möglich, diese
           Option für Einhängepunkte, die unterhalb von in InaccessiblePaths=
           oder unter /home/ und anderen geschützten Verzeichnissen
           verschachtelt sind, zu verwenden, falls ProtectHome=yes angegeben
           ist.

           Wenn DevicePolicy= auf »closed« oder »strict« gesetzt ist oder auf
           »auto« und DeviceAllow= gesetzt ist, dann fügt diese Einstellung
           /dev/loop-control mit Modus rw, »block-loop« und »block-blkext« mit
           Modus rwm zu DeviceAllow= hinzu. Siehe systemd.resource-control(5)
           für die Details über DevicePolicy= oder DeviceAllow=. Siehe auch
           nachfolgendes PrivateDevices=, da sie die Einstellungen von
           DevicePolicy= ändern könnte.

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

ZUGANGSDATEN
       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.
           Standardmäßig »off«.

       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.

       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 und werden nicht für
       Dienste, die in benutzerbezogenen Instanzen des Diensteverwalters laufen,
       unterstützt.

       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.

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, aber bestimmte Einstellungen setzen dies außer Kraft und
           ignorieren den Wert dieser Einstellung. Dies ist der Fall, wenn
           SystemCallFilter=, SystemCallArchitectures=,
           RestrictAddressFamilies=, RestrictNamespaces=, PrivateDevices=,
           ProtectKernelTunables=, ProtectKernelModules=, ProtectKernelLogs=,
           ProtectClock=, MemoryDenyWriteExecute=, RestrictRealtime=,
           RestrictSUIDSGID=, DynamicUser= oder LockPersonality= festgelegt
           werden. Beachten Sie, dass selbst diese Einstellung durch sie außer
           Kraft gesetzt wird, systemctl show zeigt den ursprünglichen Wert
           dieser Einstellung. Siehe auch Schalter »Keine neuen Privilegien«[4].

       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, werden alle Fehler ignoriert. Dies betrifft keine
           Befehle, denen »+« vorangestellt ist. Siehe setexeccon(3) für
           Details.

       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.

       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.

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

           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 2. Ressourcenbegrenzungsanweisungen, ihre äquivalenten
           Ulimit-Shell-Befehle und die verwandte Einheit

           ┌─────────────────┬───────────────────┬──────────────────────┐
           │Anweisung        ulimit-Äquivalent Einheit              │
           ├─────────────────┼───────────────────┼──────────────────────┤
           │LimitCPU=        ulimit -t         Sekunden             │
           ├─────────────────┼───────────────────┼──────────────────────┤
           │LimitFSIZE=      ulimit -f         Bytes                │
           ├─────────────────┼───────────────────┼──────────────────────┤
           │LimitDATA=       ulimit -d         Bytes                │
           ├─────────────────┼───────────────────┼──────────────────────┤
           │LimitSTACK=      ulimit -s         Bytes                │
           ├─────────────────┼───────────────────┼──────────────────────┤
           │LimitCORE=       ulimit -c         Bytes                │
           ├─────────────────┼───────────────────┼──────────────────────┤
           │LimitRSS=        ulimit -m         Bytes                │
           ├─────────────────┼───────────────────┼──────────────────────┤
           │LimitNOFILE=     ulimit -n         Anzahl an            │
           │                 │                   │ Dateideskriptoren    │
           ├─────────────────┼───────────────────┼──────────────────────┤
           │LimitAS=         ulimit -v         Bytes                │
           ├─────────────────┼───────────────────┼──────────────────────┤
           │LimitNPROC=      ulimit -u         Anzahl an Prozessen  │
           ├─────────────────┼───────────────────┼──────────────────────┤
           │LimitMEMLOCK=    ulimit -l         Bytes                │
           ├─────────────────┼───────────────────┼──────────────────────┤
           │LimitLOCKS=      ulimit -x         Anzahl an Sperren    │
           ├─────────────────┼───────────────────┼──────────────────────┤
           │LimitSIGPENDING= ulimit -i         Anzahl von Signalen  │
           │                 │                   │ in der Warteschlange │
           ├─────────────────┼───────────────────┼──────────────────────┤
           │LimitMSGQUEUE=   ulimit -q         Bytes                │
           ├─────────────────┼───────────────────┼──────────────────────┤
           │LimitNICE=       ulimit -e         Nice-Stufe           │
           ├─────────────────┼───────────────────┼──────────────────────┤
           │LimitRTPRIO=     ulimit -r         Echtzeitpriorität    │
           ├─────────────────┼───────────────────┼──────────────────────┤
           │LimitRTTIME=     Kein Äquivalent   Mikrosekunden        │
           └─────────────────┴───────────────────┴──────────────────────┘

       UMask=
           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 1. DAX-Seiten zum Speicherauszugsfilter hinzufügen

               CoredumpFilter=default private-dax shared-dax

       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.

       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 proc.txt[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 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 x86, x86-64, ppc, ppc-le, ppc64, ppc64-le, s390
           oder s390x. Welche Personalitätsarchitekturen unterstützt werden,
           hängt von der Systemarchitektur 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.

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

       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.

       IOSchedulingClass=
           Setzt die E/A-Scheduling-Klasse für ausgeführte Prozesse. Akzeptiert
           eine Ganzzahl zwischen 0 und 3 oder eine der Zeichenketten none,
           realtime, best-effort oder idle. 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). 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. Siehe ioprio_set(2) für Details.

SANDBOXING
       Die nachfolgenden Sandboxing-Optionen bieten eine wirksame Art, die
       Kontakte des Systems im Hinblick auf die Prozesse der Unit zu begrenzen.
       Es wird empfohlen, so viele dieser Optionen wie möglich, ohne die
       Betriebsfähigkeit der Prozesse der Unit negativ zu betreffen,
       einzuschalten. Beachten Sie, dass viele dieser
       Sandboxing-Funktionalitäten beschwerdefrei auf Systemen, auf denen der
       unterliegende Sicherheitsmechanismus nicht verfügbar ist, ausgeschaltet
       werden. Beispielsweise hat ProtectSystem= keine Wirkung, falls der Kernel
       ohne Namensräume für Dateisysteme gebaut wurde oder falls der
       Diensteverwalter in einem Container-Verwalter ausgeführt wird, der dafür
       sorgt, dass Dateisystem-Namensräume für seine Nutzlast nicht verfügbar
       sind. Ähnlich hat RestrictRealtime= auf Systemen keine Wirkung, denen die
       Unterstützung für SECCOMP-Systemaufruffilterung fehlt oder in Containern,
       in denen die Unterstützung dafür abgeschaltet ist.

       Beachten Sie auch, dass einige Sandboxing-Funktionalität im Allgemeinen
       in Benutzerdiensten (d.h. Diensten, die vom benutzerbezogenen
       Diensteverwalter ausgeführt werden) nicht verfügbar ist. Insbesondere die
       verschiedenen Einstellungen, die die Unterstützung für
       Dateisystem-Namensräume benötigen (wie ProtectSystem=) sind nicht
       verfügbar, da die zugrundeliegende Kernelfunktionalität nur für
       privilegierte Prozesse erreichbar ist. Allerdings werden die meisten
       Namensraum-Einstellungen, die nicht in ihrem eigenen Benutzerdienst
       funktionieren, bei der Verwendung zusammen mit PrivateUsers=true
       funktionieren.

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

       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 und wird nicht für
           Dienste, die in benutzerbezogenene Instanzen des Diensteverwalters
           laufen, unterstützt.

       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 3. Automatische Verzeichniserstellung und
           Umgebungsvariablen

           ┌────────────────────────┬───────────────┬───────────────────────┬──────────────────────────┐
           │Verzeichnis             Unterhalb vom Unterhalb vom         Umgebungsvariablenmenge  │
           │                        │ Pfad von      Pfad von              │                          │
           │                        │ System-Units  Benutzer-Units        │                          │
           ├────────────────────────┼───────────────┼───────────────────────┼──────────────────────────┤
           │RuntimeDirectory=       /run/         $XDG_RUNTIME_DIR      $RUNTIME_DIRECTORY       │
           ├────────────────────────┼───────────────┼───────────────────────┼──────────────────────────┤
           │StateDirectory=         /var/lib/     $XDG_CONFIG_HOME      $STATE_DIRECTORY         │
           ├────────────────────────┼───────────────┼───────────────────────┼──────────────────────────┤
           │CacheDirectory=         /var/cache/   $XDG_CACHE_HOME       $CACHE_DIRECTORY         │
           ├────────────────────────┼───────────────┼───────────────────────┼──────────────────────────┤
           │LogsDirectory=          /var/log/     $XDG_CONFIG_HOME/log/ $LOGS_DIRECTORY          │
           ├────────────────────────┼───────────────┼───────────────────────┼──────────────────────────┤
           │ConfigurationDirectory= /etc/         $XDG_CONFIG_HOME      $CONFIGURATION_DIRECTORY │
           └────────────────────────┴───────────────┴───────────────────────┴──────────────────────────┘
           Im Falle von RuntimeDirectory= werden die innersten
           Unterverzeichnisse entfernt, wenn die Unit gestoppt wird. Es ist
           möglich, in diesem Fall die festgelegten Verzeichnisse zu erhalten,
           falls RuntimeDirectoryPreserve= auf restart oder yes konfiguriert ist
           (siehe unten). Die mit StateDirectory=, CacheDirectory=,
           LogsDirectory=, ConfigurationDirectory= festgelegten Verzeichnisse
           werden nicht entfernt, wenn die Unit gestoppt wird.

           Außer im Fall von ConfigurationDirectory= werden die innersten
           festgelegten Verzeichnisse dem in User= und Group= angegebenem
           Benutzer und der Gruppe gehören. Falls die angegebenen Verzeichnisse
           bereits existieren und ihre besitzenden Benutzer und Gruppe nicht auf
           die konfigurierten passen, werden alle Dateien und Verzeichnisse
           unterhalb der angegebenen Verzeichnisse sowie alle Verzeichnisse
           selbst rekursiv geändert, so dass die Eigentümerschaft auf die
           konfigurierte passt. Falls die angegebenen Verzeichnisse bereits dem
           richtigen Benutzer und der richtigen Gruppe gehören, werden als
           Optimierung alle Dateien und Verzeichnisse darunter unverändert
           gelassen, selbst falls sie nicht auf das angeforderte passen. Die
           Zugriffsmodi der innersten angegebenen Verzeichnisse wird auf das,
           was in RuntimeDirectoryMode=, StateDirectoryMode=,
           CacheDirectoryMode=, LogsDirectoryMode= und
           ConfigurationDirectoryMode= festgelegt ist, angepasst.

           Diese Optionen implizieren BindPaths= für die festgelegten Pfade. Bei
           der Kombination mit RootDirectory= oder RootImage= werden diese Pfade
           immer innerhalb des Rechners liegen und von dort in den
           Dateisystemnamensraum der Unit eingehängt.

           Falls DynamicUser= zusammen mit StateDirectory= verwandt wird, ändert
           sich die Logik für CacheDirectory= und LogsDirectory= leicht: die
           Verzeichnisse werden unterhalb /var/lib/private, /var/cache/private
           bzw. /var/log/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/lib, /var/cache und /var/log 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).

           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.

       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.

       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.

       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.

       ReadWritePaths=, ReadOnlyPaths=, InaccessiblePaths=
           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.

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

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

           Diese Optionen sind nur für Systemdienste verfügbar und werden nicht
           für Dienste, die in benutzerbezogenen Instanzen des Diensteverwalters
           laufen, unterstützt.

       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 und wird nicht für
           Dienste, die in benutzerbezogenene Instanzen des Diensteverwalters
           laufen, unterstützt.

       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 dies aktiviert ist, 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 und wird nicht für
           Dienste, die in benutzerbezogenene Instanzen des Diensteverwalters
           laufen, unterstützt.

       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 sicher 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 (siehe oben) zu entfernen
           und DevicePolicy=closed zu setzen (siehe systemd.resource-control(5)
           für Details). Beachten Sie, dass die Verwendung dieser Einstellung
           die Ausbreitung von Einhängungen aus dem Dienst zum Rechner trennen
           wird (Ausbreitung in die umgekehrte Richtung wird weiterhin
           funktionieren). Dies bedeutet, dass diese Einstellung nicht für
           Dienste benutzt werden kann, die in der Lage sein sollen,
           Einhängepunkte in dem Haupteinhängeraum zu installieren. Das neue
           /dev/ wird nur lesbar und »noexec« eingehängt. Letzteres könnte alte
           Programme beschädigen, die mit mmap(2) aus /dev/zero ausführbaren
           Speicher einrichten, statt MAP_ANON zu verwenden. Für diese
           Einstellung gelten die gleichen Einschränkungen im Hinblick auf
           Einhängeausbreitung und Privilegien wie für ReadOnlyPaths= und
           verwandte Aufrufe, siehe oben. Falls dies eingeschaltet und im
           Benutzermodus oder im Systemmodus aber ohne die Capability
           CAP_SYS_ADMIN (z.B. durch Setzen von User=) betrieben wird, wird
           NoNewPrivileges=yes impliziert.

           Beachten Sie, dass die Implementierung dieser Einstellung unmöglich
           sein könnte (beispielsweise, falls Einhängenamensräume nicht
           verfügbar sind) und dass die Unit auf eine Art geschrieben sein
           sollte, die sich nicht ausschließlich auf diese Einstellung für die
           Sicherheit verlässt.

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

       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 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 und wird nicht für
           Dienste, die in benutzerbezogenene Instanzen des Diensteverwalters
           laufen, unterstützt.

       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 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 und wird nicht für
           Dienste, die in benutzerbezogenene Instanzen des Diensteverwalters
           laufen, unterstützt.

       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.

       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 und wird nicht für
           Dienste, die in benutzerbezogenene Instanzen des Diensteverwalters
           laufen, unterstützt.

       ProtectClock=
           Akzeptiert ein logisches Argument. Falls wahr, werden Schreibzugriffe
           auf die Hardware- oder System-Uhr verweigert. Für die meisten
           Dienste, die die Uhr nicht verändern müssen, wird empfohlen, dies
           einzuschalten. 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. Dies stellt sicher, dass /dev/rtc0, /dev/rtc1 usw. für
           den Dienst nur lesbar werden. Siehe systemd.resource-control(5) für
           die Details von DeviceAllow=.

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

       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. Falls eingeschaltet
           und im Benutzermodus oder im Systemmodus aber ohne die Capability
           CAP_SYS_ADMIN (d.h. für Dienste, bei denen User= gesetzt ist)
           betrieben, wird NoNewPrivileges=yes impliziert. 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 und wird nicht für
           Dienste, die in benutzerbezogenene Instanzen des Diensteverwalters
           laufen, unterstützt.

       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. Falls dies eingeschaltet und
           im Benutzermodus oder im Systemmodus, aber ohne die Capability
           CAP_SYS_ADMIN (z.B. durch Setzen von User=) betrieben wird, wird
           NoNewPrivileges=yes impliziert.

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

       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 und wird nicht für
           Dienste, die in benutzerbezogenene Instanzen des Diensteverwalters
           laufen, unterstützt.

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

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

       RestrictAddressFamilies=
           Beschränkt die Gruppe der Socket-Adressfamilien, auf die Prozesse
           dieser Unit zugreifen können. Akzeptiert eine Leerzeichen-getrennte
           Liste von freizugebenden Adressfamiliennamen, wie AF_UNIX, AF_INET
           oder AF_INET6. Wird dieser ~ 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. Falls der Betrieb im Benutzermodus oder im
           Systemmodus, aber ohne die Capability CAP_SYS_ADMIN (z.B. durch
           Setzen von User=) erfolgt, wird NoNewPrivileges=yes impliziert.
           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.

       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. Falls der
           Betrieb im Benutzermodus oder im Systemmodus aber ohne die Capability
           CAP_SYS_ADMIN (z.B. durch Setzen von User=) erfolgt, wird
           NoNewPrivileges=yes impliziert.

           Beispiel: Falls eine Unit die Einstellunng

               RestrictNamespaces=cgroup ipc
               RestrictNamespaces=cgroup net

           hat, dann werden cgroup, ipc und net gesetzt. Falls der zweiten Zeile
           »~« vorangestellt wird, d.h.

               RestrictNamespaces=cgroup ipc
               RestrictNamespaces=~cgroup net

           dann wird nur ipc gesetzt.

       LockPersonality=
           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. Falls der Betrieb im Benutzermodus oder
           im Systemmodus, aber ohne die Capability CAP_SYS_ADMIN (z.B. durch
           Setzen von User=) erfolgt, wird NoNewPrivileges=yes impliziert.

       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, 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. Falls
           der Betrieb im Benutzermodus oder im Systemmodus, aber ohne die
           Capability CAP_SYS_ADMIN (z.B. durch Setzen von User=) erfolgt, wird
           NoNewPrivileges=yes impliziert.

       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. Falls der Betrieb im Benutzermodus oder im
           Systemmodus, aber ohne die Capability CAP_SYS_ADMIN (z.B. durch
           Setzen von User=) erfolgt, wird NoNewPrivileges=yes impliziert.
           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.

       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)).Falls der Betrieb im Benutzermodus
           oder im Systemmodus, aber ohne die Capability CAP_SYS_ADMIN (z.B.
           durch Setzen von User=) erfolgt, wird NoNewPrivileges=yes impliziert.
           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«.

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

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

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

           Falls eingeschaltet, wird dies drei Aktionen für jeden aufgerufenen
           Prozess auslösen: ein neuer CLONE_NEWNS-Namensraum wird erstellt,
           danach werden alle existierenden Einhängungen neu als MS_SLAVE
           eingehängt, um die Ausbreitung aus den Prozessen der Unit zu dem
           Hauptsystem zu deaktivieren (aber die Ausbreitung in die umgekehrte
           Richtung bleibt wirksam). Schließlich werden die Einhängungen erneut
           gemäß des in dem Schalter MountFlags= konfigurierten
           Ausbreitungsmodus eingehängt, siehe unten.

           Dateisystemnamensräume werden individuell für jeden mit »fork« vom
           Diensteverwalter gestarteten Prozess eingerichtet. Einhängungen, die
           im Namensraum des durch ExecStartPre= erstellten Prozesses etabliert
           wurden, werden daher automatisch bereinigt, sobald der Prozess sich
           beendet und werden für nachfolgend durch ExecStart= mit Fork
           gestartete Prozesse nicht verfügbar sein (und Ähnliches gilt auch für
           die verschiedenen anderen für Units konfigurierten Befehle). Ähnlich
           erlaubt JoinsNamespaceOf= nicht die gemeinsame Benutzung von
           Kernelnamensräumen zwischen Units, es ermöglicht nur die gemeinsame
           Benutzung der Verzeichnisse /tmp/ und /var/tmp/.

           Andere Dateisystemnamensräume-Einstellungen für Units —
           PrivateMounts=, PrivateTmp=, PrivateDevices=, ProtectSystem=,
           ProtectHome=, ReadOnlyPaths=, InaccessiblePaths=, ReadWritePaths=, …
           — ermöglichen Dateisystemnamensräume in einer Art ähnlich dieser
           Option. Daher ist es primär zur expliziten Anfrage dieses Verhalten
           nützlich, falls keine der anderen Einstellungen verwandt wird.

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

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

           Diese Einstellung steuert nur die abschließenden
           Ausbreitungseinstellungen, die für alle Einhängepunkte des
           Dateisystemnamensraums, der für jeden Prozess dieser Unit erstellt
           wurde, wirksam sind. Andere Dateisystemnamensraum-Unit-Einstellungen
           (siehe die Diskussion in PrivateMounts= oben) werden implizit
           Einhänge- und Aushängeausbreitung von den Prozessen der Unit in
           Richtung des Systems deaktivieren, indem sie die
           Ausbreitungseinstellungen aller Einhängepunkte in dem
           Dateisystemnamensraum der Unit zuerst auf slave setzen. Setzen der
           Option auf shared richtet die Ausbreitung in diesem Fall nicht wieder
           ein.

           Falls nicht gesetzt – aber es sind durch andere
           Dateisystemnamensraumeinstellungen der Unit keine
           Dateisystemnamensräume aktiviert –, wird shared Einhängeausbreitung
           verwandt, aber wie erwähnt, wird slave zuerst angewandt, Ausbreitung
           von den Prozessen der Unit zum Hauptsystem bleibt weiterhin
           abgeschaltet.

           Es wird nicht empfohlen, private Einhängeausbreitung für Units zu
           verwenden, da dies bedeutet, dass temporäre Einhängungen (wie
           Wechselmedien) auf dem Hauptsystem eingehängt bleiben und daher
           unbefristet in mit Fork erstellten Programmen als beschäftigt
           markiert sind, da die Aushängeausbreitungsereignisse in dem
           Dateisystemnamensraum der Unit nicht empfangen werden.

           Normalerweise ist es am besten, diese Einstellung unverändert zu
           lassen und stattdessen abstraktere Dateisystemnamensraumoptionen zu
           verwenden, insbesondere PrivateMounts=, siehe oben.

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

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. Falls der Betrieb im Benutzermodus oder im Systemmodus, aber
           ohne die Capability CAP_SYS_ADMIN (z.B. durch Setzen von User=nobody)
           erfolgt, wird NoNewPrivileges=yes impliziert. 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 Diensteprogrammes benutzt — falls er blockiert ist,
           wird der Diensteaufruf notwendigerweise fehlschlagen. Falls auch die
           Ausführung des Diensteprogramms aus irgendwelchen Gründen fehlschlägt
           (beispielsweise fehlendes Diensteprogramm), könnte die
           Fehlerbehandlungslogik Zugriff auf eine zusätzliche Gruppe an
           Systemaufrufen benötigen, um diesen Fehlschlag korrekt zu verarbeiten
           und zu protokollieren. Es könnte notwendig sein, temporär die
           Systemaufruffilter zu deaktivieren, um die Fehlersuche bei solchen
           Fehlschlägen zu vereinfachen.

           Falls Sie beide Arten dieser Option (d.h. explizite Freischaltung und
           Ausschlussliste) festlegen, wird die erste angetroffene Vorrang haben
           und die Standardaktion festlegen (Beendigung oder Bestätigung eines
           Systemaufrufs). Dann wird das nächste Auftreten dieser Option die
           Liste der Systemaufrufe zu der Menge der gefilterten Systemaufrufe
           hinzufügen oder aus dieser löschen, abhängig von seiner Art und der
           Standardaktion. (Falls Sie beispielsweise mit einer expliziten
           Freischaltung von read() und write() beginnen und direkt danach eine
           Ausschlussliste mit write() hinzufügen, dann wird write() aus der
           Menge entfernt.)

           Da die Anzahl der möglichen Systemaufrufe groß ist, werden
           vordefinierte Gruppen von Systemaufrufen bereitgestellt. Eine Gruppe
           beginnt mit dem Zeichen »@«, gefolgt vom Namen der Gruppe.

           Tabelle 4. Derzeit vordefinierte Systemaufrufgruppen
           ┌────────────────┬─────────────────────────────────┐
           │Gruppe          Beschreibung                    │
           ├────────────────┼─────────────────────────────────┤
           │@aio            │ Asynchrone E/A                  │
           │                │ (io_setup(2), io_submit(2)      │
           │                │ und verwandte Aufrufe)          │
           ├────────────────┼─────────────────────────────────┤
           │@basic-io       │ Systemaufrufe für               │
           │                │ grundlegende E/A: Lesen,        │
           │                │ Schreiben, Suchen,              │
           │                │ Duplizieren und Schließen       │
           │                │ von Dateideskriptoren           │
           │                │ (read(2), write(2) und          │
           │                │ verwandte Aufrufe)              │
           ├────────────────┼─────────────────────────────────┤
           │@chown          │ Änderung der                    │
           │                │ Dateieigentümerschaft           │
           │                │ (chown(2), fchownat(2) und      │
           │                │ verwandte Aufrufe)              │
           ├────────────────┼─────────────────────────────────┤
           │@clock          │ Systemaufrufe zur Änderung      │
           │                │ der Systemuhr (adjtimex(2),     │
           │                │ settimeofday(2) und             │
           │                │ verwandte Aufrufe)              │
           ├────────────────┼─────────────────────────────────┤
           │@cpu-emulation  │ Systemaufrufe für               │
           │                │ CPU-Emulierungsfunktionen       │
           │                │ (vm86(2) und verwandte          │
           │                │ Aufrufe)                        │
           ├────────────────┼─────────────────────────────────┤
           │@debug          │ Fehlersuche,                    │
           │                │ Leistungsüberwachung und        │
           │                │ Nachverfolgungsfunktionen       │
           │                │ (ptrace(2),                     │
           │                │ perf_event_open(2) und          │
           │                │ verwandte Aufrufe)              │
           ├────────────────┼─────────────────────────────────┤
           │@file-system    │ Dateisystemaktionen:            │
           │                │ Öffnen, Dateien und             │
           │                │ Verzeichnisse zum Lesen und     │
           │                │ Schreiben erstellen, sie        │
           │                │ umbenennen oder entfernen,      │
           │                │ Lesen von                       │
           │                │ Dateieigenschaften oder         │
           │                │ Erstellen von harten und        │
           │                │ symbolischen Links              │
           ├────────────────┼─────────────────────────────────┤
           │@io-event       │ Systemaufrufe für               │
           │                │ Ereignisschleifen (poll(2),     │
           │                │ select(2), epoll(7),            │
           │                │ eventfd(2) und verwandte        │
           │                │ Aufrufe)                        │
           ├────────────────┼─────────────────────────────────┤
           │@ipc            │ Pipes, SysV IPC,                │
           │                │ POSIX-Nachrichtenwarteschlangen │
           │                │ und andere IPC                  │
           │                │ (mq_overview(7), svipc(7))      │
           ├────────────────┼─────────────────────────────────┤
           │@keyring        │ Kernel-Schlüsselbundzugriff     │
           │                │ (keyctl(2) und verwandte        │
           │                │ Aufrufe)                        │
           ├────────────────┼─────────────────────────────────┤
           │@memlock        │ Sperren von Speicher im RAM     │
           │                │ (mlock(2), mlockall(2) und      │
           │                │ verwandte Aufrufe)              │
           ├────────────────┼─────────────────────────────────┤
           │@module         │ Laden und Entladen von          │
           │                │ Kernelmodulen (init_module(2),  │
           │                │ delete_module(2) und verwandte  │
           │                │ Aufrufe)                        │
           ├────────────────┼─────────────────────────────────┤
           │@mount          │ Einhängen und Aushängen von     │
           │                │ Dateisystemen (mount(2),        │
           │                │ chroot(2) und verwandte         │
           │                │ Aufrufe)                        │
           ├────────────────┼─────────────────────────────────┤
           │@network-io     │ Socket-E/A (einschließlich      │
           │                │ lokalem AF_UNIX): socket(7),    │
           │                │ unix(7)                         │
           ├────────────────┼─────────────────────────────────┤
           │@obsolete       │ Ungewöhnliches, Veraltetes oder │
           │                │ nicht Implementiertes           │
           │                │ (create_module(2), gtty(2), …)  │
           ├────────────────┼─────────────────────────────────┤
           │@privileged     │ Alle Systemaufrufe, die         │
           │                │ Administrator-Capabilities      │
           │                │ benötigen (capabilities(7))     │
           ├────────────────┼─────────────────────────────────┤
           │@process        │ Prozesssteuerung, -ausführung,  │
           │                │ Namensraumaktionen  (clone(2),  │
           │                │ kill(2), namespaces(7), …)      │
           ├────────────────┼─────────────────────────────────┤
           │@raw-io         │ Rohzugriff auf E/A-Ports        │
           │                │ (ioperm(2), iopl(2),            │
           │                │ pciconfig_read(), …)            │
           ├────────────────┼─────────────────────────────────┤
           │@reboot         │ Systemaufrufe für den Neustart  │
           │                │ und die Neustartvorbereitung    │
           │                │ (reboot(2), kexec(), …)         │
           ├────────────────┼─────────────────────────────────┤
           │@resources      │ Systemaufrufe für die Änderung  │
           │                │ von Ressourcenbeschränkungen,   │
           │                │ Speicher- und                   │
           │                │ Schedulingparametern            │
           │                │ (setrlimit(2), setpriority(2),  │
           │                │ …)                              │
           ├────────────────┼─────────────────────────────────┤
           │@setuid         │ Systemaufrufe zur Änderung der  │
           │                │ Benutzerkennung und             │
           │                │ Gruppenberechtigungen           │
           │                │ (setuid(2), setgid(2),          │
           │                │ setresuid(2), …)                │
           ├────────────────┼─────────────────────────────────┤
           │@signal         │ Systemaufrufe für die           │
           │                │ Veränderung und Handhabung von  │
           │                │ Prozesssignalen (signal(2),     │
           │                │ sigprocmask(2), …)              │
           ├────────────────┼─────────────────────────────────┤
           │@swap           │ Systemaufrufe für die           │
           │                │ Aktivierung/Deaktivierung von   │
           │                │ Auslagerungsgeräten (swapon(2), │
           │                │ swapoff(2))                     │
           ├────────────────┼─────────────────────────────────┤
           │@sync           │ Synchronisierung von Dateien    │
           │                │ und Speicher auf Platte         │
           │                │ (fsync(2), msync(2) und         │
           │                │ verwandte Aufrufe)              │
           ├────────────────┼─────────────────────────────────┤
           │@system-service │ Eine vernünftige Gruppe von     │
           │                │ Systemaufrufen, die von         │
           │                │ typischen Systemdiensten        │
           │                │ benutzt werden, ausschließlich  │
           │                │ aller Systemaufrufe für         │
           │                │ besondere Zwecke. Dies ist der  │
           │                │ empfohlene Anfangspunkt zum     │
           │                │ expliziten Erlauben von         │
           │                │ Systemaufrufen für              │
           │                │ Systemdienste, da es das        │
           │                │ enthält, was typischerweise von │
           │                │ Systemdiensten benötigt wird,   │
           │                │ aber äußerst spezielle          │
           │                │ Schnittstellen ausschließt.     │
           │                │ Beispielsweise sind die         │
           │                │ folgenden APIs ausgeschlossen:  │
           │                │ »@clock«, »@mount«, »@swap«,    │
           │                │ »@reboot«.                      │
           ├────────────────┼─────────────────────────────────┤
           │@timer          │ Systemaufrufe für               │
           │                │ Scheduling-Aktionen von Time    │
           │                │ (alarm(2), timer_create(2), …)  │
           ├────────────────┼─────────────────────────────────┤
           │@known          │ Alle durch den Kernel           │
           │                │ definierten Systemaufrufe.      │
           │                │ Diese Liste ist in Systemd      │
           │                │ statisch basierend auf der      │
           │                │ Kernelversion, die bei der      │
           │                │ Veröffentlichung von Systemd    │
           │                │ verfügbar war, definiert. Sie   │
           │                │ wird fortschreidend veralten,   │
           │                │ wenn der Kernel aktualisiert    │
           │                │ wird.                           │
           └────────────────┴─────────────────────────────────┘
           Beachten Sie, dass neue Systemaufrufe zu den obigen Gruppen
           hinzugefügt werden könnten, wenn neue Systemaufrufe zu dem Kernel
           hinzugefügt werden. Die Inhalte dieser Gruppen können sich auch
           zwischen Systemd-Versionen unterscheiden. Zusätzlich hängt die Liste
           der Systemaufrufe auch von der Kernelversion und der Architektur, für
           die Systemd kompiliert wurde, ab. Verwenden Sie
           systemd-analyze syscall-filter, um die tatsächliche Liste der
           Systemaufrufe in jedem Filter aufzuführen.

           Im Allgemeinen ist das explizite Erlauben von Systemaufrufen (statt
           einer Ausschlussliste) der sicherere Betriebsmodus. Es wird
           empfohlen, für alle langlaufenden Systemdienste eine Liste explizit
           erlaubter Systemaufrufe zu erzwingen. Insbesondere sind die
           nachfolgenden Zeilen eine relativ sicherere grundlegende Wahl für den
           Großteil der Systemdienste:

               [Service]
               SystemCallFilter=@system-service
               SystemCallErrorNumber=EPERM

           Beachten Sie, dass die verschiedenen Systemaufrufe redundant
           definiert werden: es gibt mehrere Systemaufrufe zur Ausführung der
           gleichen Aktion. Beispielsweise kann der Systemaufruf
           pidfd_send_signal() zur Ausführung von Aktionen ähnlich zu dem
           älteren Systemaufruf kill() verwandt werden, daher führt das
           Blockieren von letzterem ohne das Blockieren des ersteren nur zu
           einem schwachen Schutz. Da neue Systemaufrufe regelmäßig dem Kernel
           hinzugefügt werden, verlangt das Pflegen von vollständigen
           Ausschlusslisten für Systemaufrufe ständige Arbeit. Es wird daher
           empfohlen, stattdessen Freischaltungen einzusetzen, wodurch der
           Nutzen entsteht, dass neue Systemaufrufe standardmäßig implizit
           blockiert sind, bis die Freischaltung aktualisiert wurde.

           Beachten Sie auch, dass eine Reihe von Systemaufrufen zugreifbar sein
           müssen, damit der dynamische Linker funktioniert. Der dynamische
           Linker wird zur Ausführung der meisten regulären Programme benötigt
           (konkret dynamische ELF-Programme - auf diese Art bauen die meisten
           Distributionen paketierte Programme). Dies bedeutet, dass das
           Blockieren dieser Systemaufrufe (wozu open(), openat() und mmap()
           gehören) dazu führen wird, das die meisten mit generischen
           Distributionen ausgelieferten Programme unbenutzbar werden.

           Es wird empfohlen, die auf den Namensraum des Dateisystems bezogenen
           Optionen mit SystemCallFilter=~@mount zu kombinieren, um zu
           verhindern, dass die Prozesse der Unit die Abbildungen rückgängig
           machen. Insbesondere sind dies die Optionen PrivateTmp=,
           PrivateDevices=, ProtectSystem=, ProtectHome=,
           ProtectKernelTunables=, ProtectControlGroups=, ProtectKernelLogs=,
           ProtectClock=, ReadOnlyPaths=, InaccessiblePaths= und
           ReadWritePaths=.

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

       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). Falls der Betrieb im Benutzermodus
           oder im Systemmodus, aber ohne die Capability CAP_SYS_ADMIN (z.B.
           durch Setzen von User=) erfolgt, wird NoNewPrivileges=yes impliziert.
           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.

       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. Falls der Betrieb im Benutzermodus oder im
           Systemmodus, aber ohne die Capability CAP_SYS_ADMIN (z.B. durch
           Setzen von User=nobody) erfolgt, wird NoNewPrivileges=yes impliziert.
           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.

UMGEBUNGSVARIABLEN
       Environment=
           Setzt Umgebungsvariablen für ausgeführte Prozesse. Akzeptiert eine
           Leerzeichen-getrennte Liste von Variablenzuweisungen. Diese Option
           kann mehr als einmal angegeben werden, dann werden alle aufgeführten
           Variablen gesetzt. Falls die gleiche Variable zweimal gesetzt ist,
           wird die spätere Einstellung die frühere Einstellung außer Kraft
           setzen. Falls der Option die leere Zeichenkette zugewiesen wird, wird
           die Liste der Umgebungsvariablen zurückgesetzt und alle
           vorhergehenden Zuweisungen haben keine Wirkung. Innerhalb der
           Zeichenkette wird keine Variablenexpansion durchgeführt, es ist
           allerdings eine Kennzeichner-Expansion möglich. Das Zeichen »$« hat
           keine besondere Bedeutung. Falls Sie einen Wert, der Leerzeichen oder
           Gleichheitszeichen enthält, einer Variablen zuweisen müssen,
           verwenden Sie doppelte Anführungszeichen (") für die Zuweisung.

           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= (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. Eine Zeile, die mit
           einem Rückwärtsschrägstrich endet, wird mit der nachfolgenden
           verbunden, wodurch mehrzeilige Variablendefinitionen ermöglicht
           werden. Das Auswertprogramm entfernt Leerraumzeichen am Anfang und
           Ende der Zeile von den Werten der Zuweisungen, falls Sie keine
           doppelten Anführungszeichen (") verwenden.

           C-Maskierungen[7] werden unterstützt, aber nicht die meisten
           Steuerzeichen[8]. Es können »\t« und »\n« zum Einfügen von
           Tabulatoren und Zeilenumbrüchen in EnvironmentFile= verwandt werden.

           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.

           C-Maskierungen[7] werden unterstützt, aber nicht die meisten
           Steuerzeichen[8]. Es können »\t« und »\n« zum Einfügen von
           Tabulatoren und Zeilenumbrüchen in EnvironmentFile= verwandt werden.

           Beispiel:

               PassEnvironment=VAR1 VAR2 VAR3

           übergibt die drei Variablen »VAR1«, »VAR2«, »VAR3« mit den für diese
           Variablen in PID1 gesetzten Werten.

           Siehe environ(7) für Details über Umgebungsvariablen.

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

           See "Environment Variables in Spawned Processes" below for a
           description of how those settings combine to form the inherited
           environment. See environ(7)  for general information about
           environment variables.

PROTOKOLLIERUNG UND SYSTEM-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.

           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.

       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,
           socket oder fd:Name.

           inherit dupliziert den Dateideskriptor der Standardeingabe für die
           Standardausgabe.

           null verbindet die Standardausgabe mit /dev/null, d.h. alles dahin
           Geschriebene geht verloren.

           tty verbindet die Standardausgabe mit einem TTY (wie in TTYPath=
           konfiguriert, siehe unten). Falls das TTY nur für die Ausgabe
           verwandt wird, wird der ausgeführte Prozess nicht der steuernde
           Prozess des Terminals werden und wird nicht fehlschlagen oder darauf
           warten, dass andere Prozesse das Terminal freigeben.

           journal verbindet die Standardausgabe mit dem Journal, das über
           journalctl(1) erreichbar ist. Beachten Sie, dass alles, was nach
           Syslog oder Kmsg (siehe unten) geschrieben wird, implizit auch im
           Journal gespeichert wird, die spezielle unten aufgeführten Optionen
           ist daher eine Obermenge dieser Option. (Beachten Sie auch, dass alle
           externen, zusätzlichen Syslog-Daemons ihre Protokolldaten auch aus
           dem Journal empfangen, daher ist dies die Option, die verwandt werden
           sollte, wenn das Protokoll mit solch einem Daemon verarbeitet werden
           soll.)

           kmsg verbindet die Standardeingabe mit dem Kernelprotokollpuffer, der
           über dmesg(1) erreichbar ist, zusätzlich zum Journal. Der
           Journal-Daemon könnte so konfiguriert sein, dass er alles, was er
           empfängt, sowieso zu Kmsg sendet, wodurch diese Option in diesem Fall
           keinen Unterschied zu journal darstellt.

           journal+console und kmsg+console arbeiten auf eine ähnliche Art wie
           die zwei Optionen oben, kopieren aber auch sämtliche Ausgabe auf die
           Systemkonsole.

           Die Option file:Pfad kann zum Verbinden eines bestimmten
           Dateisystemobjektes mit der Standardausgabe verwandt werden. Die
           Semantik ist ähnlich zu der der gleichen Option von StandardInput=,
           siehe oben. Falls sich Pfad auf eine reguläre Datei auf dem
           Dateisystem bezieht, wird sie zum Schreiben am Anfang der Datei
           geöffnet (erstellt, falls sie noch nicht existiert), aber ohne sie
           abzuschneiden. Falls die Standardeingabe und -ausgabe auf den
           gleichen Dateipfad verwiesen werden, wird dieser nur einmal zum Lesen
           und Schreiben geöffnet und dupliziert. Dies ist insbesondere
           nützlich, wenn sich der festgelegte Pfad auf ein AF_UNIX-Socket im
           Dateisystem bezieht, da in diesem Fall nur eine einzelne
           Datenstromverbindung für sowohl Ein- als auch Ausgabe erstellt wird.

           append:Pfad ist ähnlich zu file:Pfad oben, es öffnet die Datei aber
           im Anhängemodus.

           socket verbindet die Standardausgabe zu einem mittels
           Socket-Aktivierung erlangten Socket. Die Semantik ist ähnlich zu der
           der gleichen Option von StandardInput=, siehe oben.

           Die Option fd:Name verbindet die Standardausgabe mit einem bestimmten
           benannten, durch eine Socket-Unit bereitgestellten Dateideskriptor.
           Es kann als Teil dieser Option ein Name, gefolgt von einem
           »:«-Zeichen, angegeben werden (z.B. »fd:foobar«). Falls kein Name
           angegeben ist, wird der Name »stdout« impliziert (d.h. »fd« ist
           äquivalent zu »fd:stdout«). Mindestens eine Socket-Unit, die den
           angegebenen Namen definiert, muss über die Option Sockets=
           bereitgestellt werden und der Dateideskriptorname darf sich vom Namen
           der Socket-Unit, die ihn enthält, unterscheiden. Falls mehrere
           Treffer gefunden werden, wird der erste verwandt. Siehe
           FileDescriptorName= in systemd.socket(5) für weitere Details über
           benannte Dateideskriptoren und ihrer Sortierung.

           Falls die Standardausgabe (oder die Fehlerausgabe, siehe unten) einer
           Unit mit dem Journal oder dem Kernelprotokollpuffer verbunden ist,
           wird die Unit implizit eine Abhängigkeit vom Typ After= von
           systemd-journald.socket erhalten (siehe auch den Abschnitt »Implizite
           Abhängigkeiten« oben). Beachten Sie auch, dass in diesem Fall Stdout
           (oder Stderr, siehe unten) ein AF_UNIX-Datenstrom-Socket und keine
           PIPE oder FIFO, die erneut geöffnet werden kann, sein wird. Das
           bedeutet, dass bei der Ausführung von Shell-Skripten die Konstruktion
           »echo "hello" > /dev/stderr« zum Schreiben von Text nach Stderr nicht
           funktionieren wird. Um dies zu entschärfen, verwenden Sie stattdessen
           die Konstruktion »echo "hello" >&2«, die größtenteils äquivalent ist
           und diesen Fallstrick vermeidet.

           Der Vorgabewert dieser Einstellung ist der mit DefaultStandardOutput=
           in systemd-system.conf(5) gesetzte Wert, der standardmäßig journal
           ist. Beachten Sie, dass dieser Parameter zum Hinzufügen zusätzlicher
           Abhängigkeiten führen kann (siehe oben).

       StandardError=
           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. 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[9] 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=SWNrIHNpdHplIGRhIHVuJyBlc3NlIEtsb3BzLAp1ZmYgZWVtYWwga2xvcHAncy4KSWNrIGtpZWtl \
                                 LCBzdGF1bmUsIHd1bmRyZSBtaXIsCnVmZiBlZW1hbCBqZWh0IHNlIHVmZiBkaWUgVMO8ci4KTmFu \
                                 dSwgZGVuayBpY2ssIGljayBkZW5rIG5hbnUhCkpldHogaXNzZSB1ZmYsIGVyc2NodCB3YXIgc2Ug \
                                 enUhCkljayBqZWhlIHJhdXMgdW5kIGJsaWNrZSDigJQKdW5kIHdlciBzdGVodCBkcmF1w59lbj8g \
                                 SWNrZSEK
               …

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

       LogExtraFields=
           Konfiguriert zusätzliche Protokollmetadatenfelder, die in alle
           Protokolldatensätze aufgenommen werden, die von Prozessen, die dieser
           Unit zugeordnet sind, 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.

       LogRateLimitIntervalSec=, LogRateLimitBurst=
           Konfiguriert die Ratenbegrenzung, die auf von dieser Unit erstellte
           Nachrichten 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=.

       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 Protkolldaten (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 Einstellungen (siehe oben) funktionieren.
           Journal-Namensräume können daher nicht für Dienste verwandt werden,
           die Einhängepunkte auf dem Rechner etablieren müssen.

           Wenn diese Option gesetzt ist, wird die Unit automatisch Ordnungs-
           und Anforderungsabhängigkeiten von den zwei der
           systemd-journald@.service-Instanz zugeordneten Socket-Units erlangen,
           so dass diese vor dem Starten der Unit automatisch etabliert werden.
           Beachten Sie, dass bei Verwendung dieser Option die
           Protokollierausgabe dieses Dienstes nicht in der regulären
           journalctl(1)-Ausgabe erscheint, außer die Option --namespace= wird
           verwandt.

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

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

       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
           Übergibt ein Zugangsdatum an die Unit. Zugangsdaten 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 Zugangsdaten in der Umgebungsvariable
           $CREDENTIALS_DIRECTORY für die Prozesse der Unit exportiert.

           Die Einstellung LoadCredential= akzeptiert eine textuelle Kennung als
           Namen für ein Zugangsdatum sowie einen Dateisystempfad. 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 Zugangsdatum 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 Zugangsdatum aus dieser Verbindung
           ausgelesen, wodurch ein einfacher IPC-Integrationspunkt
           bereitgestellt wird, um Zugangsdaten dynamisch von anderen Diensten
           bereitzustellen. Falls der angegeben Pfad nicht absolut ist und
           selbst wieder als gültiger Zugangsdatumkennzeichner geeignet ist,
           wird er so interpretiert, dass er sich auf ein Zugangsdatum bezieht,
           das der Diensteverwalter selbst mittels der Umgebungsvariable
           $CREDENTIALS_DIRECTORY empfangen hat, was zur Weiterleitung von
           Zugangsdaten von einer aufrufenden Umgebung (z.B. einem
           Container-Verwalter, der den Diensteverwalter aufgerufen hat) an
           einen Dienst verwandt werden kann. Der Inhalt der Datei/des Sockets
           können beliebige binäre oder textuelle Daten sein, einschließlich
           Zeilenumbruchzeichen und NUL-Bytes. Diese Option kann mehrfach
           verwandt werden, wobei jedes Mal ein zusätzliches Zugangsdatum
           definiert wird, das an die Unit übergeben wird.

           Der Diensteverwalter muss auf die Zugangsdaten-Dateien/-Sockets
           zugreifen können, aber die Prozesse müsse nicht direkt darauf
           zugreifen können: die Zugangsdaten 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 einen Pfad zu
           referenzieren, unter dem ein Zugangsdatum gelesen werden kann,
           verwenden Sie »${CREDENTIALS_DIRECTORY}/mycred«, z.B. »ExecStart=cat
           ${CREDENTIALS_DIRECTORY}/mycred«.

           Derzeit wird eine Größenbegrenzung für aufsummierte Zugangsdaten von
           1 MB pro Unit durchgesetzt.

           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 Zugangsdatenkennung in seinem Socket-Namen enthält. Verwenden
           Sie getpeername(2), um diese Information abzufragen. Der
           zurückgelieferte Socket-Name ist als NUL ZUFALL »unit« UNIT »/«
           KENNUNG formatiert, d.h. ein NUL-Byte (wie für Socket-Namen aus
           abstrakten Namensräumen benötigt), gefolgt von einer zufälligen
           Zeichenkette (die aus alphadezimalen Zeichen besteht), gefolgt von
           der Zeichenkette »unit«, gefolgt von dem anfragenden Unit-Namen,
           gefolgt von dem Zeichen »/«, gefolgt von der erbetenen textuellen
           Zugangsdatenkennung. Beispiel:
           »\0adf9d86b6eda275e/unit/foobar.service/credx«, wobei die
           Zugangsdaten »credx« für eine Unit »foobar.service« erbeten werden.
           Diese Funktionalität ist nützlich, wenn ein einzelnes, auf Anfragen
           wartendes Socket Zugangsdaten für mehrere Abnehmer bereitstellen
           soll.

       SetCredential=KENNUNG:WERT
           Die Einstellung SetCredential= ist ähnlich zu LoadCredential=,
           akzeptiert aber einen buchstäblichen Wert, der als Daten für die
           Zugangsdaten 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 Zugangsdaten einzubetten,
           verwenden Sie C-artige Maskierungen (d.h. »\n«, um einen
           Zeilenumbruch einzubetten oder »\x00«, um ein NUL-Byte einzubetten).

           Falls ein Zugangsdatum mit der gleichen Kennung sowohl in
           LoadCredential= als auch in SetCredential= aufgeführt ist, dann wird
           letzteres als Vorgabe agieren, falls ersteres nicht abgefragt werden
           kann. In diesem Fall wird der Fehlschlag, das in LoadCredential=
           festgelegte Zugangsdatum nicht abfragen zu können, nicht als fatal
           betrachtet.

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

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

       The general philosophy is to expose a small curated list of environment
       variables to processes. Services started by the system manager (PID 1)
       will be started, without additional service-specific configuration, with
       just a few environment variables. The user manager inherits environment
       variables as any other system service, but in addition may receive
       additional environment variables from PAM, and, typically, additional
       imported variables when the user starts a graphical session. It is
       recommended to keep the environment blocks in both the system and user
       managers managers lean.

       Hint: systemd-run -P env and systemd-run --user -P env print the
       effective system and user service environment blocks.

   Environment Variables Set or Propagated by the Service Manager
       The following environment variables are propagated by the service manager
       or generated internally for each invoked process:

       $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. Wird dies auf Systemen mit »nicht zusammengeführtem
           /usr/« (/bin ist kein Symlink auf /usr/bin) kompiliert, wird
           »:/sbin:/bin« angehängt. 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.

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

       $USER, $LOGNAME, $HOME, $SHELL
           Benutzername (zweifach), Home-Verzeichnis und die Anmelde-Shell. Die
           Variablen sind für die Units, die User= gesetzt haben, gesetzt, dazu
           gehören Benutzer-systemd-Instanzen. Siehe passwd(5).

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

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

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

       $CREDENTIALS_DIRECTORY
           Ein absoluter Pfad zu einem Unit-spezifischen Verzeichnis mit
           Zugangsdaten, die mittels 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).

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

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

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

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

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

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

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

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

       $SERVICE_RESULT
           Diese Variable, die nur für den Dienste-Unit-Typ definiert ist, 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
           ┌──────────────────┬─────────────────────────────┐
           │Wert              Bedeutung                   │
           ├──────────────────┼─────────────────────────────┤
           │"Erfolg"          │ Der Dienst lief erfolgreich │
           │                  │ und beendete sich           │
           │                  │ ordnungsgemäß.              │
           ├──────────────────┼─────────────────────────────┤
           │"protocol"        │ Das Protokoll wurde         │
           │                  │ verletzt: der Dienst hat    │
           │                  │ nicht die von seiner        │
           │                  │ Unit-Konfiguration          │
           │                  │ verlangten Schritte         │
           │                  │ absolviert (insbesondere    │
           │                  │ was in der Einstellung      │
           │                  │ Type= konfiguriert wurde).  │
           ├──────────────────┼─────────────────────────────┤
           │"timeout"         │ Einer der Schritte hat die  │
           │                  │ Zeit überschritten.         │
           ├──────────────────┼─────────────────────────────┤
           │"exit-code"       │ Diensteprozess hat sich mit │
           │                  │ einen von Null              │
           │                  │ verschiedenen Exit-Code     │
           │                  │ beendet; siehe $EXIT_CODE   │
           │                  │ unten für den tatsächlich   │
           │                  │ zurückgelieferten           │
           │                  │ Exit-Code.                  │
           ├──────────────────┼─────────────────────────────┤
           │"signal"          │ Ein Diensteprozess wurde    │
           │                  │ durch ein Signal            │
           │                  │ regelwidrig beendet; ohne   │
           │                  │ einen Speicherauszug. Siehe │
           │                  │ $EXIT_CODE unten für das    │
           │                  │ tatsächliche Signal, das    │
           │                  │ die Beendigung auslöste.    │
           ├──────────────────┼─────────────────────────────┤
           │"core-dump"       │ Ein Diensteprozess wurde    │
           │                  │ durch ein Signal            │
           │                  │ regelwidrig beendet und hat │
           │                  │ einen Speicherauszug        │
           │                  │ ausgegeben. Siehe           │
           │                  │ $EXIT_CODE unten für das    │
           │                  │ Signal, das die Beendigung  │
           │                  │ auslöste.                   │
           ├──────────────────┼─────────────────────────────┤
           │"watchdog"        │ Der Totmannschalter des     │
           │                  │ Watchdogs war für diesen    │
           │                  │ Dienst aktiviert, aber die  │
           │                  │ Frist wurde verpasst.       │
           ├──────────────────┼─────────────────────────────┤
           │"start-limit-hit" │ Für die Unit war eine       │
           │                  │ Startbegrenzung definiert   │
           │                  │ und wurde erreicht, wodurch │
           │                  │ der Start der Unit          │
           │                  │ fehlschlug. Siehe           │
           │                  │ StartLimitIntervalSec= und  │
           │                  │ StartLimitBurst= von        │
           │                  │ systemd.unit(5) für         │
           │                  │ Details.                    │
           ├──────────────────┼─────────────────────────────┤
           │"resources"       │ Eine Auffangbedingung,      │
           │                  │ falls eine Systemaktion     │
           │                  │ fehlschlug.                 │
           └──────────────────┴─────────────────────────────┘
           Diese Umgebungsvariable ist nützlich, um den Fehlschlag oder die
           erfolgreiche Beendigung eines Dienstes zu überwachen. Obwohl diese
           Variable sowohl in ExecStop= als auch ExecStopPost= verfügbar ist,
           ist es normalerweise eine bessere Wahl, die Überwachungswerkzeuge in
           Letzterer zu platzieren, da Erstere nur für Dienste aufgerufen wird,
           die ihren Start korrekt verwaltet haben und Letztere sowohl Dienste
           abdeckt, die während ihres Startens fehlschlugen als auch solche, die
           während ihrer Laufzeit fehlschlugen.

       $EXIT_CODE, $EXIT_STATUS
           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.     │
           └─────────────────────────────────────────────────────────────┘

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

       Für Systemdienste können zusätzliche, durch Systemd definierte
       Umgebungsvariablen für Dienste gesetzt werden, wenn PAMName= aktiviert
       und pam_systemd Teil des ausgewählten PAM-Stacks ist. Dies sind
       insbesondere $XDG_SEAT und $XDG_VTNR, siehe pam_systemd(8) für Details.

PROZESS-EXIT-CODES
       Beim Aufruf eines Unit-Prozesses könnte der Diensteverwalter
       möglicherweise nicht in der Lage sein, die mit den oben dargestellten
       Einstellungen konfigurierten Ausführungsparameter zu setzen. In diesem
       Fall wird sich der bereits erstellte Diensteprozess mit einem von Null
       verschiedenen Exit-Code beenden, bevor die konfigurierte Befehlszeile
       ausgeführt wird. (Oder, mit anderen Worten, der Kindprozess hat sich mit
       diesen Fehler-Codes beendet, nachdem er mit dem Systemaufruf fork(2)
       erstellt wurde, aber bevor der zugehörige Systemaufruf execve(2)
       erfolgte.)  Insbesondere werden die durch die C-Bibliothek, die
       LSB-Spezifikation und durch den Systemd-Diensteverwalter selbst
       definierten Exit-Codes verwandt.

       Die folgenden grundlegenden Dienste-Exit-Codes sind durch die
       C-Bibliothek definiert.

       Tabelle 7. Grundlegende Exit-Codes der C-Bibliothek
       ┌──────────┬───────────────────┬──────────────────┐
       │Exit-Code Symbolischer Name Beschreibung     │
       ├──────────┼───────────────────┼──────────────────┤
       │0         │ EXIT_SUCCESS      │ Generischer      │
       │          │                   │ Erfolgs-Code.    │
       ├──────────┼───────────────────┼──────────────────┤
       │1         │ EXIT_FAILURE      │ Generischer      │
       │          │                   │ Fehlschlag oder  │
       │          │                   │ unspezifizierter │
       │          │                   │ Fehler.          │
       └──────────┴───────────────────┴──────────────────┘

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

       Tabelle 8. LSB-Dienste-Exit-Codes
       ┌──────────┬──────────────────────┬──────────────────────┐
       │Exit-Code Symbolischer Name    Beschreibung         │
       ├──────────┼──────────────────────┼──────────────────────┤
       │2         │ EXIT_INVALIDARGUMENT │ Ungültige oder       │
       │          │                      │ überzählige          │
       │          │                      │ Argumente.           │
       ├──────────┼──────────────────────┼──────────────────────┤
       │3         │ EXIT_NOTIMPLEMENTED  │ Nicht implementierte │
       │          │                      │ Funktionalität.      │
       ├──────────┼──────────────────────┼──────────────────────┤
       │4         │ EXIT_NOPERMISSION    │ Der Benutzer hat     │
       │          │                      │ nicht genug          │
       │          │                      │ Privilegien.         │
       ├──────────┼──────────────────────┼──────────────────────┤
       │5         │ EXIT_NOTINSTALLED    │ Das Programm ist     │
       │          │                      │ nicht installiert.   │
       ├──────────┼──────────────────────┼──────────────────────┤
       │6         │ EXIT_NOTCONFIGURED   │ Das Programm ist     │
       │          │                      │ nicht konfiguriert.  │
       ├──────────┼──────────────────────┼──────────────────────┤
       │7         │ EXIT_NOTRUNNING      │ Das Programm läuft   │
       │          │                      │ nicht.               │
       └──────────┴──────────────────────┴──────────────────────┘

       Die LSB-Spezifikation schlägt vor, dass Fehler-Code 200 und höher für
       Implementierungen reserviert ist. Einige von ihnen werden vom
       Diensteverwalter benutzt, um Probleme beim Aufrufen von Prozessen
       anzuzeigen.

       Tabelle 9. Systemd-spezifische Exit-Codes
       ┌──────────┬──────────────────────────────┬─────────────────────────────────────────────┐
       │Exit-Code Symbolischer Name            Beschreibung                                │
       ├──────────┼──────────────────────────────┼─────────────────────────────────────────────┤
       │200       │ EXIT_CHDIR                   │ Änderung des                                │
       │          │                              │ angeforderten                               │
       │          │                              │ Arbeitsverzeichnisses                       │
       │          │                              │ schlug fehl. Siehe                          │
       │          │                              │ WorkingDirectory=                           │
       │          │                              │ oben.                                       │
       ├──────────┼──────────────────────────────┼─────────────────────────────────────────────┤
       │201       │ EXIT_NICE                    │ Scheduling-Priorität                        │
       │          │                              │ (Nice-Stufe) konnte                         │
       │          │                              │ nicht gesetzt werden.                       │
       │          │                              │ Siehe Nice= oben.                           │
       ├──────────┼──────────────────────────────┼─────────────────────────────────────────────┤
       │202       │ EXIT_FDS                     │ Ungewünschter                               │
       │          │                              │ Dateideskriptor                             │
       │          │                              │ konnte nicht                                │
       │          │                              │ geschlossen werden                          │
       │          │                              │ oder übergebene                             │
       │          │                              │ Dateideskriptoren                           │
       │          │                              │ konnten nicht                               │
       │          │                              │ angepasst werden.                           │
       ├──────────┼──────────────────────────────┼─────────────────────────────────────────────┤
       │203       │ EXIT_EXEC                    │ Die tatsächliche                            │
       │          │                              │ Ausführung des                              │
       │          │                              │ Prozesses schlug fehl                       │
       │          │                              │ (genauer, der                               │
       │          │                              │ Systemaufruf                                │
       │          │                              │ execve(2)).                                 │
       │          │                              │ Höchstwahrscheinlich                        │
       │          │                              │ wird dies durch ein                         │
       │          │                              │ fehlendes oder nicht                        │
       │          │                              │ zugreifbares Programm                       │
       │          │                              │ hervorgerufen.                              │
       ├──────────┼──────────────────────────────┼─────────────────────────────────────────────┤
       │204       │ EXIT_MEMORY                  │ Aufgrund von                                │
       │          │                              │ Speicherknappheit                           │
       │          │                              │ konnte eine Aktion                          │
       │          │                              │ nicht durchgeführt                          │
       │          │                              │ werden.                                     │
       ├──────────┼──────────────────────────────┼─────────────────────────────────────────────┤
       │205       │ EXIT_LIMITS                  │ Ressourcenbegrenzungen                      │
       │          │                              │ konnten nicht                               │
       │          │                              │ angepasst werden.                           │
       │          │                              │ Siehe LimitCPU= und                         │
       │          │                              │ verwandte                                   │
       │          │                              │ Einstellungen oben.                         │
       ├──────────┼──────────────────────────────┼─────────────────────────────────────────────┤
       │206       │ EXIT_OOM_ADJUST              │ OOM-Einstellungen                           │
       │          │                              │ konnten nicht                               │
       │          │                              │ angepasst werden.                           │
       │          │                              │ Siehe OOMScoreAdjust=                       │
       │          │                              │ oben.                                       │
       ├──────────┼──────────────────────────────┼─────────────────────────────────────────────┤
       │207       │ EXIT_SIGNAL_MASK             │ Prozesssignalmaske                          │
       │          │                              │ konnte nicht gesetzt                        │
       │          │                              │ werden.                                     │
       ├──────────┼──────────────────────────────┼─────────────────────────────────────────────┤
       │208       │ EXIT_STDIN                   │ Standardeingabe konnte                      │
       │          │                              │ nicht gesetzt werden.                       │
       │          │                              │ Siehe StandardInput=                        │
       │          │                              │ oben.                                       │
       ├──────────┼──────────────────────────────┼─────────────────────────────────────────────┤
       │209       │ EXIT_STDOUT                  │ Standardausgabe konnte                      │
       │          │                              │ nicht gesetzt werden.                       │
       │          │                              │ Siehe StandardOutput=                       │
       │          │                              │ oben.                                       │
       ├──────────┼──────────────────────────────┼─────────────────────────────────────────────┤
       │210       │ EXIT_CHROOT                  │ Wurzelverzeichnis                           │
       │          │                              │ konnte nicht geändert                       │
       │          │                              │ werden (chroot(2)).                         │
       │          │                              │ Siehe                                       │
       │          │                              │ RootDirectory=/RootImage=                   │
       │          │                              │ oben.                                       │
       ├──────────┼──────────────────────────────┼─────────────────────────────────────────────┤
       │211       │ EXIT_IOPRIO                  │ E/A-Scheduling-Priorität                    │
       │          │                              │ konnte nicht gesetzt                        │
       │          │                              │ werden. Siehe                               │
       │          │                              │ IOSchedulingClass=/IOSchedulingPriority=    │
       │          │                              │ oben.                                       │
       ├──────────┼──────────────────────────────┼─────────────────────────────────────────────┤
       │212       │ EXIT_TIMERSLACK              │ Der Timer-Spielraum konnte nicht            │
       │          │                              │ eingerichtet werden. Siehe                  │
       │          │                              │ TimerSlackNSec= oben.                       │
       ├──────────┼──────────────────────────────┼─────────────────────────────────────────────┤
       │213       │ EXIT_SECUREBITS              │ Prozess-Sicherheits-Bits konnten nicht      │
       │          │                              │ gesetzt werden. Siehe SecureBits= oben.     │
       ├──────────┼──────────────────────────────┼─────────────────────────────────────────────┤
       │214       │ EXIT_SETSCHEDULER            │ CPU-Scheduling konnte nicht eingerichtet    │
       │          │                              │ werden. Siehe                               │
       │          │                              │ CPUSchedulingPolicy=/CPUSchedulingPriority= │
       │          │                              │ oben.                                       │
       ├──────────┼──────────────────────────────┼─────────────────────────────────────────────┤
       │215       │ EXIT_CPUAFFINITY             │ CPU-Affinität konnte nicht eingerichtet     │
       │          │                              │ werden. Siehe CPUAffinity= oben.            │
       ├──────────┼──────────────────────────────┼─────────────────────────────────────────────┤
       │216       │ EXIT_GROUP                   │ Gruppen-Zugangsdaten konnten nicht bestimmt │
       │          │                              │ oder geändert werden. Siehe                 │
       │          │                              │ Group=/SupplementaryGroups= oben.           │
       ├──────────┼──────────────────────────────┼─────────────────────────────────────────────┤
       │217       │ EXIT_USER                    │ Benutzer-Zugangsdaten 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ängenamensräume konnten nicht           │
       │          │                              │ eingerichtet werden. Siehe ReadOnlyPaths=   │
       │          │                              │ 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             │ Zugangsdaten der Unit konnten nicht         │
       │          │                              │ eingerichtet werden. Siehe LoadCredential=  │
       │          │                              │ und SetCredential= oben.                    │
       └──────────┴──────────────────────────────┴─────────────────────────────────────────────┘

       Schließlich definieren die BSD-Betriebssysteme eine Reihe von Exit-Codes,
       die typischerweise auch auf Linux-Systemen definiert sind:

       Tabelle 10. BSD-Exit-Codes
       ┌──────────┬───────────────────┬───────────────────────────────┐
       │Exit-Code Symbolischer Name Beschreibung                  │
       ├──────────┼───────────────────┼───────────────────────────────┤
       │64        │ EX_USAGE          │ Befehlszeilenbenutzungsfehler │
       ├──────────┼───────────────────┼───────────────────────────────┤
       │65        │ EX_DATAERR        │ Datenformatfehler             │
       ├──────────┼───────────────────┼───────────────────────────────┤
       │66        │ EX_NOINPUT        │ Eingabe kann nicht geöffnet   │
       │          │                   │ werden                        │
       ├──────────┼───────────────────┼───────────────────────────────┤
       │67        │ EX_NOUSER         │ Empfängerin unbekannt         │
       ├──────────┼───────────────────┼───────────────────────────────┤
       │68        │ EX_NOHOST         │ Rechnername unbekannt         │
       ├──────────┼───────────────────┼───────────────────────────────┤
       │69        │ EX_UNAVAILABLE    │ Dienst nicht verfügbar        │
       ├──────────┼───────────────────┼───────────────────────────────┤
       │70        │ EX_SOFTWARE       │ interner Softwarefehler       │
       ├──────────┼───────────────────┼───────────────────────────────┤
       │71        │ EX_OSERR          │ Systemfehler (z.B. Fork kann  │
       │          │                   │ nicht ausgeführt werden)      │
       ├──────────┼───────────────────┼───────────────────────────────┤
       │72        │ EX_OSFILE         │ kritische Betriebssystemdatei │
       │          │                   │ fehlt                         │
       ├──────────┼───────────────────┼───────────────────────────────┤
       │73        │ EX_CANTCREAT      │ (Benutzer)-Ausgabedatei kann  │
       │          │                   │ nicht erstellt werden         │
       ├──────────┼───────────────────┼───────────────────────────────┤
       │74        │ EX_IOERR          │ Eingabe/Ausgabe-Fehler        │
       ├──────────┼───────────────────┼───────────────────────────────┤
       │75        │ EX_TEMPFAIL       │ Temporärer Fehlschlag,        │
       │          │                   │ Benutzer sollte es noch       │
       │          │                   │ einmal versuchen              │
       ├──────────┼───────────────────┼───────────────────────────────┤
       │76        │ EX_PROTOCOL       │ Ferner Fehler im Protokoll    │
       ├──────────┼───────────────────┼───────────────────────────────┤
       │77        │ EX_NOPERM         │ Erlaubnis verweigert          │
       ├──────────┼───────────────────┼───────────────────────────────┤
       │78        │ EX_CONFIG         │ Konfigurationsfehler          │
       └──────────┴───────────────────┴───────────────────────────────┘

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://systemd.io/DISCOVERABLE_PARTITIONS

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

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

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

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

        6. proc.txt
           https://www.kernel.org/doc/Documentation/filesystems/proc.txt

        7. C-Maskierungen
           https://en.wikipedia.org/wiki/Escape_sequences_in_C#Table_of_escape_sequences

        8. die meisten Steuerzeichen
           https://en.wikipedia.org/wiki/Control_character#In_ASCII

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

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



systemd 247                                                      SYSTEMD.EXEC(5)