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

BEZEICHNUNG

       systemd, init - Systemd-System und Diensteverwalter

ÜBERSICHT


       /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 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.

OPTIONEN

Die folgenden Optionen werden verstanden:

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

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

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

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

--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, 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.

KONZEPTE

Systemd stellt ein Abhängigkeitssystem zwischen verschiedenen Einheiten namens »Units« in 11
verschiedenen Typen bereit. Units kapseln verschiedene Objekte, die für den Systemstart und -betrieb
relevant sind. Der Großteil der Units wird in Unit-Konfigurationsdateien, deren Syntax und grundlegenden
Menge an Optionen in systemd.unit(5) beschrieben ist, konfiguriert. Einige Units werden allerdings
automatisch aus 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 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. 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 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.

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. 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
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-Skripte werden unterstützt und werden
einfach als ein alternatives (wenn auch begrenztes) Konfigurationsdateiformat verstanden. Die
SysV-Schnittstelle /dev/initctl wird bereitgestellt und Kompatibilitätsimplementierungen der
verschiedenen SysV-Client-Werkzeuge sind verfügbar. Zusätzlich werden verschiedene etablierte
Unix-Funktionalitäten wie /etc/fstab oder die Utmp-Datenbank unterstützt.

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

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

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

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

Beachten Sie, dass einige, aber nicht alle, durch Systemd bereitgestellte Schnittstellen von der
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.

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 /lib/systemd/system. Benutzerkonfiguration hat immer Vorrang.
pkg-config systemd --variable=systemdsystemconfdir liefert den Pfad zu dem
Systemkonfigurationsverzeichnis. Pakete sollten den Inhalt dieser Verzeichnisse mit den Befehlen
enable und disable des Werkzeugs systemctl(1) verändern. Eine vollständige Auflistung von
Verzeichnissen wird in systemd.unit(5) bereitgestellt.

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

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

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

SIGNALE

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+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.

UMGEBUNGSVARIABLEN

$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 Hochfahrabschlussbenachrichtigungen
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].

KERNEL-BEFEHLSZEILE

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

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.status_unit_format=
Akzeptiert entweder name oder description als Wert. Falls name, wird der Diensteverwalter Unit-Namen
in Statusmeldungen verwenden. Falls festgelegt, setzt dies die Konfigurationsoption StatusUnitFormat=
des Systemverwalters außer Kraft, siehe systemd-system.conf(5).

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 komplette veraltete 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.

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).

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.

SIEHE AUCH

       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)

ANMERKUNGEN

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

systemd 243                                                                                           SYSTEMD(1)