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 angemeldete Benutzer zum Starten ihrer Dienste werden separate Instanzen gestartet. systemd wird normalerweise nicht direkt durch den Benutzer aufgerufen, sondern wird als Symlink /sbin/init installiert und während der frühen Systemstartphase ausgeführt. Die Benutzerverwalterinstanzen werden automatisch durch den Dienst user@.service(5) gestartet. Für die Kompatibilität mit SysV wird das Programm, falls es init genannt und nicht der erste Prozess auf der Maschine ist (PID ist nicht 1), telinit ausführen und alle Befehlszeilenargumente unverändert weitergeben. Das bedeutet, dass init und telinit beim Aufruf von normalen Anmeldesitzungen größtenteils äquivalent sind. Siehe telinit(8) für weitere Informationen. Systemd interpretiert die Konfigurationsdatei system.conf und die Dateien in Verzeichnissen system.conf.d, wenn es als Systeminstanz läuft. Wenn es als Benutzerinstanz läuft, interpretiert Systemd die Konfigurationsdatei user.conf und die Dateien in Verzeichnissen user.conf.d. Siehe systemd-system.conf(5) für weitere Informationen.KONZEPTE
Systemd stellt ein Abhängigkeitssystem zwischen verschiedenen Einheiten namens »Units« in 11 verschiedenen Typen bereit. Units kapseln verschiedene Objekte, die für den Systemstart und -betrieb relevant sind. Der Großteil der Units wird in Unit-Konfigurationsdateien, deren Syntax und grundlegenden Menge an Optionen in systemd.unit(5) beschrieben ist, konfiguriert. Einige Units werden allerdings automatisch aus anderen Konfigurationsdateien, dynamisch aus Systemzuständen oder programmatisch zur Laufzeit erstellt. Units können »aktiv« (dies bedeutet gestartet, gebunden, eingesteckt, …, abhängig vom Unit-Typ, siehe unten) oder »inaktiv« (dies bedeutet gestoppt, nicht gebunden, ausgesteckt, … ) sowie im Prozess der Aktivierung oder Deaktivierung, d.h. zwischen den zwei Zuständen (diese Zustände werden »Aktivierung« und »Deaktivierung« genannt) sein. Ein besonderer Zustand »fehlgeschlagen« ist auch verfügbar, der sehr ähnlich zu »inaktiv« ist und der erreicht wird, wenn der Dienst auf irgendeine Art fehlgeschlagen ist (Prozess lieferte beim Beenden einen Fehlercode, ist abgestürzt, eine Aktion erlebte eine Zeitüberschreitung oder nach zu vielen Neustarts). Falls dieser Zustand erreicht wird, wird die Ursache für spätere Einsichtnahme protokolliert. Beachten Sie, dass die verschiedenen Unit-Typen eine Reihe von zusätzlichen Unterzuständen haben können, die auf die fünf hier beschriebenen generalisierten Unit-Zustände abgebildet werden. Die folgenden Unit-Typen sind verfügbar: 1.Dienste-Units, die Daemons und die
Prozesse, aus denen sie bestehen, starten und steuern. Für Details
siehe systemd.service(5).
2.Socket-Units, die lokale IPC- oder
Netzwerk-Sockets in dem System kapseln, nützlich für
Socket-basierte Aktivierung. Für Details über Socket-Units siehe
systemd.socket(5), für Details über Socket-basierte
Aktivierung und andere Formen der Aktivierung siehe daemon(7).
3.Ziel-Units sind für die Gruppierung
von Units nützlich. Sie stellen während des Systemstarts auch
gut bekannte Synchronisationspunkte zur Verfügung, siehe
systemd.target(5).
4.Geräte-Units legen
Kernel-Geräte in Systemd offen und können zur Implementierung
Geräte-basierter Aktivierung verwandt werden. Für Details siehe
systemd.device(5).
5.Einhänge-Units steuern
Einhängepunkte in dem Dateisystem, für Details siehe
systemd.mount(5).
6.Automount-Units stellen
Selbsteinhänge-Fähigkeiten bereit, für bedarfsgesteuertes
Einhängen von Dateisystemen sowie parallelisiertem Systemstart. Siehe
systemd.automount(5).
7.Timer-Units sind für das
Auslösen der Aktivierung von anderen Units basierend auf Timern
nützlich. Sie können Details in systemd.timer(5)
finden.
8.Auslagerungs-Units sind ähnlich zu
Einhänge-Units und kapseln Speicherauslagerungspartitionen oder
-dateien des Betriebssystems. Sie werden in systemd.swap(5)
beschrieben.
9.Pfad-Units können zur Aktivierung
andere Dienste, wenn sich Dateisystemobjekte ändern oder
verändert werden, verwandt werden. Siehe systemd.path(5).
10.Scheiben-Units können zur
Gruppierung von Units, die Systemprozesse (wie Dienste- und Bereichs-Units) in
einem hierarchischen Baum aus Ressourcenverwaltungsgründen verwalten,
verwandt werden. Siehe systemd.slice(5).
11.Bereichs-Units sind ähnlich zu
Dienste-Units, verwalten aber fremde Prozesse, statt sie auch zu starten.
Siehe systemd.scope(5).
Units werden wie ihre Konfigurationsdateien benannt. Einige Units habe besondere
Semantiken. Eine detaillierte Liste ist in systemd.special(7)
verfügbar.
Systemd kennt verschiedene Arten von Abhängigkeiten,
einschließlich positiven und negativen Bedingungsabhängigkeiten
(d.h. Requires= und Conflicts=) sowie
Ordnungsabhängigkeiten ( After= und Before=).
Wohlgemerkt: Ordnungs- und Bedingungsabhängigkeiten sind orthogonal.
Falls zwischen zwei Units nur eine Bedingungsabhängigkeit (z.B.
foo.service bedingt bar.service) aber keine Ordnungsabhängigkeit (z.B.
foo.service nach bar.service) existiert und beide zum Start angefragt werden,
werden sie parallel gestartet. Es ist ein häufiges Muster, dass sowohl
Bedingungs- als auch Ordnungsabhängigkeiten zwischen zwei Units
angelegt werden. Beachten Sie auch, dass die Mehrzahl der
Abhängigkeiten von Systemd implizit erstellt und verwaltet werden. In
den meisten Fällen sollte es unnötig sein, zusätzliche
Abhängigkeiten manuell zu deklarieren, allerdings ist dies
möglich.
Anwendungsprogramme und Units (über Abhängigkeiten) können
Statusänderungen von Units erbitten. In Systemd werden diese Anfragen
als »Aufträge« gekapselt und in einer
Aufträgewarteschlange verwaltet. Aufträge können
erfolgreich sein und fehlschlagen, ihre Ausführungsreihenfolge basiert
auf den Ordnungsabhängigkeiten der Units, für die sie eingeplant
wurden.
Beim Systemstart aktiviert Systemd die Ziel-Unit default.target, deren Aufgabe
es ist, die bei-Systemstart-Dienste und andere bei-Systemstart-Units zu
aktivieren, indem sie sie mittels Abhängigkeiten hereinzieht.
Normalerweise ist der Unit-Name nur ein Alias (Symlink) für entweder
graphical.target (für vollfunktionale Systemstarts in die UI) oder
multi-user.target (für begrenzte, rein konsolenbasierte Systemstarts
zur Verwendung in eingebetteten oder Server-Umgebungen oder ähnlichen,
eine Untermenge von graphical.target). Es obliegt aber dem Administrator, sie
als Alias zu jeder anderen Ziel-Unit zu konfigurieren. Siehe
systemd.special(7) für Details über diese Ziel-Units.
Beim ersten Systemstart wird systemd Units gemäß der
Voreinstellungs-Richtlinie aktivieren oder deaktivieren. Siehe
systemd.preset(5) und »Semantik beim ersten Systemstart«
in machine-id(5).
Systemd behält nur eine minimale Gruppe an Units im Speicher geladen.
Konkret werden nur die Units im Speicher geladen gehalten, für die
mindestens eine der nachfolgenden Bedingungen zutrifft:
1.Sie ist in einem aktiven, aktivierenden,
deaktivierenden oder fehlgeschlagenen Zustand (d.h. in jedem Zustand
außer »inactive«)
2.Für sie ist ein Auftrag in der
Warteschlange
3.Sie ist eine Abhängigkeit von
mindestens einer anderen im Speicher geladenen Unit
4.Ihr ist noch irgendeine Form von Ressourcen
zugewiesen (z.B. eine inaktive Dienste-Unit, für die aber ein Prozess
noch herumlungert, der die Aufforderung zum Beenden ignorierte)
5.Sie wurde durch einen D-Bus-Aufruf
programmatisch im Speicher festgepinnt
Systemd wird automatisch und implizit Units von der Platte laden — falls
sie noch nicht geladen sind — sobald eine Aktion für sie
angefordert wird. Daher ist in vielerlei Hinsicht die Tatsache, ob eine Unit
geladen ist oder nicht, für Clients unsichtbar. Verwenden Sie
systemctl list-units --all, um eine vollumfängliche Liste aller
derzeit geladenen Units zu erhalten. Jede Unit, für die eine der oben
aufgeführten Bedingungen zutrifft, wird sofort entladen. Beachten Sie,
dass beim Entladen einer Unit aus dem Speicher die Buchführungsdaten
auch entfernt werden. Allerdings sind diese Daten im Allgemeinen nicht
verloren, da ein Journal-Protokolleintrag erstellt wird, der die verbrauchten
Ressourcen deklariert, wann immer eine Unit herunterfährt.
Prozesse, die Systemd startet, werden in einer privaten Systemd-Hierarchie in
individuellen Control-Gruppen von Linux, die nach der Unit, zu der sie
gehören, benannt sind, gelegt (siehe Control Groups v2[1]
für weitere Informationen über Control-Gruppen oder kurz
»cgroups«). Systemd verwendend dies, um Prozesse effektiv
nachzuverfolgen. Control-Gruppen-Informationen werden im Kernel verwaltet und
sind über die Dateisystemhierarchie (unterhalb von /sys/fs/cgroup/)
oder über Werkzeuge wie systemd-cgls(1) oder ps(1)
verfügbar. ( ps xawf -eo pid,user,cgroup,args ist besonders
nützlich, um alle Prozesse und die Systemd-Units, zu denen sie
gehören, aufzulisten.)
Systemd ist zu einem großen Teil zu SysV kompatibel: SysV-Init-Skripte
werden unterstützt und werden einfach als ein alternatives (wenn auch
begrenztes) Konfigurationsdateiformat verstanden. Die SysV-Schnittstelle
/dev/initctl wird bereitgestellt und Kompatibilitätsimplementierungen
der verschiedenen SysV-Client-Werkzeuge sind verfügbar.
Zusätzlich werden verschiedene etablierte Unix-Funktionalitäten
wie /etc/fstab oder die Utmp-Datenbank unterstützt.
Systemd hat ein minimales Transaktionssystem: Falls eine Unit zum Start oder
Herunterfahren aufgefordert wird, wird sie sich und alle Abhängigkeiten
zu einer temporären Transaktion hinzufügen. Es wird dann
nachweisen, dass die Transaktion konsistent ist (d.h. ob die Ordnung aller
Units frei von Zyklen ist). Sollte dies nicht der Fall sein, wird Systemd
versuchen, sie zu korrigieren und entfernt alle unwesentlichen Aufträge
aus der Transaktion, die die Schleife entfernen könnten. Auch versucht
Systemd, nicht wesentliche Aufträge in der Transaktion zu
unterdrücken, die einen laufenden Dienst stoppen würden.
Schließlich wird überprüft, ob die Aufträge der
Transaktion Aufträgen widersprechen, die bereits in die Warteschlange
eingereiht wurden, optional wird dann die Transaktion abgebrochen. Falls alles
passt und die Transaktion konsistent in ihren Auswirkungen minimiert ist, wird
sie mit bereits wartenden Aufträgen zusammengeführt und zu der
Ausführungswarteschlange hinzugefügt. Effektiv bedeutet dies,
dass Systemd vor der Ausführung einer angefragten Aktion
überprüft, dass sie Sinn ergibt, sie falls möglich
korrigiert und nur fehlschlägt, falls es wirklich nicht funktionieren
kann.
Beachten Sie, dass Transaktionen unabhängig vom Zustand einer Unit zur
Laufzeit erstellt werden. Wird daher beispielsweise ein Startauftrag
für eine bereits gestartete Unit angefordert, wird er dennoch eine
Transaktion erstellen und alle inaktiven Abhängigkeiten aufwecken (und
gemäß der definierten Abhängigkeiten eine Weiterleitung
zu anderen Aufträgen verursachen). Dies erfolgt, da der in die
Warteschlange eingereihte Auftrag zum Zeitpunkt der Ausführung mit dem
Zustand der Ziel-Unit verglichen und als erfolgreich und abgeschlossen
markiert wird, wenn beide zutreffen. Allerdings zieht dieser Auftrag auch
andere Abhängigkeiten aufgrund der definierten Beziehungen herein und
führt daher in unserem Beispiel dazu, dass Start-Aufträge
für jede dieser inaktiven Units auch in die Warteschlange eingereiht
werden.
Systemd enthält native Implementierungen verschiedener Programme, die als
Teil des Systemstartprozesses ausgeführt werden müssen.
Beispielsweise setzt es den Rechnernamen und konfiguriert das
Loopback-Netzwerkgerät. Es richtet auch die verschiedenen
API-Dateisysteme, wie /sys/ oder /proc/, ein und hängt sie ein.
Für weitere Informationen über die Konzepte und Ideen hinter
Systemd wird auf das Ursprüngliches Designdokument[2] verwiesen.
Beachten Sie, dass einige, aber nicht alle, durch Systemd bereitgestellte
Schnittstellen von der Schnittstellenportierungs und
-stabilitätszusage[3] abgedeckt sind.
Units können dynamisch zum Systemstartzeitpunkt und zum
Systemverwalter-Neuladezeitpunkt erstellt werden, beispielsweise basierend auf
anderen Konfigurationsdateien oder auf von der Kernelbefehlszeile
übergebenen Parametern. Für Details siehe
systemd.generator(7).
Das D-Bus-API von systemd wird in org.freedesktop.systemd1(5) und
org.freedesktop.LogControl1(5) beschrieben.
Systeme, die Systemd in einem Container oder in einer Initrd-Umgebung aufrufen,
sollten die Spezifikation Container-Schnittstelle[4] bzw.
initrd-Schnittstelle[5] implementieren.
VERZEICHNISSE
System-Unit-VerzeichnisseDer 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
SIGTERMNach 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 angegebenen Wert oder dem mit LogLevel= in der
Konfigurationsdatei angegebenen Wert oder dem eingebauten Wert
»info« abgeleitet.
SIGRTMIN+24
Verlässt den Verwalter sofort (nur
für --user-Instanzen verfügbar).
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.
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.
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
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 [email protected]. Mittels der Einstellungen Environment= und EnvironmentFile= für [email protected] 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_LEVELDie maximale Protokollierstufe ausgesandter
Nachrichten (Nachrichten mit einer höheren Protokollierstufe, d.h.
weniger wichtige, werden unterdrückt). Sie muss (in absteigender
Reihenfolge) entweder alert, crit, err, warning,
notice, info, debug oder eine Ganzzahl im Bereich
0…7 sein. Siehe syslog(3) für weitere Informationen.
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.
$SYSTEMD_LOG_LOCATION
Ein logischer Wert. Falls wahr, wird den
Protokollnachrichten ein Dateinamen und eine Zeilenummer in dem Quellcode, aus
dem die Nachrichten stammen, vorangestellt.
Dies kann mit --log-location= außer Kraft gesetzt werden.
$SYSTEMD_LOG_TID
Ein logischer Wert. Falls wahr, wird den
Nachrichten die aktuelle numerische Thread-Kennung (TID) vorangestellt.
$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.
$XDG_CONFIG_HOME, $XDG_CONFIG_DIRS, $XDG_DATA_HOME,
$XDG_DATA_DIRS
Der Systemd-Benutzerverwalter verwendet diese
Variablen in Übereinstimmung mit der
XDG-Basisverzeichnisspezifikation[6], um seine Konfiguration zu
finden.
$SYSTEMD_UNIT_PATH, $SYSTEMD_GENERATOR_PATH,
$SYSTEMD_ENVIRONMENT_GENERATOR_PATH
Steuert, wo Systemd nach Unit-Dateien und
Generatoren schaut.
Diese Variablen können eine Liste von Pfaden, getrennt durch Doppelpunkte
(»:«), enthalten. Ist dies gesetzt und endet mit der leeren
Komponente (»…:«), wird diese Liste der normalen Gruppe
an Pfaden vorangestellt. Andernfalls ersetzt die angegebene Liste die normale
Gruppe an Pfaden.
$SYSTEMD_PAGER
Zu verwendendes Textanzeigeprogramm, wenn
--no-pager nicht angegeben ist; setzt $PAGER außer Kraft.
Falls weder $SYSTEMD_PAGER noch $PAGER gesetzt sind, wird eine
Reihe wohlbekannter Textanzeigeprogrammimplementierungen der Reihe nach
ausprobiert, einschließlich less(1) und more(1), bis
eines gefunden wird. Falls keine Textanzeigeprogrammimplementierung 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
Siehe less(1) für weitere Ausführungen.
$SYSTEMD_LESSCHARSET
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.
Setzt den an less zu
übergebenden Zeichensatz (standardmäßig
»utf-8«, falls das aufrufende Terminal als UTF-8-kompatibel
erkannt wurde) außer Kraft.
$SYSTEMD_PAGERSECURE
Akzeptiert einen logischen Wert. Wenn wahr,
wird der »sichere« Modus des Seitenanzeigeprogramms 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 Seitenanzeigeprogramms gesetzt und das Seitenanzeigeprogramm
muss Befehle deaktivieren, die neue Dateien öffnen oder erstellen oder
die einen neuen Unterprozess starten. Falls $SYSTEMD_PAGERSECURE
überhaupt nicht gesetzt ist, werden Seitenanzeigeprogramme, 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 Seitenanzeigeprogramm 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 den Seitenanzeiger 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 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
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. Die folgenden Variablen werden unterstützt: 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.
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.
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.
systemd.crash_reboot
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 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 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.
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
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).
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).
systemd.log_color, systemd.log_level=,
systemd.log_location, systemd.log_target=,
systemd.log_time, systemd.log_tid
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 und $SYSTEMD_LOG_TID.
systemd.log_color, systemd.log_location, systemd.log_time
und systemd.log_tid= 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.
systemd.set_credential=
Setzt eine Systemzugangsberechtigung, die
mittels der Einstellung LoadCredential= an Systemdienste weitergeleitet
werden kann, siehe systemd.exec(5) für Details. Akzeptiert ein
Paar bestehend aus Zugangsberechtigung und -namen, getrennt durch Doppelpunkt.
Beachten Sie, dass von nicht privilegierten Programmen in /proc/cmdline
typischerweise auf die Kernel-Befehlszeile zugegriffen werden kann. Daher ist
dieser Mechanismus nicht für die Übertragung vertraulicher Daten
geeignet. Verwenden Sie ihn nur für Daten, die nicht vertraulich sind
(z.B. öffentliche Schlüssel/Zertifikate statt privater
Schlüssel) oder in Test-/Fehlersuchumgebungen.
Siehe die Dokumentation der System- und Dienste-Zugangsberechtigungen[8]
für weitere Details.
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.
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 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.
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).
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-itemsGibt 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.
--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).
--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-reboot
Beim Systemabsturz automatisch das System
neustarten. Dieser Schalter hat beim Betrieb als Benutzerinstanz keinen
Effekt. Siehe systemd.crash_reboot weiter oben.
--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.
--log-color
Hebt wichtige Protokollmeldungen hervor. Siehe
systemd.log_color oben.
--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.
--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.
--machine-id=
Setzt die auf der Festplatte gesetzte
Maschinenkennung außer Kraft. Siehe systemd.machine_id=
oben.
--service-watchdogs
Global alle
Dienste-Watchdog-Zeitüberschreitungen und Notfallaktionen
aktivieren/deaktivieren. Siehe systemd.service_watchdogs weiter
oben.
--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/notifyDaemon-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 252Die 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.
SIEHE AUCH
Die Systemd-Homepage[9], systemd-system.conf(5), locale.conf(5), systemctl(1), journalctl(1), systemd-notify(1), daemon(7), sd-daemon(3), org.freedesktop.systemd1(5), systemd.unit(5), systemd.special(7), pkg-config(1), kernel-command-line(7), bootup(7), systemd.directives(7)ANMERKUNGEN
- 1.
- Control-Gruppen v2
- 2.
- Ursprüngliches Designdokument
- 3.
- Schnittstellenportabilitäts- und -stabilitätszusage
- 4.
- Container-Schnittstelle
- 5.
- Initrd-Schnittstelle
- 6.
- XDG-Basisverzeichnisspezifikation
- 7.
- Bekannte Umgebungsvariablen
- 8.
- System- und Dienste-Zugangsberechtigungen
- 9.
- Systemd-Homepage
ÜBERSETZUNG
Die deutsche Übersetzung dieser Handbuchseite wurde von Helge Kreutzmann <[email protected]> erstellt. Diese Übersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 3 oder neuer bezüglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG übernommen. Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an die Mailingliste der Übersetzer| systemd 252 |