Ubuntu Manpage: systemd, init - Systemd-System und Diensteverwalter

BEZEICHNUNG

       systemd, init - Systemd-System und Diensteverwalter

ÜBERSICHT

       /usr/lib/systemd/systemd [OPTIONEN…]

       init [OPTIONEN…] {BEFEHL}

BESCHREIBUNG

       Systemd ist ein System- und Diensteverwalter für das Linux-Betriebssystem. Wird es beim
       Systemstart als erster Prozess (als PID 1) ausgeführt, agiert es als Init-System, das das
       System hochfährt und Dienste auf Anwendungsebene verwaltet. Für angemeldete Benutzer zum
       Starten ihrer Dienste werden separate Instanzen gestartet.

       systemd wird normalerweise nicht direkt durch den Benutzer aufgerufen, sondern wird als
       Symlink /sbin/init installiert und während der frühen Systemstartphase ausgeführt. Die
       Benutzerverwalterinstanzen werden automatisch durch den Dienst user@.service(5) gestartet.

       Für die Kompatibilität mit SysV wird das Programm, falls es init genannt und nicht der
       erste Prozess auf der Maschine ist (PID ist nicht 1), telinit ausführen und alle
       Befehlszeilenargumente unverändert weitergeben. Das bedeutet, dass init und telinit beim
       Aufruf von normalen Anmeldesitzungen größtenteils äquivalent sind. Siehe telinit(8) für
       weitere Informationen.

       Systemd interpretiert die Konfigurationsdatei system.conf und die Dateien in
       Verzeichnissen system.conf.d, wenn es als Systeminstanz läuft. Wenn es als Benutzerinstanz
       läuft, interpretiert Systemd die Konfigurationsdatei user.conf und die Dateien in
       Verzeichnissen user.conf.d. Siehe systemd-system.conf(5) für weitere Informationen.

KONZEPTE

Systemd stellt ein Abhängigkeitssystem zwischen verschiedenen Einheiten namens »Units« in
11 verschiedenen Typen bereit. Units kapseln verschiedene Objekte, die für den Systemstart
und -betrieb relevant sind. Der Großteil der Units wird in Unit-Konfigurationsdateien,
deren Syntax und grundlegenden Menge an Optionen in systemd.unit(5) beschrieben ist,
konfiguriert. Einige Units werden allerdings automatisch aus anderen
Konfigurationsdateien, dynamisch aus Systemzuständen oder programmatisch zur Laufzeit
erstellt. Units können »aktiv« (dies bedeutet gestartet, gebunden, eingesteckt, …,
abhängig vom Unit-Typ, siehe unten) oder »inaktiv« (dies bedeutet gestoppt, nicht
gebunden, ausgesteckt, … ) sowie im Prozess der Aktivierung oder Deaktivierung, d.h.
zwischen den zwei Zuständen (diese Zustände werden »Aktivierung« und »Deaktivierung«
genannt) sein. Ein besonderer Zustand »fehlgeschlagen« ist auch verfügbar, der sehr
ähnlich zu »inaktiv« ist und der erreicht wird, wenn der Dienst auf irgendeine Art
fehlgeschlagen ist (Prozess lieferte beim Beenden einen Fehlercode, ist abgestürzt, eine
Aktion erlebte eine Zeitüberschreitung oder nach zu vielen Neustarts). Falls dieser
Zustand erreicht wird, wird die Ursache für spätere Einsichtnahme protokolliert. Beachten
Sie, dass die verschiedenen Unit-Typen eine Reihe von zusätzlichen Unterzuständen haben
können, die auf die fünf hier beschriebenen generalisierten Unit-Zustände abgebildet
werden.

Die folgenden Unit-Typen sind verfügbar:

1. Dienste-Units, die Daemons und die Prozesse, aus denen sie bestehen, starten und
steuern. Für Details siehe systemd.service(5).

2. Socket-Units, die lokale IPC- oder Netzwerk-Sockets in dem System kapseln, nützlich
für Socket-basierte Aktivierung. Für Details über Socket-Units siehe
systemd.socket(5), für Details über Socket-basierte Aktivierung und andere Formen der
Aktivierung siehe daemon(7).

3. Ziel-Units sind für die Gruppierung von Units nützlich. Sie stellen während des
Systemstarts auch gut bekannte Synchronisationspunkte zur Verfügung, siehe
systemd.target(5).

4. Geräte-Units legen Kernel-Geräte in Systemd offen und können zur Implementierung
Geräte-basierter Aktivierung verwandt werden. Für Details siehe systemd.device(5).

5. Einhänge-Units steuern Einhängepunkte in dem Dateisystem, für Details siehe
systemd.mount(5).

6. Automount-Units stellen Selbsteinhänge-Fähigkeiten bereit, für bedarfsgesteuertes
Einhängen von Dateisystemen sowie parallelisiertem Systemstart. Siehe
systemd.automount(5).

7. Timer-Units sind für das Auslösen der Aktivierung von anderen Units basierend auf
Timern nützlich. Sie können Details in systemd.timer(5) finden.

8. Auslagerungs-Units sind ähnlich zu Einhänge-Units und kapseln
Speicherauslagerungspartitionen oder -dateien des Betriebssystems. Sie werden in
systemd.swap(5) beschrieben.

9. Pfad-Units können zur Aktivierung andere Dienste, wenn sich Dateisystemobjekte ändern
oder verändert werden, verwandt werden. Siehe systemd.path(5).

10. Scheiben-Units können zur Gruppierung von Units, die Systemprozesse (wie Dienste- und
Bereichs-Units) in einem hierarchischen Baum aus Ressourcenverwaltungsgründen
verwalten, verwandt werden. Siehe systemd.slice(5).

11. Bereichs-Units sind ähnlich zu Dienste-Units, verwalten aber fremde Prozesse, statt
sie auch zu starten. Siehe systemd.scope(5).

Units werden wie ihre Konfigurationsdateien benannt. Einige Units habe besondere
Semantiken. Eine detaillierte Liste ist in systemd.special(7) verfügbar.

Systemd kennt verschiedene Arten von Abhängigkeiten, einschließlich positiven und
negativen Bedingungsabhängigkeiten (d.h. Requires= und Conflicts=) sowie
Ordnungsabhängigkeiten (After= und Before=). Wohlgemerkt: Ordnungs- und
Bedingungsabhängigkeiten sind orthogonal. Falls zwischen zwei Units nur eine
Bedingungsabhängigkeit (z.B. foo.service bedingt bar.service) aber keine
Ordnungsabhängigkeit (z.B. foo.service nach bar.service) existiert und beide zum Start
angefragt werden, werden sie parallel gestartet. Es ist ein häufiges Muster, dass sowohl
Bedingungs- als auch Ordnungsabhängigkeiten zwischen zwei Units angelegt werden. Beachten
Sie auch, dass die Mehrzahl der Abhängigkeiten von Systemd implizit erstellt und verwaltet
werden. In den meisten Fällen sollte es unnötig sein, zusätzliche Abhängigkeiten manuell
zu deklarieren, allerdings ist dies möglich.

Anwendungsprogramme und Units (über Abhängigkeiten) können Statusänderungen von Units
erbitten. In Systemd werden diese Anfragen als »Aufträge« gekapselt und in einer
Aufträgewarteschlange verwaltet. Aufträge können erfolgreich sein und fehlschlagen, ihre
Ausführungsreihenfolge basiert auf den Ordnungsabhängigkeiten der Units, für die sie
eingeplant wurden.

Beim Systemstart aktiviert Systemd die Ziel-Unit default.target, deren Aufgabe es ist, die
bei-Systemstart-Dienste und andere bei-Systemstart-Units zu aktivieren, indem sie sie
mittels Abhängigkeiten hereinzieht. Normalerweise ist der Unit-Name nur ein Alias
(Symlink) für entweder graphical.target (für vollfunktionale Systemstarts in die UI) oder
multi-user.target (für begrenzte, rein konsolenbasierte Systemstarts zur Verwendung in
eingebetteten oder Server-Umgebungen oder ähnlichen, eine Untermenge von
graphical.target). Es obliegt aber dem Administrator, sie als Alias zu jeder anderen
Ziel-Unit zu konfigurieren. Siehe systemd.special(7) für Details über diese Ziel-Units.

