systemd, init - Systemd-System und Diensteverwalter
ÜBERSICHT
/lib/systemd/systemd [OPTIONEN…]
init [OPTIONEN…] {BEFEHL}
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 Benutzerraumdienste verwaltet.
Für die Kompatibilität mit SysV wird Systemd, falls
es als init und einer von 1 verschiedenen PID aufgerufen wird,
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.
Die folgenden Optionen werden verstanden:
--test
Bestimmt die Startsequenz, gibt sie aus und beendet sich.
Diese Option ist nur für die Fehlersuche nützlich.
--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 dem Bus offengelegt
sind.
--unit=
Setzt die beim Starten zu aktivierende Vorgabe-Unit.
Falls nicht angegeben, ist die Vorgabe default.target.
--system, --user
Mit --system wird Systemd mitgeteilt, eine
Systeminstanz auszuführen, selbst wenn die Prozesskennung nicht 1 ist,
d.h. Systemd nicht als Init-Prozess läuft. --user führt
zum Gegenteil, der Ausführung als Benutzerinstanz, selbst falls die
Prozesskennung 1 ist. Normalerweise sollte es nicht notwendig sein, diese
Optionen zu übergeben, da Systemd automatisch den Modus, in dem es
gestartet wurde, erkennt. Diese Optionen haben daher einen geringen Nutzwert,
außer für die Fehlersuche. Beachten Sie, dass das Starten und
Verwalten eines kompletten Systems mit Systemd im Modus --system aber
nicht mit PID 1 nicht unterstützt wird. In der Praxis ist die explizite
Übergabe von --system nur im Zusammenhang mit --test
nützlich.
--dump-core
Beim Absturz Kernspeicherabzüge aktivieren. Dieser
Schalter hat beim Betrieb als Benutzerinstanz keinen Effekt. Diese Einstellung
kann auch während des Systemstarts auf der Kernelbefehlszeile mittels
der Option systemd.dump_core= aktiviert werden, siehe unten.
--crash-vt=VT
Beim Systemabsturz auf eine bestimmte virtuelle Konsole
(VT) umschalten. Akzeptiert eine positive Ganzzahl im Bereich 1–63 oder
ein logisches Argument. Falls eine Ganzzahl übergeben wird, wird das
VT, auf das umgeschaltet wird, ausgewählt. Falls yes, wird das
VT ausgewählt, auf das die Kernelmeldungen geschrieben werden. Bei
no wird keine VT-Umschaltung versucht. Dieser Schalter hat beim Betrieb
als Benutzerinstanz keinen Effekt. Diese Einstellung kann auch während
des Systemstarts auf der Kernelbefehlszeile mittels der Option
systemd.crash_vt= aktiviert werden, siehe unten.
--crash-shell
Führt beim Systemabsturz eine Shell aus. Dieser
Schalter hat beim Betrieb als Benutzerinstanz keinen Effekt. Diese Einstellung
kann auch während des Systemstarts auf der Kernelbefehlszeile mittels
der Option systemd.crash_shell= aktiviert werden, siehe unten.
--crash-reboot
Beim Systemabsturz automatisch das System neustarten.
Dieser Schalter hat beim Betrieb als Benutzerinstanz keinen Effekt. Diese
Einstellung kann auch während des Systemstarts auf der
Kernelbefehlszeile mittels der Option systemd.crash_reboot= aktiviert
werden, siehe unten.
--confirm-spawn
Beim Öffnen von Prozessen um Bestätigung
bitten. Dieser Schalter hat beim Betrieb als Benutzerinstanz keinen
Effekt.
--show-status=
Akzeptiert ein logisches Argument oder den besonderen
Wert
auto. Falls eingeschaltet wird während des Hoch- und
Runterfahrens des Systems eine knappe Unit-Start-Information angezeigt. Falls
ausgeschaltet werden keine solchen Statusinformationen angezeigt. Falls auf
auto gesetzt ist, ist das Verhalten ähnlich des ausgeschalteten
Zustands, außer dass sie automatisch eingeschaltet wird, sobald die
erste Unit fehlschlägt oder eine deutliche Verzögerung beim
Systemstart auftritt. Dieser Schalter hat beim Betrieb als Benutzerinstanz
keinen Effekt. Falls angegeben, setzt sie sowohl die
Kernelbefehlszeileneinstellung
systemd.show_status= (siehe unten) als
auch die Konfigurationsdateioption
ShowStatus= außer Kraft,
siehe
systemd-system.conf(5).
--log-target=
Setzt das Protokollierziel. Argument muss entweder
console, journal, kmsg, journal-or-kmsg oder
null sein.
--log-level=
Setzt die Protokollierstufe. Als Argument wird eine
numerische Protokollierstufe oder die gut bekannten symbolischen Namen von
syslog(3) (in Kleinschreibung) akzeptiert:
emerg,
alert,
crit,
err,
warning,
notice,
info,
debug.
--log-color=
Wichtige Protokolliermeldungen hervorheben. Argument ist
ein logischer Wert. Falls das Argument fehlt, ist die Vorgabe
true.
--log-location=
Code-Stelle in Protokollnachrichten aufnehmen. Dies ist
hauptsächlich für Fehlersuchzwecke relevant. Argument ist ein
logischer Wert. Falls das Argument fehlt ist die Vorgabe true.
--default-standard-output=,
--default-standard-error=
Setzt die Standardausgabe oder Fehlerausgabe für
alle Dienste bzw. 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,
syslog,
syslog+console,
kmsg,
kmsg+console. Falls kein Argument
angegeben wird, ist die Vorgabe für
--default-standard-output=
journal und für
--default-standard-error=
inherit.
--machine-id=
Setzt die Maschinenkenung auf der Festplatte außer
Kraft. Dies ist für das Starten über Netz oder für
Container nützlich. Kann nicht komplett auf Nullen gesetzt
werden.
--service-watchdogs=
Global alle Dienste-Watchdog-Zeitüberschreitungen
und Notfallaktionen aktivieren/deaktivieren. Diese Einstellung kann auch auf
der Kernelbefehlszeile mit der Option systemd.service_watchdogs=
während des Systemstarts festgelegt werden, siehe unten.
Standardmäßig aktiviert.
-h, --help
Zeigt einen kurzen Hilfetext an und beendet das
Programm.
--version
Zeigt eine kurze Versionszeichenkette an und beendet das
Programm.
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 anderer Konfiguration, 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 protokollierta. 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 Automount-Fähigkeiten
bereit, für bedarfsgesteuertes Einhängen von Dateisystemen sowie
parallelisiertem Systemstart. Siehe
systemd.automount(5).
7.Zeitgeber-Units sind für das Auslösen
der Aktivierung von anderen Units basierend auf Zeitgebern 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 fehlschalgen, 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 obligt aber dem Administrator, sie als Alias zu
jeder anderen Ziel-Unit zu konfigurieren. Siehe systemd.special(7)
für Details über diese Ziel-Units.
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 in irgendeiner Art eine Abhängigkeit
von mindestens einer anderen im Speicher geladenen Unit
4.Sie hat irgendeine Form von Ressourcen noch 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
cgroups.txt[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/systemd/) 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-Skripts 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). Falls dies nicht
der Fall ist, wird Systemd versuchen, sie zu korrigieren und entfernt alle
nicht wesentlichen 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
Laufwarteschlange hinzugefügt. Effektiv bedeutet dies, dass vor der
Ausführung einer angefragten Aktion Systemd ü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
Schnittstellenstabilitä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).
Systeme, die Systemd in einem Container oder in einer
Initrd-Umgebung aufrufen, sollten die Spezifikation
Container-Schnittstelle[4] bzw. initrd-Schnittstelle[5]
implementieren.
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 /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 sowhl 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 (mit entfernter 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.
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-irreversible.
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-irreversible. 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 sicherere 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-irreversible.
SIGRTMIN+4
Schaltet die Maschine aus, startet die Unit
poweroff.target. Dies ist größtenteils äquivalent zu
systemctl start poweroff.target
--job-mode=replace-irreversible.
SIGRTMIN+5
Startet die Maschine neu, startet die Unit reboot.target.
Dies ist größtenteils äquivalent zu systemctl start
reboot.target --job-mode=replace-irreversible.
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-irreversible.
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+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 festgelegten Wert oder dem mit LogLevel= in der
Konfigurationsdatei festgelegten Wert oder dem eingebauten Wert
»info« abgeleitet.
SIGRTMIN+24
Verlässt den Verwalter sofort (nur für
--user-Instanzen verfügbar).
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 festgelegten Wert oder dem mit LogTarget= in der
Konfigurationsdatei festgelegten Wert oder dem eingebauten Wert
abgeleitet.
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.
$SYSTEMD_LOG_LEVEL
Systemd liest die Protokollierstufe aus dieser
Umgebungsvariablen. Dies kann mit --log-level= außer Kraft
gesetzt werden.
$SYSTEMD_LOG_TARGET
Systemd liest das Protokollierziel aus dieser
Umgebungsvariablen. Dies kann mit --log-target= außer Kraft
gesetzt werden.
$SYSTEMD_LOG_COLOR
Steuert, ob Systemd wichtige Protokollnachrichten
hervorhebt. Dies kann mit --log-color= außer Kraft gesetzt
werden.
$SYSTEMD_LOG_LOCATION
Steuert, ob Systemd den Code-Ort zusammen mit der
Protokollnachricht ausgibt. Dies kann mit --log-location= außer
Kraft gesetzt werden.
$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
Steuert, wo Systemd nach Unit-Dateien schaut.
$SYSTEMD_SYSVINIT_PATH
Steuert, wo Systemd nach SysV-Init-Skripten schaut.
$SYSTEMD_SYSVRCND_PATH
Steuert, wo Systemd nach
SysV-Init-Skript-Runlevel-Linksammlungen schaut.
$SYSTEMD_COLORS
Dies muss ein logischer Wert sein. Steuert, ob
gefärbte Ausgabe erstellt werden soll. Dies kann festgelegt werden, um
die Entscheidung, die systemd basierend auf $TERM und mit
welcher Konsole es verbunden ist, trifft, außer Kraft zu setzen.
$SYSTEMD_URLIFY
Dies muss ein logischer Wert sein. Steuert, ob
anklickbare Links in der Ausgabe für Terminalemulatoren, die dies
unterstützen, erstellt werden sollen. Dies kann festgelegt werden, um
die Entscheidung, die systemd basierend auf $TERM und weiteren
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 Systemd für überwachte Prozesse
für Status- und Hcohfahrabschlussbenachrichtigungen gesetzt. Siehe
sd_notify(3) für weitere Informationen.
Für weitere Umgebungsvariablen, die von Systemd und seinen
verschiedenen Komponenten verstanden werden, siehe Bekannte
Umgebungsvariablen[7].
Beim Betrieb als Systeminstanz wertet Systemd eine Reihe von
Kernelbefehlszeilenargumenten aus[8]:
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
anfänglichen RAM-Platte (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 festgelegt. Falls aktiviert wird der
Systemverwalter (PID 1) einen Speicherauszug schreiben, wenn er
abstürzt. Andernfalls wird kein Speicherauszug erstellt.
Standardmäßig aktiviert.
systemd.crash_chvt
Akzeptiert eine positive Ganzzahl oder ein logisches
Argument. Kann auch ohne Argument festgelegt werden; dies hat den gleichen
Effekt wie ein positiver logischer Wert. Falls eine positive Ganzzahl (im
Bereich 1…63) festgelegt ist, wird der Systemverwalter (PID 1) die
festgelegte Anzahl an virtuellen Terminals (VTs) erstellen, wenn er
abstürzt. Standardmäßig deaktiviert, was bedeutet, dass
dies nicht versucht wird. Falls auf aktiviert gesetzt, wird der VT, auf den
die Kernelnachrichten geschrieben werden, ausgewählt.
systemd.crash_shell
Akzeptiert ein logisches Argument oder aktiviert die
Option, falls ohne Argument festgelegt. 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.
systemd.crash_reboot
Akzeptiert ein logisches Argument oder aktiviert die
Option, falls ohne Argument festgelegt. Falls aktiviert wird der
Systemverwalter (PID 1) nach einer Verzögerung von 10 Sekunden die
Maschine neustarten, wenn er abstürzt. Andernfalls wird das System
unbegrenzt hängen. Standardmäßig deaktiviert, um eine
Neustartschleife zu verhindern. Falls mit systemd.crash_shell
kombiniert, wird das System neu gestartet, nachdem die Shell sich
beendet.
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 festgelegt 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 Konsolenamen (wie
»ttyS0«) bereitgestellt wird, wird stattdessen die durch diesen
Pfad angezeigte virtuelle Konsole oder durch den übergebenen Namen
beschriebene stattdessen verwandt. Standardmäßig
deaktiviert.
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.
systemd.show_status
Akzeptiert ein logisches Argument oder die Konstante
auto. Kann auch ohne Argument festgelegt 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.
auto verhält sich wie
false, bis eine Unit fehlschlägt oder es beim Systemstart zu
signifikanten Verzögerungen kommt. Standardmäßig
aktiviert, außer
quiet wird als Kernelbefehlszeilenoption
angegeben. In letzterem Fall ist die Vorgabe
auto. Ist dies festgelegt,
setzt es die Konfigurationsdateioption
ShowStatus= des Systemverwalters
außer Kraft, siehe
systemd-system.conf(5). Allerdings hat die
Prozessbefehlszeilenoption
--show-status= Vorrang vor sowohl dieser
Kernelbefehlszeilenoption als auch der Konfigurationsdateioption.
systemd.log_target=, systemd.log_level=,
systemd.log_location=, systemd.log_color
Steuert die Protokollausgabe, mit dem gleichen Effekt wie
die oben beschriebenen Umgebungsvariablen $SYSTEMD_LOG_TARGET,
$SYSTEMD_LOG_LEVEL, $SYSTEMD_LOG_LOCATION,
$SYSTEMD_LOG_COLOR. systemd.log_color kann ohne Argumente
festgelegt werden; dies hat den gleichen Effekt wie ein positiver logischer
Wert.
systemd.default_standard_output=,
systemd.default_standard_error=
Steuert die Vorgabe-Standardausgabe und -Fehlerausgabe
für Dienste, mit dem gleichen Effekt wie die oben beschriebenen
Befehlszeilenargumente --default-standard-output= bzw.
--default-standard-error=.
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.
systemd.unified_cgroup_hierarchy
Wird das ohne Argument oder mit einem wahren Argument
festgelegt, aktiviert dies die Verwendung der
vereinigten
Cgroup-Hierarchie[9] (auch als cgroups-v2 bekannt). Wird es mit einem
falschen Argument festgelegt, wird es auf hybride oder die komplett alte
Cgroup-Hierarchie zurückfallen.
Falls diese Option nicht festgelegt ist, wird das
Standardverhalten während der Kompilierung (mit der Meson-Option
-Ddefault-hierarchy=) bestimmt. Falls der Kernel die vereinigte
Cgroup-Hierarchie nicht unterstützt, wird die alte Hierarchie
verwandt, selbst wenn diese Option festgelegt ist.
systemd.legacy_systemd_cgroup_controller
Wird wirksam, falls die komplette vereinigte
Cgroup-Hierarchie nicht verwandt wird (siehe vorherige Option). Deaktiviert
die »hybride« Cgroup-Hierarchie (d.h. eines von Systemd
verwandten cgroups-v2-Baumes und der
alten Cgroup-Hierarchie[10],
für andere Controller auch als cgroups-v1 bekannt), falls ohne oder mit
einem wahren Argument festgelegt und erzwingt den vollständigen
»alten« Modus. Aktiviert die Verwendung der
»hybriden« Hierarchie, falls mit einem falschen Argument
festgelegt.
Falls diese Option nicht festgelegt ist, wird das
Standardverhalten während der Kompilierung (mit der Meson-Option
-Ddefault-hierarchy=) bestimmt. Falls der Kernel die vereinigte
Cgroup-Hierarchie nicht unterstützt, wird die alte Hierarchie
verwandt, selbst wenn diese Option festgelegt ist.
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.
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.
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.
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.
2, 3, 4, 5
Systemstart in den festgelegten 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.
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).
Für weitere von Komponenten des Kernbetriebssystems
verstandene Kernelbefehlszeilenparameter siehe
kernel-command-line(7).
/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 verwawndt 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 solte in neuen Anwendungen nicht verwandt
werden.
Die Systemd-Homepage[11], systemd-system.conf(5),
locale.conf(5), systemctl(1), journalctl(1),
systemd-notify(1), daemon(7), sd-daemon(3),
systemd.unit(5), systemd.special(5), pkg-config(1),
kernel-command-line(7), bootup(7),
systemd.directives(7)
- 1.
- cgroups.txt
https://www.kernel.org/doc/Documentation/cgroup-v1/cgroups.txt
- 2.
- Ursprüngliches Designdokument
http://0pointer.de/blog/projects/systemd.html
- 3.
- Schnittstellenstabilitätszusage
https://www.freedesktop.org/wiki/Software/systemd/InterfaceStabilityPromise
- 4.
- Container-Schnittstelle
https://www.freedesktop.org/wiki/Software/systemd/ContainerInterface
- 5.
- Initrd-Schnittstelle
https://www.freedesktop.org/wiki/Software/systemd/InitrdInterface
- 6.
- XDG-Basisverzeichnisspezifikation
http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
- 7.
- Bekannte Umgebungsvariablen
https://systemd.io/ENVIRONMENT
- 8.
- Falls innerhalb eines Linux-Containers ausgeführt, können
diese Argumente als Befehlszeilenargumente an Systemd selbst
übergeben werden, neben allen anderen Befehlszeilenoptionen, die in
dem obigen Abschnitt »Optionen« aufgeführt sind.
Falls außerhalb von Linux-Containern ausgeführt, werden
diese Argumente stattdessen aus /proc/cmdline ausgewertet.
- 9.
- Vereinigte Cgroup-Hierarchie
https://www.kernel.org/doc/Documentation/cgroup-v2.txt
- 10.
- Alte Cgroup-Hierarchie
https://www.kernel.org/doc/Documentation/cgroup-v1/
- 11.
- Systemd-Homepage
https://www.freedesktop.org/wiki/Software/systemd/
Ü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
<debian-l10n-german@lists.debian.org>.