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.
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/, /proc/ und /dev/, ein
und hängt sie ein.
Beachten Sie, dass einige, aber nicht alle, durch Systemd
bereitgestellte Schnittstellen von der Schnittstellenportierungs und
-stabilitätszusage[1] abgedeckt sind.
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[2] bzw. initrd-Schnittstelle[3]
implementieren.
UNITS¶
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[4] 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.
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).
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[5] 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¶
Der Dienste wartet auf die Signale verschiedener UNIX-Prozesse,
die dazu verwandt werden können, verschiedene Aktionen asynchron zu
erbitten. Die Signal-Handhabung wird sehr früh im Systemstart
aktiviert, bevor irgendwelche Prozesse aufgerufen werden. Allerdings muss
ein überwachender Container-Verwalter oder ähnliches, der
plant, diese Aktionen mittels dieses Mechanismus zu erbitten,
berücksichtigen, dass diese Funktionalität nicht
während der allerfrühsten Initialisierungsphase
verfügbar ist. Wie nachfolgend beschrieben wird wird eine
sd_notify(3)-Nachricht ausgesandt, die das Feld
X_SYSTEMD_SIGNALS_LEVEL=2 enthält, sobald die Signalhandhaber
aktiviert sind. Dies kann dazu verwandt werden, die Einreichung dieser
Signale korrekt einzuplanen.
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 eine Zeichenkette 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 Dateiname 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[5],
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ührung
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
Wird durch den Diensteverwalter für seine Dienste
für die Status- und Bereitschaftsbenachrichtigungen gesetzt. Wird auch
vom Diensteverwalter zur Benachrichtigungen von überwachenden
Container-Verwaltern oder übergeordneten Dienstervewaltern über
seine eigenen Fortschritt konsumiert. Siehe
sd_notify(3) und den
relevanten nachfolgenden Abschnitt für weitere Informationen.
Für weitere Umgebungsvariablen, die von Systemd und seinen
verschiedenen Komponenten verstanden werden, siehe Bekannte
Umgebungsvariablen[6].
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[7] 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[7] 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.
Eine Liste von Systemzugangsberechtigungen, die verschiedene
andere Komponenten von Systemd konsumieren, finden Sie in
systemd.system-credentials(7).
BEREITSCHAFTSPROTOKOLL¶
Der Diensteverwalter implementiert ein
Bereitschafts-Benachrichtigungsprotokoll, sowohl zwischen dem Verwalter und
seinen Diensten (d. zu den nachgeordneten Teilen) als auch zwischen dem
Verwalter und einem möglichen übergeordneten Überwacher
(letzerer könnte ein Maschinen- oder Container-Verwalter sein, oder
im Falle eines benutzerbezogenen Diensteverwalters die Instanz des
System-Diensteverwalters). Das grundlegende Protokoll (und die dafür
vorgeschlagene API) sind in sd_notify(3) beschrieben.
Das vom Diensteverwalter (einschließlich PID 1) für
die Meldung der Bereitschaft an seinen eigenen Supervisor verwandte
Benachrichtigungs-Socket wird mittels der Umgebungsvariablen
$NOTIFY_SOCKET gesetzt (siehe oben). Da diese nur für
Container-Verwalter und für die benutzerbezogene Instanz des
Diensteverwalters setzbar ist, ist ein zusätzlicher Mechanismus zur
Konfiguration davon verfügbar, der insbesondere für
VM-Umgebungen gedacht ist: Die Systemzugangsberechtigung
vmm.notify_socket (siehe oben) kann mittels
SMBIOS-Type-11-Lieferantenzeichenketten auf ein geeignetes Socket
(typischerweise der Art AF_VSOCK) gesetzt werden. Details hierzu
finden Sie weiter oben.
Das Benachrichtigungsprotokoll vom Diensteverwalter zu
übergeordneten Supervisoren unterstützt eine Reihe von
Erweiterungsfeldern, die es einem Supervisor ermöglichen,
Informationen über bestimmte Eigenschaften des Systems zu erlangen
und dessen Systemstartvorgang nachzuverfolgen. Konkret werden die folgenden
Felder gesandt:
•Die Meldung
X_SYSTEMD_HOSTNAME=\[u2026]
wird ausgesandt, sobald der anfängliche Rechnername für das
System bestimmt wurde. Beachten Sie, dass während der weiteren Laufzeit
der Rechnername programatisch geändert werden kann und (derzeit) in
diesem Fall keine weiteren Benachrichtigungen ausgesandt werden.
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[8], 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)
Für weitere Informationen über die Konzepte und
Ideen hinter Systemd wird auf das Ursprüngliches
Designdokument[9] verwiesen.
ANMERKUNGEN¶
- 1.
- Schnittstellenportabilitäts- und -stabilitätszusage
- 2.
- Container-Schnittstelle
- 3.
- Initrd-Schnittstelle
- 4.
- Control-Gruppen v2
- 5.
- XDG-Basisverzeichnisspezifikation
- 6.
- Bekannte Umgebungsvariablen
- 7.
- System- und Dienste-Zugangsberechtigungen
- 8.
- Systemd-Homepage
- 9.
- Ursprüngliches Designdokument
Ü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.