Beim ersten Systemstart wird systemd Units gemäß der Voreinstellungs-Richtlinie aktivieren
oder deaktivieren. Siehe systemd.preset(5) und »Semantik beim ersten Systemstart« in
machine-id(5).

Systemd behält nur eine minimale Gruppe an Units im Speicher geladen. Konkret werden nur
die Units im Speicher geladen gehalten, für die mindestens eine der nachfolgenden
Bedingungen zutrifft:

1. Sie ist in einem aktiven, aktivierenden, deaktivierenden oder fehlgeschlagenen Zustand
(d.h. in jedem Zustand außer »inactive«)

2. Für sie ist ein Auftrag in der Warteschlange

3. Sie ist eine Abhängigkeit von mindestens einer anderen im Speicher geladenen Unit

4. Ihr ist noch irgendeine Form von Ressourcen zugewiesen (z.B. eine inaktive
Dienste-Unit, für die aber ein Prozess noch herumlungert, der die Aufforderung zum
Beenden ignorierte)

5. Sie wurde durch einen D-Bus-Aufruf programmatisch im Speicher festgepinnt

Systemd wird automatisch und implizit Units von der Platte laden — falls sie noch nicht
geladen sind — sobald eine Aktion für sie angefordert wird. Daher ist in vielerlei
Hinsicht die Tatsache, ob eine Unit geladen ist oder nicht, für Clients unsichtbar.
Verwenden Sie systemctl list-units --all, um eine vollumfängliche Liste aller derzeit
geladenen Units zu erhalten. Jede Unit, für die eine der oben aufgeführten Bedingungen
zutrifft, wird sofort entladen. Beachten Sie, dass beim Entladen einer Unit aus dem
Speicher die Buchführungsdaten auch entfernt werden. Allerdings sind diese Daten im
Allgemeinen nicht verloren, da ein Journal-Protokolleintrag erstellt wird, der die
verbrauchten Ressourcen deklariert, wann immer eine Unit herunterfährt.

Prozesse, die Systemd startet, werden in einer privaten Systemd-Hierarchie in
individuellen Control-Gruppen von Linux, die nach der Unit, zu der sie gehören, benannt
sind, gelegt (siehe Control Groups v2[1] für weitere Informationen über Control-Gruppen
oder kurz »cgroups«). Systemd verwendend dies, um Prozesse effektiv nachzuverfolgen.
Control-Gruppen-Informationen werden im Kernel verwaltet und sind über die
Dateisystemhierarchie (unterhalb von /sys/fs/cgroup/) oder über Werkzeuge wie
systemd-cgls(1) oder ps(1) verfügbar. (ps xawf -eo pid,user,cgroup,args ist besonders
nützlich, um alle Prozesse und die Systemd-Units, zu denen sie gehören, aufzulisten.)

Systemd ist zu einem großen Teil zu SysV kompatibel: SysV-Init-Skripte werden unterstützt
und werden einfach als ein alternatives (wenn auch begrenztes) Konfigurationsdateiformat
verstanden. Die SysV-Schnittstelle /dev/initctl wird bereitgestellt und
Kompatibilitätsimplementierungen der verschiedenen SysV-Client-Werkzeuge sind verfügbar.
Zusätzlich werden verschiedene etablierte Unix-Funktionalitäten wie /etc/fstab oder die
Utmp-Datenbank unterstützt.

Systemd hat ein minimales Transaktionssystem: Falls eine Unit zum Start oder
Herunterfahren aufgefordert wird, wird sie sich und alle Abhängigkeiten zu einer
temporären Transaktion hinzufügen. Es wird dann nachweisen, dass die Transaktion
konsistent ist (d.h. ob die Ordnung aller Units frei von Zyklen ist). Sollte dies nicht
der Fall sein, wird Systemd versuchen, sie zu korrigieren und entfernt alle unwesentlichen
Aufträge aus der Transaktion, die die Schleife entfernen könnten. Auch versucht Systemd,
nicht wesentliche Aufträge in der Transaktion zu unterdrücken, die einen laufenden Dienst
stoppen würden. Schließlich wird überprüft, ob die Aufträge der Transaktion Aufträgen
widersprechen, die bereits in die Warteschlange eingereiht wurden, optional wird dann die
Transaktion abgebrochen. Falls alles passt und die Transaktion konsistent in ihren
Auswirkungen minimiert ist, wird sie mit bereits wartenden Aufträgen zusammengeführt und
zu der Ausführungswarteschlange hinzugefügt. Effektiv bedeutet dies, dass Systemd vor der
Ausführung einer angefragten Aktion überprüft, dass sie Sinn ergibt, sie falls möglich
korrigiert und nur fehlschlägt, falls es wirklich nicht funktionieren kann.

Beachten Sie, dass Transaktionen unabhängig vom Zustand einer Unit zur Laufzeit erstellt
werden. Wird daher beispielsweise ein Startauftrag für eine bereits gestartete Unit
angefordert, wird er dennoch eine Transaktion erstellen und alle inaktiven Abhängigkeiten
aufwecken (und gemäß der definierten Abhängigkeiten eine Weiterleitung zu anderen
Aufträgen verursachen). Dies erfolgt, da der in die Warteschlange eingereihte Auftrag zum
Zeitpunkt der Ausführung mit dem Zustand der Ziel-Unit verglichen und als erfolgreich und
abgeschlossen markiert wird, wenn beide zutreffen. Allerdings zieht dieser Auftrag auch
andere Abhängigkeiten aufgrund der definierten Beziehungen herein und führt daher in
unserem Beispiel dazu, dass Start-Aufträge für jede dieser inaktiven Units auch in die
Warteschlange eingereiht werden.

Systemd enthält native Implementierungen verschiedener Programme, die als Teil des
Systemstartprozesses ausgeführt werden müssen. Beispielsweise setzt es den Rechnernamen
und konfiguriert das Loopback-Netzwerkgerät. Es richtet auch die verschiedenen
API-Dateisysteme, wie /sys/ oder /proc/, ein und hängt sie ein.

Für weitere Informationen über die Konzepte und Ideen hinter Systemd wird auf das
Ursprüngliches Designdokument[2] verwiesen.

Beachten Sie, dass einige, aber nicht alle, durch Systemd bereitgestellte Schnittstellen
von der Schnittstellenportierungs und -stabilitätszusage[3] abgedeckt sind.

Units können dynamisch zum Systemstartzeitpunkt und zum Systemverwalter-Neuladezeitpunkt
erstellt werden, beispielsweise basierend auf anderen Konfigurationsdateien oder auf von
der Kernelbefehlszeile übergebenen Parametern. Für Details siehe systemd.generator(7).

Das D-Bus-API von systemd wird in org.freedesktop.systemd1(5) und
org.freedesktop.LogControl1(5) beschrieben.

Systeme, die Systemd in einem Container oder in einer Initrd-Umgebung aufrufen, sollten
die Spezifikation Container-Schnittstelle[4] bzw. initrd-Schnittstelle[5] implementieren.

VERZEICHNISSE

System-Unit-Verzeichnisse
Der Systemd-Systemverwalter liest Unit-Konfigurationen aus verschiedenen
Verzeichnissen. Pakete, die Unit-Dateien installieren möchten, sollten sie in dem
durch pkg-config systemd --variable=systemdsystemunitdir zurückgelieferten Verzeichnis
ablegen. Weitere geprüfte Verzeichnisse sind /usr/local/lib/systemd/system und
/usr/lib/systemd/system. Benutzerkonfiguration hat immer Vorrang. pkg-config systemd
--variable=systemdsystemconfdir liefert den Pfad zu dem
Systemkonfigurationsverzeichnis. Pakete sollten den Inhalt dieser Verzeichnisse mit
den Befehlen enable und disable des Werkzeugs systemctl(1) verändern. Eine
vollständige Auflistung von Verzeichnissen wird in systemd.unit(5) bereitgestellt.

