Provided by: manpages-de_4.13-4_all 
BEZEICHNUNG
systemd-system.conf, system.conf.d, systemd-user.conf, user.conf.d - System- und
Sitzungsserviceverwalter-Konfigurationsdateien
ÜBERSICHT
/etc/systemd/system.conf, /etc/systemd/system.conf.d/*.conf, /run/systemd/system.conf.d/*.conf,
/lib/systemd/system.conf.d/*.conf
~/.config/systemd/user.conf, /etc/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 (entweder im Home-Verzeichnis des Benutzers oder, falls nicht gefunden,
unter /etc/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. Anfänglich enthält die
Hauptkonfigurationsdatei in /etc/systemd/ die Vorgaben als auskommentierten Hinweis für den
Administrator. Lokal können diese Einstellungen außer Kraft gesetzt werden, indem diese Datei bearbeitet
wird oder durch die Erstellung von Ergänzungen, wie nachfolgend beschrieben. Es wird empfohlen,
Ergänzungen für lokale Konfiguration zu verwenden, statt die Hauptkonfigurationsdatei zu verändern.
Zusätzlich zu der »Haupt«-Konfigurationsdatei, 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 der Dateien zu vereinfachen.
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,
CrashReboot=no, 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.
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«.
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).
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).
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).
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.
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.
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.
NoNewPrivileges=
Akzeptiert ein logisches Argument. Falls wahr, 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 falsch. 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«[1].
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.
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.
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=.
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.
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). Standardmäßig deaktiviert,
wenn Dienst mit Type=oneshot verwandt wird. Für Units, die keine Dienste sind, setzt
DefaultTimeoutStartSec= den Standardwert von TimeoutSec=. DefaultTimeoutStartSec= und
DefaultTimeoutStopSec= sind standardmäßig 90 s. DefaultTimeoutAbortSec= ist standardmäßig nicht
gesetzt, so dass alle Units auf TimeoutStopSec= zurückfallen. DefaultRestartSec= ist standardmäßig
100 ms.
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.
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".
ManagerEnvironment=
Akzeptiert die gleichen Argumente wie DefaultEnvironment=, siehe oben. Setzt Umgebungsvariablen nur
für den Verwalterprozess selbst. Im Gegensatz zu Benutzerverwaltern werden diese Variablen nicht von
Prozessen ererbt, die vom Systemverwalter erzeugt werden, 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.
Das Setzen von Umgebungsvariablen für den Verwalterprozess kann zu Veränderung dessen Verhaltens
nützlich sein. Siehe UMGEBUNGSVARIABLEN[2] 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.
DefaultCPUAccounting=, DefaultBlockIOAccounting=, DefaultMemoryAccounting=, DefaultTasksAccounting=,
DefaultIOAccounting=, DefaultIPAccounting=
Konfiguriert die Standard-Buchführungs-Einstellungen, wie sie für jede Unit durch CPUAccounting=,
BlockIOAccounting=, MemoryAccounting=, TasksAccounting=, IOAccounting= und IPAccounting= konfiguriert
werden. Siehe systemd.resource-control(5) für Details über die Einstellungen pro Unit.
DefaultTasksAccounting= ist standardmäßig »yes«, DefaultMemoryAccounting= ist »yes«.
DefaultCPUAccounting= ist standardmäßig »yes«, falls die Aktivierung der CPU-Buchführung nicht die
Aktivierung der CPU-Controller benötigt (Linux 4.15+ verwendet die vereinigte Hierarchie für die
Ressourcensteuerung), andernfalls ist die Vorgabe »no«. Die anderen drei Einstellungen sind
standardmäßig »no.
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.
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«.
• 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 RLIMIT_MEMLOCK für sich selbst erhöht, die
Beschränkung wird allerdings für per Fork erzeugten Kindprozesse auf den ursprünglichen Wert
zurückgesetzt.
DefaultOOMPolicy=
Konfiguriert die Standardrichtlinie für die Reaktion auf Prozesse, die durch den Speicherknappheits-
(OOOM-)Killer von Linux 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.
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.
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 die leere │
│ │ │ Zeichenkette. 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 │ Dies ist entweder /tmp oder der Pfad, auf │
│ │ Dateien │ 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 │ Dies ist entweder /var/tmp oder der Pfad, │
│ │ dauerhafte temporäre Dateien │ auf den »$TMPDIR«, »$TEMP« oder »$TMP« │
│ │ │ gesetzt ist. (Beachten Sie, dass das │
│ │ │ Verzeichnis ohne abschließenden │
│ │ │ Schrägstrich angegeben werden kann.) │
├──────────────┼────────────────────────────────┼───────────────────────────────────────────┤
│ "%%" │ Einzelnes Prozentzeichen │ Verwenden Sie »%%« anstelle von »%«, um │
│ │ │ ein einzelnes Prozentzeichen anzugeben. │
└──────────────┴────────────────────────────────┴───────────────────────────────────────────┘
SIEHE AUCH
systemd(1), systemd.directives(7), systemd.exec(5), systemd.service(5), environ(7), capabilities(7)
ANMERKUNGEN
1. Schalter »Keine neuen Privilegien«
https://www.kernel.org/doc/html/latest/userspace-api/no_new_privs.html
2. UMGEBUNGSVARIABLEN
https://systemd.io/ENVIRONMENT
ÜBERSETZUNG
Die deutsche Übersetzung dieser Handbuchseite wurde von Helge Kreutzmann <debian@helgefjell.de> erstellt.
Diese Übersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 3 oder neuer
bezüglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG übernommen.
Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an die
Mailingliste der Übersetzer.
systemd 250 SYSTEMD-SYSTEM.CONF(5)