BEZEICHNUNG¶
systemd-system.conf, system.conf.d, systemd-user.conf, user.conf.d
- System- und Sitzungsserviceverwalter-Konfigurationsdateien
ÜBERSICHT¶
/etc/systemd/system.conf, /run/systemd/system.conf,
/usr/lib/systemd/system.conf, /etc/systemd/system.conf.d/*.conf,
/run/systemd/system.conf.d/*.conf, /usr/lib/systemd/system.conf.d/*.conf
~/.config/systemd/user.conf, /etc/systemd/user.conf,
/run/systemd/user.conf, /usr/lib/systemd/user.conf,
/etc/systemd/user.conf.d/*.conf, /run/systemd/user.conf.d/*.conf,
/usr/lib/systemd/user.conf.d/*.conf
BESCHREIBUNG¶
Wird systemd als Systeminstanz ausgeführt,
interpretiert es die Konfigurationsdatei system.conf und die Dateien in
system.conf.d-Verzeichnissen; wird es als Benutzerinstanz ausgeführt,
interpretiert es die Konfigurationsdatei user.conf (in der
Prioritätsreihenfolge, im Home-Verzeichnis des Benutzers und unter
/etc/systemd/, /run/systemd/ und /usr/lib/systemd/) und die Dateien in
user.conf.d-Verzeichnissen. Diese Konfigurationsdateien enthalten ein paar
Einstellungen, die grundlegende Verwaltungsaktionen steuern.
Siehe systemd.syntax(7) für eine allgemeine
Beschreibung der Syntax.
KONFIGURATIONSVERZEICHNISSE UND RANGFOLGE¶
Die Standardkonfiguration wird während der Kompilierung
gesetzt. Daher wird eine Konfiguration nur benötigt, wenn von diesen
Vorgaben abgewichen werden muss. Die Hauptkonfigurationsdatei wird aus einem
der aufgeführten Verzeichnisse in der Prioritätsreihenfolge
geladen, nur die zuerst gefundene Datei wird verwandt: /etc/systemd/,
/run/systemd/, /usr/local/lib/systemd/ [1], /usr/lib/systemd/. Die
Lieferantenversion der Datei enthält die Vorgaben als auskommentierte
Hinweise für den Administrator. Lokal können diese
Einstellungen durch die Erstellung von Ergänzungen, wie nachfolgend
beschrieben, außer Kraft gesetzt werden. Zu diesem Zweck kann die
Hauptkonfigurationsdatei (oder eine Kopie in /etc/, falls sie in /usr/
ausgeliefert wird) auch bearbeitet werden, allerdings wird empfohlen,
Ergänzungen für lokale Konfiguration zu verwenden, statt die
Hauptkonfigurationsdatei zu verändern.
Zusätzlich zu der Hauptkonfigurationsdatei, werden
Ergänzungs-Konfigurationsschnipsel aus /usr/lib/systemd/*.conf.d/,
/usr/local/lib/systemd/*.conf.d/ und /etc/systemd/*.conf.d/ gelesen. Diese
Ergänzungen haben Vorrang vor der Hauptkonfigurationsdatei und setzen
diese außer Kraft. Dateien in den Konfigurationsunterverzeichnissen
*.conf.d/ werden in lexikographischer Reihenfolge nach ihrem Dateinamen
sortiert, unabhängig davon, in welchem Unterverzeichnis sie sich
befinden. Bei Optionen, die nur einen einzelnen Wert akzeptieren, hat der
Eintrag in der Datei, die als letztes in der Sortierung folgt, Vorrang,
falls mehrere Dateien die gleiche Option angeben. Bei Optionen, die eine
Liste von Werten akzeptieren, werden Einträge gesammelt, wie sie in
den sortierten Dateien auftauchen.
Wenn Pakete die Konfiguration anpassen müssen,
können sie Ergänzungen unter /usr/ installieren. Dateien in
/etc/ sind für den lokalen Administrator reserviert, der diese Logik
verwenden kann, um die durch die Lieferantenpakete bereitgestellten
Konfigurationsdateien außer Kraft zu setzen. Um Ergänzungen
der Pakete außer Kraft zu setzen, müssen Ergänzungen
verwandt werden, da die Hauptkonfigurationsdatei die niedrigste
Priorität hat. Es wird empfohlen, allen Dateinamen in diesen
Unterverzeichnissen eine zweistellige Zahl und einen Bindestrich
voranzustellen, um die Sortierung zu vereinfachen. Dies definiert auch ein
Konzept von Ergänzungsprioritäten, um es
Betriebssystemlieferanten zu ermöglichen, Ergänzungen in einem
bestimmten Bereich auszuliefern, der unterhalb des von Benutzern verwandten
Bereichs liegt. Dies sollte das Risiko reduzieren, dass eine
Paketergänzung versehentlich durch Benutzer definierte
Ergänzungen außer Kraft setzt. Es wird empfohlen, den Bereich
10-40 für Ergänzungen in /usr/ und den Bereich 60-90
für Ergänzungen in /etc/ und /run/ zu verwenden um
sicherzustellen, dass lokale und flüchtige Ergänzungen
Priorität gegenüber Ergänzungen haben, die vom
Betriebssystemlieferanten geliefert werden.
Um eine vom Lieferanten bereitgestellte Konfigurationsdatei zu
deaktivieren, wird empfohlen, einen Symlink nach /dev/null in dem
Konfigurationsverzeichnis in /etc/ mit dem gleichen Dateinamen wie die
Konfigurationsdatei des Lieferanten abzulegen.
OPTIONEN¶
Alle Optionen werden im Abschnitt »[Manager]«
konfiguriert:
LogColor=, LogLevel=, LogLocation=,
LogTarget=, LogTime=, DumpCore=yes,
CrashChangeVT=no, CrashShell=no, CrashAction=freeze,
ShowStatus=yes, DefaultStandardOutput=journal,
DefaultStandardError=inherit
Konfigurieren verschiedene Parameter grundlegender
Verwaltungsaktionen. Diese Optionen können durch die
Befehlszeilenargumente des betreffenden Prozesses und des Kernels außer
Kraft gesetzt werden. Siehe
systemd(1) für Details.
Hinzugefügt in Version 198.
CtrlAltDelBurstAction=
Definiert, welche Aktionen ausgeführt werden,
falls der Benutzer Strg-Alt-Entf mehr als sieben Mal in 2 s drückt.
Kann auf »reboot-force«, »poweroff-force«,
»reboot-immediate«, »poweroff-immediate« gesetzt
oder mittels »none« deaktiviert werden.
Standardmäßig »reboot-force«.
Hinzugefügt in Version 232.
StatusUnitFormat=
Akzeptiert
name,
description oder
combined als Wert. Falls
name, wird der Systemverwalter
Unit-Namen (z.B. »systemd-journald.service«) statt der
längeren und aussagefähigeren, mit
Description= gesetzten
Beschreibungen (z.B. »Journal Logging Service«) in
Statusmeldungen verwenden. Falls
combined, wird der Systemverwalter
sowohl Unit-Namen als auch Beschreibungen in Stausmeldungen verwenden (z.B.
»systemd-journald.service - Journal Logging Service«).
Siehe systemd.syntax(5) für Details über
Unit-Namen und Description=.
Hinzugefügt in Version 243.
DefaultTimerAccuracySec=
Setzt die Standardgenauigkeit der Timer-Units. Dies
steuert die globale Voreinstellung für die Einstellung
AccuracySec= von Timer-Units, siehe
systemd.timer(5) für
Details.
AccuracySec=-Einstellungen in individuellen Units setzen die
globale Vorgabe für die bestimmte Unit außer Kraft.
Standardmäßig 1 Minute. Beachten Sie, dass die Genauigkeit der
Timer-Units auch von dem Timer-Spielraum beeinflusst wird, siehe
TimerSlackNSec= oben.
Hinzugefügt in Version 212.
RESSOURCENVERWALTUNG¶
TimerSlackNSec=
Setzt den Timer-Spielraum in Nanosekunden für PID
1, der von allen ausgeführten Prozessen geerbt wird, außer er
wird individuell außer Kraft gesetzt, beispielsweise mit der
Einstellung
TimerSlackNSec= in Dienste-Units (für Details siehe
systemd.exec(5)). 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.
Hinzugefügt in Version 198.
CPUAffinity=
Konfiguriert die CPU-Affinität für den
Diensteverwalter sowie die Vorgabe-CPU-Affinität für alle mit
Fork erstellten Prozesse. Erhält eine Liste von CPU-Indizes oder
Bereichen, die entweder durch Leerraum oder Kommata getrennt sind.
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 CPU-Affinitätsmasken
zusammengeführt. Falls die leere Zeichenkette zugewiesen wird, wird die
Maske zurückgesetzt, alle vorherigen Zuweisungen haben keine Wirkung.
Individuelle Dienste können die CPU-Affinität für ihre
Prozesse mit der Einstellung
CPUAffinity= in Unit-Dateien außer
Kraft setzen, siehe
systemd.exec(5).
Hinzugefügt in Version 198.
NUMAPolicy=
Konfiguriert die NUMA-Speicherrichtlinie für den
Diensteverwalter und die Vorgabe-NUMA-Speicherrichtlinie für alle mit
Fork gestarteten Prozesse. Individuelle Dienste können die
Vorgaberichtlinie mit der Einstellung
NUMAPolicy= in Unit-Dateien
außer Kraft setzen, siehe
systemd.exec(5).
Hinzugefügt in Version 243.
NUMAMask=
Konfiguriert die NUMA-Knotenmaske, die der
ausgewählten NUMA-Richtlinie zugeordnet wird. Beachten Sie, dass die
NUMA-Richtlinien
default und
local keine expliziten
NUMA-Knotenmasken benötigen und der Wert dieser Option leer sein kann.
Ähnlich zu
NUMAPolicy= kann dieser Wert durch individuelle
Dienste in Unit-Dateien außer Kraft gesetzt werden, siehe
systemd.exec(5).
Hinzugefügt in Version 243.
DefaultCPUAccounting=, DefaultMemoryAccounting=,
DefaultTasksAccounting=, DefaultIOAccounting=,
DefaultIPAccounting=
Konfiguriert die
Vorgabe-Ressourcen-Buchhaltungseinstellungen, wie Unit-bezogen mittels
CPUAccounting=,
MemoryAccounting=,
TasksAccounting=,
IOAccounting= und
IPAccounting= konfiguriert. Siehe
systemd.resource-control(5) zu Details Unit-bezogener Einstellungen.
DefaultCPUAccounting= ist bei der Ausführung auf
Kerneln ≥4.15 standardmäßig »yes« und
»no« auf älteren Versionen.
DefaultMemoryAccounting= ist standardmäßig
»yes«. DefaultTasksAccounting= ist
standardmäßig »yes«. Die anderen Einstellungen
sind standardmäßig »no«.
Hinzugefügt in Version 211.
DefaultTasksMax=
Konfiguriert die Vorgabewerte der
TasksMax=-Einstellungen für jede Unit. Siehe
systemd.resource-control(5) für Details. Diese Einstellung wird
auf alle Unit-Typen, die Ressourcensteuerungseinstellungen
unterstützen, mit der Ausnahme von Scheiben-Units, angewandt.
Standardmäßig 15% der minimalen
kernel.pid_max=,
kernel.threads-max= und der Wurzel-Cgroup
pids.max. Der Kernel
hat einen Vorgabewert für
kernel.pid_max= und einen
Zählalgorithmus, falls er mehr als 32 Kerne antrifft. Mit der
standardmäßigen
kernel.pid_max= ist die Vorgabe
für
DefaultTasksMax= 4915, aber sie kann auf anderen Systemen
größer und in Betriebssystem-Containern kleiner sein.
Hinzugefügt in Version 228.
DefaultLimitCPU=, DefaultLimitFSIZE=,
DefaultLimitDATA=, DefaultLimitSTACK=,
DefaultLimitCORE=, DefaultLimitRSS=,
DefaultLimitNOFILE=, DefaultLimitAS=,
DefaultLimitNPROC=, DefaultLimitMEMLOCK=,
DefaultLimitLOCKS=, DefaultLimitSIGPENDING=,
DefaultLimitMSGQUEUE=, DefaultLimitNICE=,
DefaultLimitRTPRIO=, DefaultLimitRTTIME=
Diese Einstellungen steuern verschiedene
Vorgaberessourcenbeschränkungen für von Units ausgeführte
Prozesse. Siehe
setrlimit(2) für Details. Diese Einstellungen
können in individuellen Units mittels der entsprechenden
LimitXXX=-Direktiven außer Kraft gesetzt werden und sie
akzeptieren die gleiche Parametersyntax, siehe
systemd.exec(5)
für Details. Beachten Sie, dass diese Ressourcenbeschränkungen
nur die Vorgaben für die Units sind, sie werden nicht auf den
Diensteverwalterprozess (d.h. PID 1) selbst angewandt.
Die meisten dieser Einstellungen sind nicht gesetzt, was bedeutet,
dass Ressourcenbegrenzungen von dem Kernel oder, falls innerhalb eines
Containers, vom Container-Verwalter ererbt werden. Die Folgenden haben
allerdings Standardwerte:
•DefaultLimitNOFILE= ist
standardmäßig »1024:524288«.
•DefaultLimitMEMLOCK= ist
standardmäßig 8M.
•DefaultLimitCORE= hat keine Vorgabe, aber
es lohnt sich zu erwähnen, dass RLIMIT_CORE durch PID1 auf
»infinity« gesetzt wird, was von seinen Kindprogrammen ererbt
wird.
Beachten Sie, dass der Diensteverwalter intern in PID 1
RLIMIT_NOFILE und RLIMIT_MEMLOCK auf höhere Werte
erhöht; die Beschränkung wird allerdings für alle per
Fork erzeugten Kindprozesse auf die angegeben Vorgaben
zurückgesetzt.
Hinzugefügt in Version 198.
DefaultOOMPolicy=
Konfiguriert die Standardrichtlinie für die
Reaktion auf Prozesse, die durch den Speicherknappheits- (OOOM-)Killer von
Linux oder
systemd-oomd getötet werden. Dies kann zur Auswahl
einer globalen Vorgabe für die Unit-bezogene Einstellung
OOMPolicy= verwandt werden. Siehe
systemd.service(5) für
Details. Beachten Sie, dass diese Vorgabe für Dienste, die
Delegate= eingeschaltet haben, nicht verwandt wird.
Hinzugefügt in Version 243.
DefaultOOMScoreAdjust=
Konfiguriert die Standard-OOM-Bewertungsanpassung
für vom Diensteverwalter ausgeführte Prozesse.
Standardmäßig nicht gesetzt (was bedeutet, dass mit Fork
gestartete Prozesse die OOM-Bewertungsanpassung vom Diensteverwalter erben),
außer falls der Diensteverwalter für einen nichtprivilegierten
Benutzer ausgeführt wird, dann ist die Vorgabe die
OOM-Bewertungsanpassung vom Diensteverwalter plus 100 (wodurch der
Diensteprozess etwas wahrscheinlicher unter Speicherdruck beendet wird als der
Verwalter selbst). Dies kann zum Auswählen einer globalen Vorgabe
für die Unit-bezogene Einstellung
OOMScoreAdjust= verwandt
werden. Siehe
systemd.exec(5) für Details. Beachten Sie, dass
diese Einstellung keine Auswirkung auf den
Standard-OOM-Bewertungsanpassungswert des Diensteverwalters selbst hat, er
behält den ursprünglichen Wert, der während des Aufrufs
gesetzt wurde.
Hinzugefügt in Version 250.
DefaultMemoryPressureWatch=,
DefaultMemoryPressureThresholdSec=
Konfiguriert die Standardeinstellungen für die
Unit-bezogenen Einstellungen
MemoryPressureWatch= und
MemoryPressureThresholdSec=. Siehe
systemd.resource-control(5)
zu Details. Standardmäßig »auto« bzw.
»200ms«. Dies setzt auch den Schwellwert für die
Überwachung des Speicherdrucks für den Diensteverwalter selbst.
Hinzugefügt in Version 254.
HARDWARE-WATCHDOG¶
RuntimeWatchdogSec=, RebootWatchdogSec=,
KExecWatchdogSec=
Konfiguriert den Hardware-Watchdog zur Laufzeit und beim
Systemstart. Akzeptiert einen Zeitüberschreitungswert in Sekunden (oder
anderen Zeiteinheiten, falls »ms«, »min«,
»h«, »d«, »w« angehängt wird)
oder die besondere Zeichenkette »off« oder
»default«. Falls auf »off« gesetzt (alternativ
»0«), wird die Watchdog-Logik deaktiviert: Es wird kein
Watchdog-Gerät geöffnet, konfiguriert oder angesprochen. Falls
auf die besondere Zeichenkette »default« gesetzt, wird der
Watchdog geöffnet und in regelmäßigen Intervallen
angesprochen, aber die Zeitüberschreitung wird nicht von der Vorgabe
geändert. Falls auf einen anderen Zeitwert gesetzt, wird die
Watchdog-Zeitüberschreitung auf den festgelegten Werte konfiguriert
(oder einen Wert in der Nähe, abhängig von den
Hardware-Fähigkeiten).
Falls RuntimeWatchdogSec= auf einen von Null verschiedenen
Wert gesetzt wird, wird die Watchdog-Hardware (/dev/watchdog0 oder der mit
WatchdogDevice= oder der mit der Kerneloption
systemd.watchdog_device= festgelegte Pfad) programmiert, das System
automatisch neu zu starten, falls sie nicht innerhalb des festgelegten
Zeitüberschreitungsintervalls kontaktiert wird. Diese
Funktionalität benötigt die Existenz eines
Watchdog-Gerätes, wie dies bei eingebetteten und Server-Systemen
häufig der Fall ist. Nicht alle Hardware-Watchdogs erlauben die
Konfiguration aller möglichen
Neustart-Zeitüberschreitungswerte – dann wird der naheste
verfügbare Zeitüberschreitungswert ausgewählt.
RebootWatchdogSec= kann zur Konfiguration des
Hardware-Watchdogs verwandt werden, wenn das System um einen Neustart
gebeten wird. Es funtioniert als Sicherheitsnetz, um sicherzustellen, dass
der Neustart sogar dann stattfindet, falls ein sauberer Neustartversuch
wegen einer Zeitüberschreitung nicht stattfindet. Beachten Sie, dass
die Zeitüberschreitung RebootWatchdogSec= nur für die
zweite Phase des Systemneustarts angewandt wird, d.h. nachdem alle
regulären Dienste bereits beendet wurden und nachdem der System- und
Diensteverwalterprozess (PID 1) durch das System-Herunterfahrprogramm
ersetzt wurde, siehe bootup(7) für Details. Während der
ersten Phase der Herunterfahr-Aktion bleibt der System- und Diensteverwalter
am Laufen und daher wird RuntimeWatchdogSec= weiterhin
gewürdigt. Um eine Zeitüberschreitung in dieser ersten Phase
des System-Herunterfahrens zu definieren, konfigurieren Sie
JobTimeoutSec= und JobTimeoutAction= in dem Abschnitt
»[Unit]« von shutdown.target unit. Standardmäßig
beträgt RuntimeWatchdogSec= 0 (off) und
RebootWatchdogSec= 10min.
KExecWatchdogSec= kann zur zusätzlichen Aktivierung
des Watchdogs verwandt werden, wenn kexec statt eines Systemneustarts
ausgeführt wird. Beachten Sie, dass in diesem Fall der Watchdog nicht
nach dem kexec deaktiviert werden könnte, falls der Kernel den
Watchdog beim kexec nicht zurücksetzt (abhängig von der
spezifischen Hardware und/oder Treiber) und daher das System neu gestartet
werden könnte, außer wenn RuntimeWatchdogSec=
gleichzeitig auch aktiviert ist. Aus diesem Grund wird empfohlen,
KExecWatchdogSec= nur zu aktivieren, falls RuntimeWatchdogSec=
auch aktiviert ist.
Diese Einstellungen haben keine Auswirkungen, falls kein
Hardware-Watchdog verfügbar ist.
Hinzugefügt in Version 198.
RuntimeWatchdogPreSec=
Konfiguriert den
Hardware-Watchdog-Vorzeitüberschreitungswert. Akzeptiert einen
Zeitüberschreitungswert in Sekunden (oder in anderen Zeiteinheiten,
ähnlich wie
RuntimeWatchdogSec=). Eine
Vorzeitüberschreitung ist eine durch den Watchdog erzeugte
Benachrichtigung, bevor eine Watchdog-Zurücksetzung erfolgen
könnte, falls der Watchdog nicht bedient wurde. Diese Benachrichtigung
wird vom Kernel bedient und kann so mit
RuntimeWatchdogPreGovernor=
konfiguriert werden, dass eine Aktion erfolgt (d.h. eine Kernel-Panik erzeugt
wird). Nicht alle Watchdog-Hardware oder -Treiber unterstützen die
Erstellung einer Vorzeitüberschreitung und abhängig vom Zustand
des Systems könnte der Kernel nicht in der Lage sein, die konfigurierte
Aktion vorzunehmen, bevor sich der Watchdog neu startet. Der Watchdog wird so
konfiguriert, dass er die Vorzeitüberschreitung die in
RuntimeWatchdogPreSec= festgelegte Zeit vor der
Laufzeitüberschreitung des Watchdogs erstellt (gesetzt über
RuntimeWatchdogSec=). Ist beispielsweise
RuntimeWatchdogSec=30
und
RuntimeWatchdogPreSec=10, dann wird das
Vorzeitüberschreitungsereignis auftreten, falls 20 Sekunden lang kein
Ping zum Watchdog erfolgte (10 Sekunden bevor der Watchdog auslösen
würde). Standardmäßig ist 0 (ausgeschaltet) die Vorgabe
für
RuntimeWatchdogPreSec=. Der für
RuntimeWatchdogPreSec= gesetzte Wert muss kleiner als der
Zeitüberschreitungswert für
RuntimeWatchdogSec= sein.
Diese Einstellung hat keine Auswirkung, falls kein Hardware-Watchdog
verfügbar ist oder der Hardware-Watchdog keine
Vorzeitüberschreitung unterstützt und wird vom Kernel ignoriert,
falls die Einstellung größer als die tatsächliche
Watchdog-Zeitüberschreitung ist.
Hinzugefügt in Version 251.
RuntimeWatchdogPreGovernor=
Konfiguriert die vom Hardware-Watchdog-Gerät
vorzunehmende Aktion, wenn die Vorzeitüberschreitung abläuft.
Die Vorgabeaktion für das Vorzeitüberschreitungsereignis
hängt von der Kernelkonfiguration ab, aber normalerweise wird eine
Kernelmeldung protokolliert. Lesen Sie den Inhalt der Datei
/sys/class/watchdog/watchdog
X/pretimeout_available_governors für
eine Liste gültiger, für ein Watchdog-Gerät
verfügbarer Aktionen. Typischerweise sind die Regulierungstypen
noop und
panic verfügbar. Verfügbarkeit, Namen und
Funktionalität könnten sich, abhängig vom konkret
verwandten Gerätetreiber, unterscheiden. Falls die Sysfs-Datei
pretimeout_available_governors leer ist, könnte der Regulierer als
Kernelmodul gebaut worden sein und könnte manuell zu laden sein (z.B.
pretimeout_noop.ko) oder das Watchdog-Gerät könnte
Vorzeitüberschreitung nicht unterstützen.
Hinzugefügt in Version 251.
WatchdogDevice=
Konfiguriert das Hardware-Watchdog-Gerät, das die
Laufzeit- und Herunterfahr-Watchdog-Timer öffnen und benutzen wird.
Standardmäßig /dev/watchdog0. Diese Einstellung hat keinen
Effekt, falls kein Hardware-Watchdog verfügbar ist.
Hinzugefügt in Version 236.
SICHERHEIT¶
CapabilityBoundingSet=
Steuert, welche Capabilities in der
Capability-Begrenzungsmenge für PID 1 und seine Kindprozesse
aufgenommen werden sollen. Siehe
capabilities(7) für Details.
Akzeptiert eine durch Leerraumzeichen getrennte Liste von Capability-Namen,
wie sie von
cap_from_name(3) eingelesen werden. Die aufgeführten
Capabilities werden in die Begrenzungsmenge aufgenommen, alle anderen werden
entfernt. Falls der Liste der Capabilities ein ~ vorangestellt wird, werden
alle außer den aufgeführten Capabilities aufgenommen, der Effekt
der Zuweisung ist invertiert. Beachten Sie, dass diese Option auch die
respektiven Capabilities in der effektiven, erlaubten und vererbbaren
Capability-Menge betrifft. Die Capability-Begrenzungsmenge kann auch
für Units auch individuell mittels der Anweisung
CapabilityBoundingSet= für diese Unit konfiguriert werden.
Beachten Sie aber, dass Capabilities, die für PID 1 ausgeschlossen
wurden, nicht für individuelle Units wiedererlangt werden
können, sie sind auf Dauer verloren.
Hinzugefügt in Version 198.
NoNewPrivileges=
Akzeptiert ein logisches Argument. Falls true, stellt sie
sicher, dass PID 1 und alle seine Kinder niemals Privilegien durch
execve(2) erhalten können (d.h. mittels der Bits setuid oder
setgid oder Dateisystem-Capabilities). Standardmäßig false.
Allzweckdistributionen benötigen typischerweise Programme mit gesetzten
Setuid- oder Setgid-Bits und werden daher nicht korrekt funktionieren, wenn
diese Option aktiviert ist. Individuelle Units können diese Option
nicht deaktivieren. Siehe auch
Schalter »Keine neuen
Privilegien«[2].
Hinzugefügt in Version 239.
ProtectSystem=
Akzeptiert ein logisches Argument oder die Zeichenkette
»auto«. Falls auf true gesetzt, wird dies /usr/
schreibgeschützt neu einhängen. Falls auf (die Vorgabe)
»auto« gesetzt und in einer Initrd ausgeführt, dann
äquivalent zu true, sonst false. Dies implementiert eine
eingeschränkte Untermenge der Unit-bezogenen Einstellung des gleichen
Namens, siehe
systemd.exec(5) zu Details: aktuell werden die Werte
»full« oder »strict« nicht unterstützt.
Hinzugefügt in Version 256.
SystemCallArchitectures=
Akzeptiert eine durch Leerzeichen getrennte Liste von
Architekturkennzeichnern. Wählt aus, von welchen Architekturen auf
diesem System Systemaufrufe aufgerufen werden dürfen. Dies kann als
effektive systemweite Art zur Deaktivierung von Aufrufen von nicht-nativen
Programmen verwandt werden, um beispielsweise die Ausführung von
32-Bit-x86-Programmen auf 64-Bit-x86-64-Systemen zu verbieten. Diese Option
agiert systemweit und arbeitet ähnlich der Einstellung
SystemCallArchitectures= von Unit-Dateien, siehe
systemd.exec(5)
für Details. Diese Einstellung ist standardmäßig die
leere Liste, d.h. dass in diesem Fall keine Filterung der Systemaufrufe
basierend auf der Architektur angewandt wird. Bekannte Architekturkennzeichner
sind »x86«, »x86-64«, »x32«,
»arm« und der besondere Kennzeichner »native«.
Letzterer wird implizit auf die native Architektur des Systems abgebildet
(oder genauer, der Architektur, für die der Systemverwalter kompiliert
wurde). Setzen Sie diese Einstellung auf »native«, um die
Ausführung nicht nativer Programme zu verbieten. Wenn ein Programm
einen Systemaufruf einer Architektur ausführt, die nicht in dieser
Einstellung aufgeführt ist, wird sie sofort mit dem Signal SIGSYS
beendet.
Hinzugefügt in Version 209.
DefaultSmackProcessLabel=
Akzeptiert einen
SMACK64-Sicherheits-Label als
Argument. Der durch eine Unit ausgeführte Prozess wird unter diesem
Label gestartet, falls
SmackProcessLabel= nicht in der Unit gesetzt
ist. Siehe
systemd.exec(5) für Details.
Falls der Wert »/« ist, werden nur mit
SmackProcessLabel= festgelegte Label zugewiesen und die Vorgabe aus
der Kompilierung wird ignoriert.
Hinzugefügt in Version 252.
ZEITÜBERSCHREITUNGEN UND RATENBEGRENZUNGEN¶
DefaultTimeoutStartSec=, DefaultTimeoutStopSec=,
DefaultTimeoutAbortSec=, DefaultRestartSec=
Konfiguriert die Standardzeitüberschreitung zum
Starten, Beenden und Abbrechen von Units sowie die Standardzeit, die zwischen
automatischen Neustarts von Units geschlafen wird, wie dies pro Unit in
TimeoutStartSec=,
TimeoutStopSec=,
TimeoutAbortSec= und
RestartSec= konfiguriert ist (für Dienste, siehe
systemd.service(5) für Details über die Einstellungen pro
Unit). Für Units, die keine Dienste sind, setzt
DefaultTimeoutStartSec= den Standardwert von
TimeoutSec=.
DefaultTimeoutStartSec= und DefaultTimeoutStopSec=
sind standardmäßig 90 s im Systemverwalter und 90 s im
Benutzerverwalter. DefaultTimeoutAbortSec= ist
standardmäßig nicht gesetzt, so dass alle Units auf
TimeoutStopSec= zurückfallen. DefaultRestartSec= ist
standardmäßig 100 ms.
Hinzugefügt in Version 209.
DefaultDeviceTimeoutSec=
Konfiguriert die standardmäßige
Zeitüberschreitung zum Warten auf Geräte. Sie kann
gerätebezogen mittels der Option
x-systemd.device-timeout= in
/etc/fstab und /etc/crypttab geändert werden (siehe
systemd.mount(5),
crypttab(5)). Standardmäßig 90 s
im Systemverwalter und 90 s im Benutzerverwalter.
Hinzugefügt in Version 252.
DefaultStartLimitIntervalSec=,
DefaultStartLimitBurst=
Konfiguriert die Standard-Startratenbegrenzung von Units,
wie dies pro Dienst in
StartLimitIntervalSec= und
StartLimitBurst= konfiguriert ist. Siehe
systemd.service(5)
für Details über die Einstellungen pro Dienst.
DefaultStartLimitIntervalSec= ist standardmäßig 10 s.
DefaultStartLimitBurst= ist standardmäßig 5.
Hinzugefügt in Version 209.
ReloadLimitIntervalSec=, ReloadLimitBurst=
Ratenbegrenzung für Daemon-Neulade- und (seit
v256) Daemon-Neuausführungs-Anforderungen. Die Einstellung gilt
für beide Aktionen, aber die Ratenbegrenzungen werden getrennt
nachverfolgt. Standardmäßig nicht gesetzt und jede Anzahl an
Aktionen kann zu jeder Zeit erbeten werden.
ReloadLimitIntervalSec=
akzeptiert einen Wert in Sekunden, um das Ratenbegrenzungsfenster zu
konfigurieren und
ReloadLimitBurst= akzeptiert eine positive Ganzzahl,
um die maximal erlaubte Anzahl von Aktionen innerhalb des konfigurierten
Zeitfensters zu konfigurieren.
Hinzugefügt in Version 253.
UMGEBUNGSVARIABLEN¶
ManagerEnvironment=
Akzeptiert die gleichen Argumente wie
DefaultEnvironment=, siehe oben. Setzt Umgebungsvariablen für
den Verwalterprozess selbst. Diese Variablen werden von Prozessen ererbt, die
vom Benutzerverwalter erzeugt werden, aber nicht von dem Systemverwalter,
verwenden Sie dafür
DefaultEnvironment=. Beachten Sie, dass
diese Variablen mit dem bestehenden Umgebungsblock zusammengeführt
werden. Insbesondere im Falle des Systemverwalters schließt dies
Variablen ein, die vom Kernel — basierend auf der Kernelbefehlszeile
— gesetzt werden. Wie bei
DefaultEnvironment= ist dieser
Umgebungsblock intern und Änderungen daran werden nicht in
/proc/PID/environ des Verwalters wiedergespiegelt.
Das Setzen von Umgebungsvariablen für den Verwalterprozess
kann zu Veränderung dessen Verhaltens nützlich sein. Siehe
Bekannte Umgebungsvariablen[3] für eine Beschreibung
über einige der von systemd verstandenen Variablen.
Einfache »%«-Kennzeichner-Expansion wird
unterstützt, siehe unten für eine Liste der
unterstützten Kennzeichner.
Hinzugefügt in Version 248.
DefaultEnvironment=
Konfiguriert Umgebungsvariablen, die an alle
ausgeführten Prozesse weitergegeben werden. Erhält eine Liste
von durch Leerzeichen getrennten Variablenzuweisungen. Siehe
environ(7)
für Details über Umgebungsvariablen.
Einfache »%«-Kennzeichner-Expansion wird
unterstützt, siehe unten für eine Liste der
unterstützten Kennzeichner.
Beispiel:
DefaultEnvironment="VAR1=Wort1 Wort2" VAR2=Wort3 "VAR3=Wort 5 6"
Setzt drei Variablen "VAR1", "VAR2",
"VAR3".
Hinzugefügt in Version 205.
KENNZEICHNER¶
Kennzeichner können in den Einstellungen
DefaultEnvironment= und ManagerEnvironment= verwandt werden.
Die folgenden Expansionen werden verstanden:
Tabelle 1. Verfügbare Kennzeichner
| Kennzeichner |
Bedeutung |
Details |
| "%a" |
Architektur |
Eine kurze Zeichenkette, die die Architektur des lokalen Systems
identifiziert. Eine Zeichenkette wie x86, x86-64 oder
arm64. Siehe die für ConditionArchitecture= in
systemd.unit(5) definierten Architekturen für die
vollständige Liste. |
| "%A" |
Betriebssystemabbildversion |
Die Betriebssystemabbildversionskennzeichnung des laufenden Systems, wie
aus dem Feld IMAGE_VERSION= in /etc/os-release ausgelesen. Falls
nicht gesetzt, wird es zur leeren Zeichenkette aufgelöst. Siehe
os-release(5) für weitere Informationen. |
| "%b" |
Boot-Kennung |
Die Boot-Kennung des laufenden Systems, formatiert als Zeichenkette.
Siehe random(4) für weitere Informationen. |
| "%B" |
Betriebssystembaukennung |
Die Betriebssystembaukennung des laufenden Systems, wie aus dem Feld
BUILD_ID= in /etc/os-release ausgelesen. Falls nicht gesetzt, wird
es zur leeren Zeichenkette aufgelöst. Siehe os-release(5)
für weitere Informationen. |
| "%H" |
Rechnername |
Der Rechnername des laufenden Systems. |
| "%l" |
Kurzer Rechnername |
Die Rechnername des laufenden Systems, abgeschnitten am ersten Punkt, um
alle Domain-Komponenten zu entfernen. |
| "%m" |
Maschinenkennung |
Die Maschinenkennung des laufenden Systems, formatiert als Zeichenkette.
Siehe machine-id(5) für weitere Informationen. |
| "%M" |
Betriebssystemabbildkennung |
Die Betriebssystemabbildkennung des laufenden Systems, wie aus dem Feld
IMAGE_ID= in /etc/os-release ausgelesen. Falls nicht gesetzt, wird
es die leere Zeichenkette. Siehe os-release(5) für weitere
Informationen. |
| "%o" |
Betriebssystemkennung |
Die Betriebssystemkennung des laufenden Systems, wie aus dem Feld
ID= in /etc/os-release ausgelesen. Siehe os-release(5)
für weitere Informationen. |
| "%v" |
Kernelveröffentlichung |
Identisch zur Ausgabe von uname -r. |
| "%w" |
Betriebssystemversionskennung |
Die Betriebssystemversionskennzeichnung des laufenden Systems, wie aus
dem Feld VERSION_ID= in /etc/os-release ausgelesen. Falls nicht
gesetzt, wird es die leere Zeichenkette. Siehe os-release(5)
für weitere Informationen. |
| "%W" |
Betriebssystemvariantenkennung |
Die Betriebssystemvariantenkennung des laufenden Systems, wie aus dem
Feld VARIANT_ID= in /etc/os-release ausgelesen. Falls nicht
gesetzt, wird es die leere Zeichenkette. Siehe os-release(5)
für weitere Informationen. |
| "%T" |
Verzeichnis für temporäre Dateien |
Dies ist entweder /tmp oder der Pfad, auf den »$TMPDIR«,
»$TEMP« oder »$TMP« gesetzt ist. (Beachten
Sie, dass das Verzeichnis ohne abschließenden Schrägstrich
angegeben werden kann.) |
| "%V" |
Verzeichnis für größere und dauerhafte
temporäre Dateien |
Dies ist entweder /var/tmp oder der Pfad, auf den
»$TMPDIR«, »$TEMP« oder »$TMP«
gesetzt ist. (Beachten Sie, dass das Verzeichnis ohne
abschließenden Schrägstrich angegeben werden kann.) |
| "%h" |
Benutzer-Home-Verzeichnis |
Dies ist das Home-Verzeichnis des Benutzers, der die Instanz des
Diensteverwalters ausführt. |
| "%u" |
Benutzername |
Dies ist der Benutzername des Benutzers, der die Instanz des
Diensteverwalters ausführt. |
| "%U" |
Benutzerkennung |
Die ist die Benutzerkennung des Benutzers, der die Instanz des
Diensteverwalters ausführt. |
| "%g" |
Primäre Gruppe |
Dies ist die primäre Gruppe des Benutzers, der die Instanz des
Diensteverwalters ausführt. |
| "%G" |
Primäre Gruppenkennung |
Dies ist die primäre Gruppekennung des Benutzers, der die
Instanz des Diensteverwalters ausführt. |
| "%s" |
Benutzer-Shell |
Dies ist die Shell des Benutzers, der die Instanz des
Diensteverwalters ausführt. |
| "%%" |
Einzelnes Prozentzeichen |
Verwenden Sie »%%« anstelle von »%«, um ein
einzelnes Prozentzeichen anzugeben. |
GESCHICHTE¶
systemd 252
Die Option
DefaultBlockIOAccounting= wurde als
veraltet markiert. Bitte wechseln Sie zur vereinigten Cgroup-Hierarchie.
Hinzugefügt in Version 252.
ANMERKUNGEN¶
- 1.
- 💣💥🧨💥💥💣 Bitte beachten Sie,
dass diese Konfigurationsdateien zu allen Zeiten verfügbar sein
müssen. Falls /usr/local/ eine separate Partition ist,
könnte diese während des frühen Systemstarts nicht
verfügbar sein und darf dann nicht für Konfiguration
verwandt werden.
- 2.
- Schalter »Keine neuen Privilegien«
- 3.
- Bekannte Umgebungsvariablen
ÜBERSETZUNG¶
Die deutsche Übersetzung dieser Handbuchseite wurde von
Helge Kreutzmann <debian@helgefjell.de> erstellt.
Diese Übersetzung ist Freie Dokumentation; lesen Sie die
GNU General
Public License Version 3 oder neuer bezüglich der
Copyright-Bedingungen. Es wird KEINE HAFTUNG übernommen.
Wenn Sie Fehler in der Übersetzung dieser Handbuchseite
finden, schicken Sie bitte eine E-Mail an die Mailingliste der
Übersetzer:
debian-l10n-german@lists.debian.org.