Benutzer-Unit-Verzeichnisse
Ähnliche Regeln gelten für die Benutzer-Unit-Verzeichnisse. Allerdings wird hier der
XDG-Basisverzeichnisspezifikation[6] zum Finden von Units gefolgt. Anwendungen sollten
ihre Unit-Dateien in dem durch pkg-config systemd --variable=systemduserunitdir
zurückgelieferten Verzeichnis ablegen. Globale Konfiguration erfolgt in dem durch
pkg-config systemd --variable=systemduserconfdir gemeldeten Verzeichnis. Die Befehle
enable und disable des Werkzeugs systemctl(1) können sowohl mit globaler (d.h. für
alle Benutzer) als auch privater (für einen Benutzer) Freigabe/Ausschaltung von Units
umgehen. Eine vollständige Auflistung von Verzeichnissen wird in systemd.unit(5)
bereitgestellt.

SysV-Init-Skripte-Verzeichnis
Der Ort der SysV-Init-Skript-Verzeichnisse unterscheidet sich zwischen Distributionen.
Falls Systemd für den angefragten Dienst keine native Unit-Datei finden kann, wird es
nach einem SysV-Init-Skript des gleichen Namens (ohne die Endung .service) schauen.

SysV-Runlevel-Linksammelverzeichnis
Der Ort der SysV-Runlevel-Linksammelverzeichnisse unterscheidet sich zwischen
Distributionen. Systemd wird die Linksammlung berücksichtigen, wenn es bestimmt, ob
ein Dienst freigegeben werden soll. Beachten Sie, dass eine Dienste-Unit mit einer
nativen Unit-Konfigurationsdatei nicht durch Aktivierung in der
SysV-Runlevel-Linksammlung gestartet werden kann.

SIGNALE

The service listens to various UNIX process signals that can be used to request various
actions asynchronously. The signal handling is enabled very early during boot, before any
further processes are invoked. However, a supervising container manager or similar that
intends to request these operations via this mechanism must take into consideration that
this functionality is not available during the earliest initialization phase. An
sd_notify() notification message carrying the X_SYSTEMD_SIGNALS_LEVEL=2 field is emitted
once the signal handlers are enabled, see below. This may be used to schedule submission
of these signals correctly.

SIGTERM
Nach Empfang dieses Signals serialisiert der Systemd-Systemverwalter seinen Zustand,
führt sich selbst erneut aus und deseriealisiert den gespeicherten Zustand wieder.
Dies ist größtenteils äquivalent zu systemctl daemon-reexec.

Systemd-Benutzerverwalter werden die Unit exit.target starten, wenn dieses Signal
empfangen wird. Dies ist größtenteils äquivalent zu systemctl --user start exit.target
--job-mode=replace-irreversibly.

SIGINT
Nach Empfang dieses Signals wird der Systemverwalter die Unit ctrl-alt-del.target
starten. Dies ist größtenteils äquivalent zu systemctl start ctrl-alt-del.target
--job-mode=replace-irreversibly. Falls dieses Signal mehr als sieben Mal in zwei
Sekunden empfangen wird, wird ein sofortiger Systemneustart ausgelöst. Beachten Sie,
dass Drücken von Strg+Alt+Entf auf der Konsole dieses Signal auslösen wird. Hängt
daher ein Neustart, ist das siebenmalige Drücken von Strg+Alt+Entf in zwei Sekunden
eine relativ sichere Art, einen sofortigen Neustart auszulösen.

Systemd-Benutzerverwalter behandeln dieses Signal auf die gleiche Art wie SIGTERM.

SIGWINCH
Wenn dieses Signal empfangen wird, startet der Systemd-Systemverwalter die Unit
kbrequest.target. Dies ist größtenteils äquivalent zu systemctl start
kbrequest.target.

Dieses Signal wird von Systemd-Benutzerverwaltern ignoriert.

SIGPWR
Wenn dieses Signal empfangen wird, startet der Systemd-Systemverwalter die Unit
sigpwr.target. Dies ist größtenteils äquivalent zu systemctl start sigpwr.target.

SIGUSR1
Wenn dieses Signal empfangen wird, versucht der Systemd-Systemverwalter, sich erneut
mit dem D-Bus-Bus zu verbinden.

SIGUSR2
Wenn dieses Signal empfangen wird, protokolliert der Systemd-Systemverwalter seinen
kompletten Zustand in menschenlesbarer Form. Die protokollierten Daten sind identisch
zu den von systemd-analyze dump ausgegebenen.

SIGHUP
Lädt die komplette Daemon-Konfiguration neu. Dies ist größtenteils äquivalent zu
systemctl daemon-reload.

SIGRTMIN+0
Betritt den Standardmodus, startet die Unit default.target. Dies ist größtenteils
äquivalent zu systemctl isolate default.target.

SIGRTMIN+1
Betritt den Rettungsmodus, startet die Unit rescue.target. Dies ist größtenteils
äquivalent zu systemctl isolate rescue.target.

SIGRTMIN+2
Betritt den Notfallmodus, startet die Unit emergency.service. Dies ist größtenteils
äquivalent zu systemctl isolate emergency.service.

SIGRTMIN+3
Hält die Maschine an, startet die Unit halt.target. Dies ist größtenteils äquivalent
zu systemctl start halt.target --job-mode=replace-irreversibly.

SIGRTMIN+4
Schaltet die Maschine aus, startet die Unit poweroff.target. Dies ist größtenteils
äquivalent zu systemctl start poweroff.target --job-mode=replace-irreversibly.

SIGRTMIN+5
Startet die Maschine neu, startet die Unit reboot.target. Dies ist größtenteils
äquivalent zu systemctl start reboot.target --job-mode=replace-irreversibly.

SIGRTMIN+6
Startet die Maschine mittels kexec neu, startet die Unit kexec.target. Dies ist
größtenteils äquivalent zu systemctl start kexec.target
--job-mode=replace-irreversibly.

SIGRTMIN+7
Startet den Benutzerraum neu, startet die Unit soft-reboot.target. Dies ist
größtenteils äquivalent zu systemctl start soft-reboot.target
--job-mode=replace-irreversibly.

Hinzugefügt in Version 254.

SIGRTMIN+13
Hält die Maschine sofort an.

SIGRTMIN+14
Schaltet die Maschine sofort aus.

SIGRTMIN+15
Startet die Maschine sofort neu.

SIGRTMIN+16
Startet die Maschine sofort mit kexec neu.

SIGRTMIN+17
Startet den Benutzerraum sofort neu.

Hinzugefügt in Version 254.

SIGRTMIN+20
Aktiviert die Anzeige von Statusmeldungen auf der Konsole, wie dies mit
systemd.show_status=1 auf der Kernelbefehlszeile gesteuert wird.

SIGRTMIN+21
Deaktiviert die Anzeige von Statusmeldungen auf der Konsole, wie dies mit
systemd.show_status=0 auf der Kernelbefehlszeile gesteuert wird.

SIGRTMIN+22
Setzt die Protokollierstufe des Diensteverwalters auf »debug«, in einer Art, die
äquivalent zu systemd.log_level=debug auf der Kernelbefehlszeile ist.

SIGRTMIN+23
Stellt die Protokollierstufe wieder auf ihren konfigurierten Wert her. Der
konfigurierte Wert wird, in dieser Prioritätsreihenfolge, von dem mit
systemd.log-level= auf der Kernelbefehlszeile angegebenen Wert oder dem mit LogLevel=
in der Konfigurationsdatei angegebenen Wert oder dem eingebauten Wert »info«
abgeleitet.

Hinzugefügt in Version 239.

SIGRTMIN+24
Verlässt den Verwalter sofort (nur für --user-Instanzen verfügbar).

Hinzugefügt in Version 195.

SIGRTMIN+25
Nach Empfang dieses Signals führt der Systemd-Systemverwalter sich selbst erneut aus.
Dies ist größtenteils äquivalent zu systemctl daemon-reexec, außer dass es asynchron
erfolgt.

Der Systemd Systemverwalter behandelt dieses Signal auf die gleiche Art wie SIGTERM.

Hinzugefügt in Version 250.

SIGRTMIN+26
Stellt das Protokollierziel wieder auf seinen konfigurierten Wert her. Der
konfigurierte Wert wird, in dieser Prioritätsreihenfolge, von dem mit
systemd.log-target= auf der Kernelbefehlszeile angegebenen Wert oder dem mit
LogTarget= in der Konfigurationsdatei angegebenen Wert oder dem eingebauten Wert
abgeleitet.

Hinzugefügt in Version 239.

SIGRTMIN+27, SIGRTMIN+28
Setzt das Protokollierziel auf »console« bei SIGRTMIN+27 (oder »kmsg« bei
SIGRTMIN+28), in einer Art äquivalent zu systemd.log_target=console (oder
systemd.log_target=kmsg bei SIGRTMIN+28) auf der Kernelbefehlszeile.

Hinzugefügt in Version 239.

UMGEBUNGSVARIABLEN

Der Umgebungsblock für den Systemverwalter wird anfänglich vom Kernel gesetzt.
(Insbesondere werden »Schlüssel=Wert«-Zuweisungen auf der Kernelbefehlszeile in
Umgebungsvariablen für PID 1 umgewandelt). Für den Benutzerverwalter setzt der
Systemverwalter den Umgebungsblock, wie im Abschnitt »Umgebungsvariablen in erzeugten
Prozessen« von systemd.exec(5) beschrieben. Die Einstellung DefaultEnvironment= im
Systemverwalter gilt für alle Dienste, einschließlich user@.service. Mittels der
Einstellungen Environment= und EnvironmentFile= für user@.service können zusätzliche
Einträge (wie bei jedem anderen Dienst auch) konfiguriert werden (siehe systemd.exec(5)).
Es können auch zusätzliche Umgebungsvariablen mittels der Einstellung ManagerEnvironment=
in systemd-system.conf(5) und systemd-user.conf(5) gesetzt werden.

Einige der von systemd verstandenen Variablen:

$SYSTEMD_LOG_LEVEL
Die maximale Protokollierstufe für ausgegebene Meldungen (Meldungen mit einer höheren
Protokollierstufe, d.h. weniger wichtige, werden unterdrückt). Akzeptiert eine
Kommata-getrennte Liste von Werten. Ein Wert kann einer der folgenden sein (in
Reihenfolge absteigender Bedeutung): emerg, alert, crit, err, warning, notice, info,
debug oder eine Ganzzahl im Bereich 0…7. Siehe syslog(3) für weitere Informationen.
Jedem Wert kann optional einer aus console, syslog, kmsg oder journal gefolgt von
einem Doppelpunkt vorangestellt werden, um die maximale Protokollierstufe für dieses
spezielle Protokollierziel zu setzen (d.h. SYSTEMD_LOG_LEVEL=debug,console:info legt
fest, dass auf der Stufe »debug« protokolliert werden soll, außer beim Protokollieren
auf die Konsole, die auf Stufe »info« erfolgen soll). Beachten Sie, dass die globale
maximale Protokollierstufe Priorität gegenüber jeder zielbezogenen maximalen
Protokollierstufe hat.

Dies kann mit --log-level= außer Kraft gesetzt werden.

$SYSTEMD_LOG_COLOR
Ein logischer Wert. Falls wahr, werden auf das TTY geschriebene Nachrichten gemäß
ihrer Priorität eingefärbt.

Dies kann mit --log-color= außer Kraft gesetzt werden.

$SYSTEMD_LOG_TIME
Ein logischer Wert. Falls wahr, wird den Protokollnachrichten der Konsole ein
Zeitstempel vorangestellt.

Dies kann mit --log-time= außer Kraft gesetzt werden.

Hinzugefügt in Version 246.

$SYSTEMD_LOG_LOCATION
Ein logischer Wert. Falls wahr, wird den Protokollnachrichten ein Dateinamen und eine
Zeilenummer in dem Quellcode, aus dem die Nachrichten stammen, vorangestellt.

Dies kann mit --log-location= außer Kraft gesetzt werden.

$SYSTEMD_LOG_TID
Ein logischer Wert. Falls wahr, wird den Nachrichten die aktuelle numerische
Thread-Kennung (TID) vorangestellt.

Hinzugefügt in Version 247.

$SYSTEMD_LOG_TARGET
Das Ziel für Protokolliernachrichten. Entweder console (auf das angehängte TTY
protokollieren), console-prefixed (auf das angehängte TTY protokollieren, aber die
Protokollierstufe und »Einrichtung« voranstellen, siehe syslog(3)), kmsg (in den
zirkulären Kernel-Protokollpuffer protokollieren), journal (in das Journal
protokollieren (journal-or-kmsg (in das Journal protokollieren, falls verfügbar, und
andernfalls nach Kmsg), auto (das geeignete Protokollierziel automatisch ermitteln,
die Vorgabe) oder null (die Protokollierung deaktivieren).

Dies kann mit --log-target= außer Kraft gesetzt werden.

$SYSTEMD_LOG_RATELIMIT_KMSG
Ob Kmsg ratenlimitiert werden soll oder nicht. Akzeptiert einen logischen Wert.
Standardmäßig »true«. Falls deaktiviert, wird Systemd die nach Kmsg geschriebenen
Meldungen nicht ratenlimitieren.

Hinzugefügt in Version 254.

$XDG_CONFIG_HOME, $XDG_CONFIG_DIRS, $XDG_DATA_HOME, $XDG_DATA_DIRS
Der Systemd-Benutzerverwalter verwendet diese Variablen in Übereinstimmung mit der
XDG-Basisverzeichnisspezifikation[6], um seine Konfiguration zu finden.

$SYSTEMD_UNIT_PATH, $SYSTEMD_GENERATOR_PATH, $SYSTEMD_ENVIRONMENT_GENERATOR_PATH
Steuert, wo Systemd nach Unit-Dateien und Generatoren schaut.

Diese Variablen können eine Liste von Pfaden, getrennt durch Doppelpunkte (»:«),
enthalten. Ist dies gesetzt und endet mit der leeren Komponente (»…:«), wird diese
Liste der normalen Gruppe an Pfaden vorangestellt. Andernfalls ersetzt die angegebene
Liste die normale Gruppe an Pfaden.

$SYSTEMD_PAGER
Zu verwendendes Textanzeigeprogramm, wenn --no-pager nicht angegeben ist; setzt $PAGER
außer Kraft. Falls weder $SYSTEMD_PAGER noch $PAGER gesetzt sind, wird eine Reihe
wohlbekannter Implementierungen von Textanzeigeprogrammen der Reihe nach ausprobiert,
einschließlich less(1) und more(1), bis eines gefunden wird. Falls keine
Implementierung eines Textanzeigeprogramms gefunden wird, wird keines aufgerufen.
Setzen der Umgebungsvariablen auf die leere Zeichenkette oder den Wert »cat« ist
äquivalent zur Übergabe von --no-pager.

Beachten Sie: Falls $SYSTEMD_PAGERSECURE nicht gesetzt ist, dann wird $SYSTEMD_PAGER
(sowie $PAGER) ohne Rückmeldung ignoriert.

$SYSTEMD_LESS
Setzt die an less übergebenen Optionen (standardmäßig »FRSXMK«) außer Kraft.

Benutzer könnten insbesondere zwei Optionen ändern wollen:

K
Diese Option weist das Textanzeigeprogramm an, sich sofort beim Druck von Strg-C
zu beenden. Um less die Handhabung von Strg-C selbst zum Umschalten auf die
Eingabeaufforderung zu erlauben, setzen Sie diese Option zurück.

Falls der Wert von $SYSTEMD_LESS kein »K« enthält und less das aufgerufene
Textanzeigeprogramm ist, wird Strg+C durch das Programm ignoriert und muss durch
das Textanzeigeprogramm selbst gehandhabt werden.

X
Diese Option weist das Textanzeigeprogramm an, keine Termcap-Initialisierungs- und
-Deinitalisierungszeichenketten an das Terminal zu senden. Dies ist standardmäßig
gesetzt, damit die Darstellung von Befehlen selbst nach dem Beenden des
Textanzeigeprogramms sichtbar bleibt. Allerdings stehen dadurch einige Funktionen
des Textanzeigeprogramms nicht zur Verfügung; insbesondere ist das Scrollen in der
Ausgabe mit der Maus nicht möglich.

Beachten Sie, dass das Setzen der regulären Umgebungsvariablen $LESS keine
Auswirkungen auf die Ausführungen von less(1) durch systemd(1)-Werkzeuge hat.

Siehe less(1) für weitere Ausführungen.

$SYSTEMD_LESSCHARSET
Setzt den an less zu übergebenden Zeichensatz (standardmäßig »utf-8«, falls das
aufrufende Terminal als UTF-8-kompatibel erkannt wurde) außer Kraft.

Beachten Sie, dass das Setzen der regulären Umgebungsvariablen $LESSCHARSET keine
Auswirkungen auf die Ausführungen von less(1) durch systemd(1)-Werkzeuge hat.

$SYSTEMD_PAGERSECURE
Akzeptiert einen logischen Wert. Wenn wahr, wird der »sichere« Modus des
Textanzeigeprogramms verwandt, falls falsch, wird dieser deaktiviert. Falls
$SYSTEMD_PAGERSECURE überhaupt nicht gesetzt ist, dann wird der sichere Modus
aktiviert, falls die effektive Kennung nicht identisch zu dem Eigentümer der
Anmeldesitzung ist, siehe geteuid(2) und sd_pid_get_owner_uid(3). Im sicheren Modus
wird LESSSECURE=1 beim Aufruf des Textanzeigeprogramms gesetzt und das
Textanzeigeprogramm muss Befehle deaktivieren, die neue Dateien öffnen oder erstellen
oder die einen neuen Unterprozess starten. Falls $SYSTEMD_PAGERSECURE überhaupt nicht
gesetzt ist, werden Textanzeigeprogramme, bei denen unbekannt ist, ob sie einen
sicheren Modus implementieren, nicht verwandt. (Derzeit implementiert nur less(1)
einen sicheren Modus.)

Hinweis: Wenn Befehle mit erhöhten Rechten ausgeführt werden, beispielsweise mittels
sudo(8) oder pkexec(1), muss Vorsicht walten gelassen werden, um sicherzustellen, dass
keine ungeplanten interaktiven Funktionalitäten aktiviert werden. Der »sichere« Modus
für das Textanzeigeprogramm kann wie oben beschrieben automatisch aktiviert werden.
Durch Setzen von SYSTEMD_PAGERSECURE=0 oder durch Nichtenfernen dieser Einstellung aus
der ererbten Umgebung wird es dem Benutzer ermöglicht, beliebige Befehle auszuführen.
Beachten Sie, dass auch $SYSTEMD_PAGERSECURE gesetzt werden muss, falls die Variablen
$SYSTEMD_PAGER oder $PAGER berücksichtigt werden sollen. Es kann sinnvoll sein,
stattdessen das Textanzeigeprogramm komplett mit --no-pager zu deaktivieren.

$SYSTEMD_COLORS
Akzeptiert ein logisches Argument. Wenn wahr, werden systemd und verwandte
Hilfswerkzeuge Farben in ihrer Ausgabe verwenden, andernfalls wird die Ausgabe
einfarbig sein. Zusätzlich kann die Variable eine der folgenden besonderen Werte
annehmen: »16«, »256«, um die Verwendung von Farbe auf die grundlegenden 16 bzw. 256
ANSI-Farben zu beschränken. Dies kann festgelegt werden, um die auf $TERM und der
vorliegenden Verbindung der Konsole basierende automatische Entscheidung außer Kraft
zu setzen.

$SYSTEMD_URLIFY
Dies muss ein logischer Wert sein. Er steuert, ob anklickbare Links für
Terminal-Emulatoren, die dies unterstützen, erstellt werden sollen. Dies kann
angegeben werden, um die Entscheidung, die systemd basierend auf $TERM und anderen
Bedingungen trifft, außer Kraft zu setzen.

$LISTEN_PID, $LISTEN_FDS, $LISTEN_FDNAMES
Wird durch Systemd für überwachte Prozesse während Socket-basierter Aktivierung
gesetzt. Siehe sd_listen_fds(3) für weitere Informationen.

$NOTIFY_SOCKET
Set by service manager for its services for status and readiness notifications. Also
consumed by service manager for notifying supervising container managers or service
managers up the stack about its own progress. See sd_notify(3) and the relevant
section below for more information.

Für weitere Umgebungsvariablen, die von Systemd und seinen verschiedenen Komponenten
verstanden werden, siehe Bekannte Umgebungsvariablen[7].

KERNEL-BEFEHLSZEILE

Bei der Ausführung als Systeminstanz wertet Systemd eine Reihe von nachfolgend
aufgeführten Optionen aus. Diese können als Kernelbefehlszeilenargumente angegeben werden,
die von einer Reihe von Quellen ausgewertet werden, abhängig von der Umgebung, in der
Systemd ausgeführt wird. Beim Betrieb innerhalb eines Linux-Containers werden diese
Optionen, die von der Befehlszeile übergeben werden, von Systemd selbst ausgewertet, neben
allen Befehlzeilenoptionen, die in obigem Abschnitt Options aufgeführt sind. Beim Betrieb
von außerhalb von Linux-Containern werden diese Argumente stattdessen aus /proc/cmdline
und der EFI-Variable »SystemdOptions« (auf EFI-Systemen) auswerten. Optionen von
/proc/cmdline haben höhere Priorität.

Hinweis: Die Verwendung von »SystemdOptions« wird missbilligt.

Die folgenden Variablen werden verstanden:

systemd.unit=, rd.systemd.unit=
Setzt die beim Systemstart zu aktivierende Unit außer Kraft. Standardmäßig
default.target. Dies kann temporär zum Starten in eine andere Systemstart-Unit
verwandt werden, beispielsweise rescue.target oder emergency.service. Siehe
systemd.special(7) für Details über diese Units. Wird der Option »rd.« vorangestellt,
dann wird sie nur in der Initrd berücksichtigt, während die Option ohne diese
Zeichenkette am Anfang nur im Hauptsystem berücksichtigt wird.

systemd.dump_core
Akzeptiert ein logisches Argument oder aktiviert die Option, falls ohne Argument
angegeben. Falls aktiviert, wird der Systemverwalter (PID 1) einen Speicherauszug
schreiben, wenn er abstürzt. Andernfalls wird kein Speicherauszug erstellt.
Standardmäßig aktiviert.

Hinzugefügt in Version 233.

systemd.crash_chvt
Akzeptiert eine positive Ganzzahl oder ein logisches Argument. Kann auch ohne Argument
angegeben werden; dies hat den gleichen Effekt wie ein positiver logischer Wert. Falls
eine positive Ganzzahl (im Bereich 1…63) angegeben ist, wird der Systemverwalter (PID
1) die angegebene Anzahl an virtuellen Terminals erstellen, wenn er abstürzt.
Standardmäßig deaktiviert, was bedeutet, dass dies nicht versucht wird. Falls auf
aktiviert gesetzt, wird stattdessen das virtuelle Terminal, auf den die
Kernelnachrichten geschrieben werden, verwandt.

Hinzugefügt in Version 233.

systemd.crash_shell
Akzeptiert ein logisches Argument oder aktiviert die Option, falls ohne Argument
angegeben. Falls aktiviert, wird der Systemverwalter (PID 1) nach einer Verzögerung
von 10 Sekunden eine Shell starten, wenn er abstürzt. Andernfalls wird keine Shell
gestartet. Aus Sicherheitsgründen standardmäßig deaktiviert, da die Shell nicht durch
Passwortauthentifizierung geschützt ist.

Hinzugefügt in Version 233.

systemd.crash_action=
Takes one of "freeze", "reboot" or "poweroff". Defaults to "freeze". If set to
"freeze", the system will hang indefinitely when the system manager (PID 1) crashes.
If set to "reboot", the system manager (PID 1) will reboot the machine automatically
when it crashes, after a 10s delay. If set to "poweroff", the system manager (PID 1)
will power off the machine immediately when it crashes. If combined with
systemd.crash_shell, the configured crash action is executed after the shell exits.

Hinzugefügt in Version 256.

systemd.confirm_spawn
Akzeptiert ein logisches Argument oder einen Pfad zu einer virtuellen Konsole, auf der
Bestätigungsmeldungen ausgegeben werden sollen. Kann auch ohne Argument angegeben
werden; dies hat den gleichen Effekt wie ein positiver logischer Wert. Falls
aktiviert, wird der Systemverwalter (PID 1) um Bestätigung bitten, wenn er einen
Prozess mittels /dev/console startet. Falls ein Pfad oder Konsolename (wie »ttyS0«)
bereitgestellt wird, wird stattdessen die durch diesen Pfad angezeigte virtuelle
Konsole oder durch den übergebenen Namen beschriebene stattdessen verwandt.
Standardmäßig deaktiviert.

Hinzugefügt in Version 233.

systemd.service_watchdogs=
Akzeptiert ein logisches Argument. Falls deaktiviert, werden alle Laufzeit-Watchdogs
für Dienste (WatchdogSec=) und Notfallaktionen (z.B. OnFailure= oder
StartLimitAction=) durch den Systemverwalter (PID 1) ignoriert, siehe
systemd.service(5). Standardmäßig deaktiviert, d.h. Watchdogs und Fehlschlagaktionen
werden normal verarbeitet. Der Hardware-Watchdog ist durch diese Option nicht
betroffen.

Hinzugefügt in Version 237.

systemd.show_status
Akzeptiert ein logisches Argument oder die Konstanten error und auto. Kann auch ohne
Argument angegeben werden; dies hat den gleichen Effekt wie ein positiver logischer
Wert. Falls aktiviert, wird der Systemverwalter (PID 1) auf der Konsole beim
Systemstart knappe Dienstestatusaktualisierungen anzeigen. Bei error werden nur
Meldungen über Fehler angezeigt, der Systemstart erfolgt ansonsten still. auto verhält
sich wie false, bis es beim Systemstart zu signifikanten Verzögerungen kommt.
Standardmäßig aktiviert, außer quiet wird als Kernelbefehlszeilenoption angegeben. In
letzterem Fall ist die Vorgabe error. Ist dies angegeben, setzt es die
Konfigurationsdateioption ShowStatus= des Systemverwalters außer Kraft, siehe
systemd-system.conf(5).

Hinzugefügt in Version 233.

systemd.status_unit_format=
Akzeptiert name, description oder combined als Wert. Falls name, wird der
Diensteverwalter Unit-Namen in Statusmeldungen verwenden. Falls combined, wird der
Systemverwalter Unit-Namen und -Beschreibungen in Statusmeldungen verwenden. Wenn
angegeben, setzt dies die Konfigurationsoption StatusUnitFormat= des Systemverwalters
außer Kraft, siehe systemd-system.conf(5).

Hinzugefügt in Version 243.

systemd.log_color, systemd.log_level=, systemd.log_location, systemd.log_target=,
systemd.log_time, systemd.log_tid, systemd.log_ratelimit_kmsg
Steuert die Protokollausgabe, mit dem gleichen Effekt wie die oben beschriebenen
Umgebungsvariablen $SYSTEMD_LOG_COLOR, $SYSTEMD_LOG_LEVEL, $SYSTEMD_LOG_LOCATION,
$SYSTEMD_LOG_TARGET, $SYSTEMD_LOG_TIME$SYSTEMD_LOG_TID und
$SYSTEMD_LOG_RATELIMIT_KMSG. systemd.log_color, systemd.log_location,
systemd.log_time, systemd.log_tid= und systemd.log_ratelimit_kmsg können ohne
Argumente angegeben werden; dies hat den gleichen Effekt wie ein positiver logischer
Wert.

systemd.default_standard_output=, systemd.default_standard_error=
Steuert die Standardausgabe und Fehlerausgabe für alle Dienste und Sockets. D.h.
steuert die Vorgabe für StandardOutput= und StandardError= (siehe systemd.exec(5) für
Details). Akzeptiert einen aus inherit, null, tty, journal, journal+console, kmsg,
kmsg+console. Falls kein Argument angegeben wird, ist die Vorgabe für
systemd.default-standard-output= journal und für systemd.default-standard-error=
inherit.

systemd.setenv=
Akzeptiert ein Zeichenkettenargument in der Form VARIABLE=WERT. Kann zum Setzen der
Standardumgebungsvariablen, die mit Fork erstellten Kindern hinzugefügt werden sollen,
verwandt werden. Kann mehr als einmal verwandt werden, um mehrere Variablen zu setzen.

systemd.machine_id=
Akzeptiert einen 32-Zeichen-Hexadezimalwert zum Setzen der Maschinenkennung.
Hauptsächlich für den Systemstart über das Netzwerk gedacht, bei dem die gleiche
Maschinenkennung für jeden Systemstart erwünscht ist.

Hinzugefügt in Version 229.

systemd.set_credential=, systemd.set_credential_binary=
Setzt eine Systemzugangsberechtigung, die mittels der Einstellung ImportCredential=
oder LoadCredential= an Systemdienste weitergeleitet werden kann, siehe
systemd.exec(5) für Details. Akzeptiert ein Paar bestehend aus Zugangsberechtigung und
-namen, getrennt durch Doppelpunkt. Der Parameter systemd.set_credential= erwartet den
Zugangsberechtigungswert in wörtlicher Textform, der Parameter
systemd.set_credential_binary= akzeptiert als Base64 kodierte Binärdaten. Beachten
Sie, dass von nicht privilegierten Programmen in /proc/cmdline typischerweise auf die
Kernel-Befehlszeile zugegriffen werden kann. Daher ist dieser Mechanismus nicht für
die Übertragung vertraulicher Daten geeignet. Verwenden Sie ihn nur für Daten, die
nicht vertraulich sind (z.B. öffentliche Schlüssel/Zertifikate statt privater
Schlüssel) oder in Test-/Fehlersuchumgebungen.

Siehe die Dokumentation der System- und Dienste-Zugangsberechtigungen[8] für weitere
Details.

Hinzugefügt in Version 251.

systemd.import_credentials=
Akzeptiert ein logisches Argument. Falls falsch, deaktiviert den Import von
Zugangsberechtigungen aus der Kernel-Befehlszeile, der
DMI/SMBIOS-OEM-Zeichenketten-Tabelle, dem qemu_fw_cfg-Sybsystem oder dem
EFI-Kernel-Rumpf.

Hinzugefügt in Version 251.

quiet
Schaltet Statusausgaben beim Systemstart aus, ähnlich wie dies systemd.show_status=no
täte. Beachten Sie, dass diese Option auch vom Kernel selbst gelesen wird und
Kernelprotokollierungsausgaben deaktiviert. Die Übergabe dieser Option schaltet daher
die normale Ausgabe sowohl vom Systemverwalter als auch dem Kernel aus.

Hinzugefügt in Version 186.

debug
Schaltet den Fehlersuchmodus ein. Dies ist äquivalent zu systemd.log_level=debug.
Beachten Sie, dass diese Option auch vom Kernel selbst gelesen wird und die
Kernel-Fehlersuchausgabe aktiviert. Die Übergabe dieser Option schaltet daher die
Fehlersuchausgabe sowohl vom Systemverwalter als auch des Kernels ein.

Hinzugefügt in Version 205.

emergency, rd.emergency, -b
Systemstart in den Notfallmodus. Dies ist zu systemd.unit=emergency.target bzw.
rd.systemd.unit=emergency.target äquivalent und wird aus Kompatibilitätsgründen und da
es leichter zu tippen ist, bereitgestellt.

Hinzugefügt in Version 186.

rescue, rd.rescue, single, s, S, 1
Systemstart in den Rettungsmodus. Dies ist zu systemd.unit=rescue.target bzw.
rd.systemd.unit=rescue.target äquivalent und wird aus Kompatibilitätsgründen und da es
leichter zu tippen ist, bereitgestellt.

Hinzugefügt in Version 186.

2, 3, 4, 5
Systemstart in den angegebenen veralteten SysV-Runlevel. Dies ist zu
systemd.unit=runlevel2.target, systemd.unit=runlevel3.target,
systemd.unit=runlevel4.target bzw. systemd.unit=runlevel5.target äquivalent und wird
aus Kompatibilitätsgründen und da es leichter zu tippen ist, bereitgestellt.

Hinzugefügt in Version 186.

locale.LANG=, locale.LANGUAGE=, locale.LC_CTYPE=, locale.LC_NUMERIC=, locale.LC_TIME=,
locale.LC_COLLATE=, locale.LC_MONETARY=, locale.LC_MESSAGES=, locale.LC_PAPER=,
locale.LC_NAME=, locale.LC_ADDRESS=, locale.LC_TELEPHONE=, locale.LC_MEASUREMENT=,
locale.LC_IDENTIFICATION=
Setzt die zu verwendende System-Locale. Dies setzt die Einstellungen in
/etc/locale.conf außer Kraft. Für weitere Informationen siehe locale.conf(5) und
locale(7).

Hinzugefügt in Version 186.

Für weitere von Komponenten des Kernbetriebssystems verstandene
Kernelbefehlszeilenparameter siehe kernel-command-line(7).

SYSTEMZUGANGSBERECHTIGUNGEN

Während der Initialisierung wird der Diensteverwalter Zugangsberechtigungen aus
verschiedenen Stellen in den Satz der Zugangsberechtigungen des Systems importieren. Dies
kann dann an Dienste weitergeleitet und von Generatoren verwandt werden:

• Wenn sich der Diensteverwalter erstmals initialisiert, wird er die
Systemzugangsberechtigungen aus SMBIOS-Typ-11-Lieferantenzeichenketten
io.systemd.credential:Name=Wert und io.systemd.credential.binary:Name=Wert lesen.

• Gleichzeitig wird er Zugangsberechtigungen von QEMUs »fw_cfg« importieren. (Beachten
Sie, dass der SMBIOS-Mechanismus im Allgemeinen bevorzugt wird, da er scheller und
generisch ist.)

• Zugangsberechtigungen können wie oben beschrieben über die Kernelbefehlszeile mittels
des Parameters systemd.set-credential= übergeben werden.

• Zugangsberechtigungen können von der UEFI-Umgebung mittels systemd-stub(7) übergeben
werden.

• Wenn der Diensteverwalter während des Übergangs Initrd → Hauptsystem aufgerufen wird,
wird er alle Dateien in /run/credentials/@initrd/ als Systemzugangsberechtigungen
importieren.

Rufen Sie systemd-creds(1) wie folgt auf, um eine Liste der an das System übergebenen
Zugangsberechtigungen zu sehen:

# systemd-creds --system list

Siehe die Dokumentation der System- und Dienste-Zugangsberechtigungen[8] für weitere
Details.

Wenn der Diensteverwalter als PID 1 ausgeführt wird, verwendet er die folgenden
Systemzugangsberechtigungen:

vmm.notify_socket
Contains a AF_VSOCK or AF_UNIX address where to send a READY=1 notification message
when the service manager has completed booting. See sd_notify(3) and the next section
for more information. Note that in case the hypervisor does not support SOCK_DGRAM
over AF_VSOCK, SOCK_SEQPACKET will be tried instead. The credential payload for
AF_VSOCK should be a string in the form "vsock:CID:PORT". "vsock-stream",
"vsock-dgram" and "vsock-seqpacket" can be used instead of "vsock" to force usage of
the corresponding socket type.

Diese Funktionalität ist für Maschinenverwalter oder andere Prozesse auf dem Rechner
nützlich, um eine Benachrichtigung über VSOCK zu erhalten, wenn eine virtuelle
Maschine mit dem Starten fertig ist.

Hinzugefügt in Version 254.

system.machine_id
Akzeptiert eine hexadezimale 128-bit Kennung, aus der /etc/machine-id initialisiert
wird, falls die Datei noch nicht eingerichtet ist. Siehe machine-id(5) zu Details.

Hinzugefügt in Version 254.

For a list of system credentials various other components of systemd consume, see
systemd.system-credentials(7).

READINESS PROTOCOL

The service manager implements a readiness notification protocol both between the manager
and its services (i.e. down the stack), and between the manager and a potential supervisor
further up the stack (the latter could be a machine or container manager, or in case of a
per-user service manager the system service manager instance). The basic protocol (and the
suggested API for it) is described in sd_notify(3).

The notification socket the service manager (including PID 1) uses for reporting readiness
to its own supervisor is set via the usual $NOTIFY_SOCKET environment variable (see
above). Since this is directly settable only for container managers and for the per-user
instance of the service manager, an additional mechanism to configure this is available,
in particular intended for use in VM environments: the vmm.notify_socket system credential
(see above) may be set to a suitable socket (typically an AF_VSOCK one) via SMBIOS Type 11
vendor strings. For details see above.

The notification protocol from the service manager up the stack towards a supervisor
supports a number of extension fields that allow a supervisor to learn about specific
properties of the system and track its boot progress. Specifically the following fields
are sent:

• An X_SYSTEMD_HOSTNAME=... message will be sent out once the initial hostname for the
system has been determined. Note that during later runtime the hostname might be
changed again programmatically, and (currently) no further notifications are sent out
in that case.

Hinzugefügt in Version 256.

• An X_SYSTEMD_MACHINE_ID=... message will be sent out once the machine ID of the system
has been determined. See machine-id(5) for details.

Hinzugefügt in Version 256.

• An X_SYSTEMD_SIGNALS_LEVEL=... message will be sent out once the service manager
installed the various UNIX process signal handlers described above. The field's value
is an unsigned integer formatted as decimal string, and indicates the supported UNIX
process signal feature level of the service manager. Currently, only a single feature
level is defined:

• X_SYSTEMD_SIGNALS_LEVEL=2 covers the various UNIX process signals documented above
– which are a superset of those supported by the historical SysV init system.

Signals sent to PID 1 before this message is sent might not be handled correctly yet.
A consumer of these messages should parse the value as an unsigned integer indication
the level of support. For now only the mentioned level 2 is defined, but later on
additional levels might be defined with higher integers, that will implement a
superset of the currently defined behaviour.

Hinzugefügt in Version 256.

• X_SYSTEMD_UNIT_ACTIVE=... and X_SYSTEMD_UNIT_INACTIVE=... messages will be sent out
for each target unit as it becomes active or stops being active. This is useful to
track boot progress and functionality. For example, once the ssh-access.target unit is
reported started SSH access is typically available, see systemd.special(7) for
details.

Hinzugefügt in Version 256.

• An X_SYSTEMD_SHUTDOWN=... message will be sent out very shortly before the system
shuts down. The value is one of the strings "reboot", "halt", "poweroff", "kexec" and
indicates which kind of shutdown is being executed.

Hinzugefügt in Version 256.

• An X_SYSTEMD_REBOOT_PARAMETER=... message will also be sent out very shortly before
the system shuts down. Its value is the reboot argument as configured with systemctl
--reboot-argument=....

Hinzugefügt in Version 256.

Note that these extension fields are sent in addition to the regular "READY=1" and
"RELOADING=1" notifications.

OPTIONEN

Systemd wird nur sehr selten direkt aufgerufen, da es früh gestartet wird und bereits
läuft, wenn Benutzer mit ihm interagieren. Normalerweise werden Werkzeuge wie systemctl(1)
verwandt, um Befehle an den Verwalter abzusetzen. Da systemd normalerweise nicht direkt
aufgerufen wird, sind die nachfolgend aufgeführten Optionen hauptsächlich zur Fehlersuche
und für besondere Zwecke nützlich.

Optionen zur Selbstprüfung und Fehlersuche
Diese Optionen werden zum Testen und zur Selbstprüfung verwandt und systemd kann mit ihnen
jederzeit aufgerufen werden:

--dump-configuration-items
Gibt die verstandenen Unit-Konfigurationselemente aus. Diese Ausgabe ist eine knappe,
aber komplette Liste aller Konfigurationselemente in Unit-Definitionsdateien.

--dump-bus-properties
Gibt offengelegte Buseigenschaften aus. Diese Ausgabe ist eine knappe, aber komplette
Liste von Eigenschaften, die auf D-Bus offengelegt sind.

Hinzugefügt in Version 239.

--test
Bestimmt die anfängliche Hochfahrtransaktion (d.h. die Liste der beim Hochfahren in
die Warteschlange eingereihten Aufträge), gibt sie aus und beendet sich, ohne
tatsächlich irgend einen der bestimmten Aufträge auszuführen. Diese Option ist nur zur
Fehlersuche nützlich. Beachten Sie, dass während des regulären Hochfahrens des
Diensteverwalters Units, die von dieser Aktion nicht angezeigt werden, gestartet
werden könnten, da Hardware, Sockets, Busse oder andere Arten von Aktivierungen
zusätzliche Aufträge während der Ausführung der Transaktion hinzufügen könnnten.
Verwenden Sie --system, um die anfängliche Transaktion des Systemdiensteverwalters zu
erbitten (was die implizite Vorgabe ist). Kombinieren Sie mit --user, um stattdessen
die anfängliche Transaktion für den benutzerbezogenen Diensteverwalter zu erbitten.

--system, --user
Wählt aus, ob die anfängliche Transaktion für die Systeminstanz oder für die
benutzerbezogene Instanz berechnet werden soll, wenn zusammen mit --test verwandt.
Diese Option hat keine Wirkung ohne --test, da während des regulären (d.h. ohne
--test) Aufrufs der Diensteverwalter automatisch erkennen wird, ob er im System- oder
benutzerbezogenen Modus agieren soll, indem er prüft, ob die PID, unter der er laufen
soll, 1 ist oder nicht. Beachten Sie, dass das Starten und Betreiben eines Systems,
bei dem der Systemverwalter im Modus --system aber mit einer von 1 verschiedenen PID
läuft, nicht unterstützt wird.

-h, --help
Zeigt einen kurzen Hilfetext an und beendet das Programm.

--version
Zeigt eine kurze Versionszeichenkette an und beendet das Programm.

Optionen, die Kernelbefehlszeileneinstellungen duplizieren
Diese Optionen entsprechen direkt den oben unter »Kernel-Befehlszeile« aufgeführten
Optionen. Beide Formen können gleichwertig für den Systemverwalter verwandt werden, aber
es wird empfohlen, in diesem Zusammenhang die oben aufgeführten Formen einzusetzen, da
ihnen ein korrekter Namensraum zugewiesen ist. Wenn eine Option sowohl auf der
Kernelbefehlszeile als auch als normales Befehlszeilenargument angegeben ist, hat letztere
höheren Vorrang.

Wird systemd als Benutzerverwalter eingesetzt, wird die Kernelbefehlzeile ignoriert und
nur die beschriebenen Optionen werden verstanden. Da systemd normalerweise durch den
Dienst user@.service(5) in diesem Modus gestartet wird und der Dienst von allen Benutzer
gemeinsam verwandt wird, kann es bequemer sein, die Konfigurationsdatei oder
Umgebungsvariablen zu verwenden, um Einstellungen zu verändern (siehe
systemd-user.conf(5)). Siehe den obigen Abschnitt »Umgebungsvariablen« für eine
Diskussion, wie der Umgebungsblock gesetzt wird.

--unit=
Setzt die beim Starten zu aktivierende Vorgabe-Unit. Falls nicht angegeben, ist die
Vorgabe default.target. Siehe systemd.unit= weiter oben.

--dump-core
Beim Absturz Kernspeicherabzüge aktivieren. Dieser Schalter hat beim Betrieb als
Benutzerinstanz keinen Effekt. Identisch zu systemd.dump_core= weiter oben.

--crash-vt=VT
Beim Absturz auf eine bestimmte virtuelle Konsole (VT) umschalten. Dieser Schalter hat
beim Betrieb als Benutzerinstanz keine Wirkung. Identisch zu systemd.crash_chvt= oben
(beachten Sie aber die andere Schreibweise).

Hinzugefügt in Version 227.

--crash-shell
Führt beim Systemabsturz eine Shell aus. Dieser Schalter hat beim Betrieb als
Benutzerinstanz keinen Effekt. Siehe systemd.crash_shell= weiter oben.

--crash-action=
Specify what to do when the system manager (PID 1) crashes. This switch has no effect
when systemd is running as user instance. See systemd.crash_action= above.

Hinzugefügt in Version 256.

--confirm-spawn
Beim Öffnen von Prozessen um Bestätigung bitten. Dieser Schalter hat beim Betrieb als
Benutzerinstanz keinen Effekt. Siehe systemd.confirm_spawn weiter oben.

--show-status
Zeigt knappe Unit-Statusinformationen während des Hochfahrens und Herunterfahrens auf
der Konsole. Siehe systemd.show_status oben.

Hinzugefügt in Version 244.

--log-color
Hebt wichtige Protokollmeldungen hervor. Siehe systemd.log_color oben.

Hinzugefügt in Version 244.

--log-level=
Setzt Protokollierstufe. Siehe systemd.log_level weiter oben.

--log-location
Schließt den Ort im Code in Protokollmeldungen ein. Siehe systemd.log_location oben.

Hinzugefügt in Version 244.

--log-target=
Setzt Protokollierziel. Siehe systemd.log_target weiter oben.

--log-time=
Stellt Nachrichten der Konsole einen Zeitstempel voran. Siehe systemd.log_time weiter
oben.

Hinzugefügt in Version 246.

--machine-id=
Setzt die auf der Festplatte gesetzte Maschinenkennung außer Kraft. Siehe
systemd.machine_id= oben.

Hinzugefügt in Version 229.

--service-watchdogs
Global alle Dienste-Watchdog-Zeitüberschreitungen und Notfallaktionen
aktivieren/deaktivieren. Siehe systemd.service_watchdogs weiter oben.

Hinzugefügt in Version 237.

--default-standard-output=, --default-standard-error=
Setzt die Vorgabe-Standardausgabe und -Fehlerausgabe für alle Dienste bzw. Sockets.
Siehe systemd.default_standard_output= und systemd.default_standard_error= oben.

SOCKETS UND FIFOS

       /run/systemd/notify
           Daemon-Statusbenachrichtigungs-Socket. Dies ist ein AF_UNIX-Datagram-Socket, das zur
           Implementierung der Benachrichtigungslogik des Daemons mit sd_notify(3) verwandt wird.

       /run/systemd/private
           Wird intern als Kommunikationskanal zwischen systemctl(1) und dem Systemd-Prozess
           verwandt. Dies ist ein AF_UNIX-Stream-Socket. Diese Schnittstelle ist für Systemd
           privat und sollte in externen Projekten nicht verwandt werden.

       /dev/initctl
           Eingeschränkte Kompatibilitätsunterstützung für SysV-Client-Schnittstellen, wie sie
           von der Unit systemd-initctl.service implementiert wird. Dies ist eine benannte Pipe
           im Dateisystem. Diese Schnittstelle ist veraltet und sollte in neuen Anwendungen nicht
           verwandt werden.

GESCHICHTE

       systemd 252
           Die Kernel-Befehlszeilenargumente systemd.unified_cgroup_hierarchy und
           systemd.legacy_systemd_cgroup_controller wurden als veraltet gekennzeichnet. Bitte
           stellen Sie auf die vereinigte Cgroup-Hierarchie um.

           Hinzugefügt in Version 252.

SIEHE AUCH

       Die Systemd-Homepage[9], systemd-system.conf(5), locale.conf(5), systemctl(1),
       journalctl(1), systemd-notify(1), daemon(7), sd-daemon(3), org.freedesktop.systemd1(5),
       systemd.unit(5), systemd.special(7), pkg-config(1), kernel-command-line(7), bootup(7),
       systemd.directives(7)

ANMERKUNGEN

        1. Control-Gruppen v2
           https://docs.kernel.org/admin-guide/cgroup-v2.html

        2. Ursprüngliches Designdokument
           https://0pointer.de/blog/projects/systemd.html

        3. Schnittstellenportabilitäts- und -stabilitätszusage
           https://systemd.io/PORTABILITY_AND_STABILITY/

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

        5. Initrd-Schnittstelle
           https://systemd.io/INITRD_INTERFACE/

        6. XDG-Basisverzeichnisspezifikation
           https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html

        7. Bekannte Umgebungsvariablen
           https://systemd.io/ENVIRONMENT

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

        9. Systemd-Homepage
           https://systemd.io/

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