systemd – Online in der Cloud

PROGRAMM:

NAME/FUNKTION

systemd, init – systemd-System- und Service-Manager

ZUSAMMENFASSUNG

systemd [OPTIONEN...]

init [OPTIONEN...] {BEFEHL}

BESCHREIBUNG

systemd ist ein System- und Dienstmanager für Linux-Betriebssysteme. Wenn als erstes ausgeführt
Prozess beim Booten (als PID 1), fungiert es als Init-System, das den Benutzerbereich aufbaut und verwaltet
Dienstleistungen.

Aus Kompatibilitätsgründen mit SysV, wenn systemd als aufgerufen wird init und eine PID, die nicht 1 ist, wird es tun
ausführen telini und übergeben Sie alle Befehlszeilenargumente unverändert. Das bedeutet init und
telini sind größtenteils gleichwertig, wenn sie aus normalen Anmeldesitzungen aufgerufen werden. Sehen telini(8) für
mehr Informationen.

Bei der Ausführung als Systeminstanz interpretiert systemd die Konfigurationsdatei system.conf und
die Dateien in system.conf.d-Verzeichnissen; Bei Ausführung als Benutzerinstanz interpretiert systemd
die Konfigurationsdatei user.conf und die Dateien in den Verzeichnissen user.conf.d. Sehen systemd-
system.conf(5) für weitere Informationen.

OPTIONAL

Folgende Optionen werden verstanden:

--Prüfung
Bestimmen Sie die Startreihenfolge, sichern Sie sie und beenden Sie den Vorgang. Dies ist eine nützliche Option zum Debuggen
nur.

--dump-configuration-items
Verstehen Sie die Konfigurationselemente der Einheit. Dies gibt eine knappe, aber vollständige Liste von aus
Konfigurationselemente, die in Einheitendefinitionsdateien verstanden werden.

--einheit=
Legen Sie die Standardeinheit so fest, dass sie beim Start aktiviert wird. Wenn nicht angegeben, wird standardmäßig default.target verwendet.

--System, --Benutzer
Für --System, weisen Sie systemd an, eine Systeminstanz auszuführen, auch wenn die Prozess-ID nicht 1 ist,
dh systemd wird nicht als Init-Prozess ausgeführt. --Benutzer macht das Gegenteil und führt einen Benutzer aus
Instanz, auch wenn die Prozess-ID 1 ist. Normalerweise sollte eine Übergabe nicht erforderlich sein
Diese Optionen, da systemd automatisch den Modus erkennt, in dem es gestartet wird. Diese
Optionen sind daher außer zum Debuggen von geringem Nutzen. Beachten Sie, dass dies nicht unterstützt wird
Booten und Warten eines vollständigen Systems mit laufendem systemd --System Modus, aber PID
nicht 1. In der Praxis bestanden --System ist explizit nur in Verbindung mit sinnvoll
--Prüfung.

--dump-core
Aktivieren Sie das Core-Dumping bei einem Absturz. Dieser Schalter hat keine Auswirkung, wenn er als Benutzerinstanz ausgeführt wird.
Diese Einstellung kann auch während des Bootens in der Kernel-Befehlszeile über aktiviert werden
systemd.dump_core= Option, siehe unten.

--crash-vt=VT
Wechseln Sie bei einem Absturz zu einer bestimmten virtuellen Konsole (VT). Akzeptiert eine positive ganze Zahl im
Bereich 1–63 oder ein boolesches Argument. Wenn eine Ganzzahl übergeben wird, wird ausgewählt, welches VT umgeschaltet werden soll
Zu. Wenn ja, die VT-Kernel-Nachrichten, in die geschrieben werden, ist ausgewählt. Wenn nicht, kein VT-Schalter ist
versucht. Dieser Schalter hat keine Auswirkung, wenn er als Benutzerinstanz ausgeführt wird. Diese Einstellung kann
kann auch während des Bootens in der Kernel-Befehlszeile über aktiviert werden systemd.crash_vt=
Option, siehe unten.

--crash-shell
Führen Sie bei einem Absturz eine Shell aus. Dieser Schalter hat keine Auswirkung, wenn er als Benutzerinstanz ausgeführt wird. Das
Die Einstellung kann auch während des Bootens in der Kernel-Befehlszeile über aktiviert werden
systemd.crash_shell= Option, siehe unten.

--crash-reboot
Starten Sie das System bei einem Absturz automatisch neu. Dieser Schalter hat keine Auswirkung, wenn er als ausgeführt wird
Benutzerinstanz. Diese Einstellung kann auch während des Bootens über den Kernel-Befehl aktiviert werden
Linie über die systemd.crash_reboot= Option, siehe unten.

--confirm-spawn
Bitten Sie beim Spawnen um eine Bestätigung. Dieser Schalter hat keine Auswirkung, wenn er ausgeführt wird als
Benutzerinstanz.

--show-status=
Zeigen Sie beim Booten knappe Informationen zum Dienststatus an. Dieser Schalter hat keine Wirkung, wenn
Als Benutzerinstanz ausführen. Akzeptiert ein boolesches Argument, das weggelassen werden kann
Interpretiert als was immer dies auch sein sollte..

--log-target=
Protokollziel festlegen. Das Argument muss eines von sein trösten, Zeitschrift, kmsg, Journal-oder-kmsg, null.

--log-level=
Protokollebene festlegen. Als Argument akzeptiert dies einen numerischen Log-Level oder das bekannte
syslog(3) symbolische Namen (Kleinbuchstaben): emerg, alarmieren, krit, sich irren, Warnung, beachten, Info,
debuggen.

--log-color=
Heben Sie wichtige Protokollmeldungen hervor. Argument ist ein boolescher Wert. Wenn das Argument ist
weggelassen, wird standardmäßig verwendet was immer dies auch sein sollte..

--log-location=
Geben Sie den Codespeicherort in Protokollnachrichten ein. Dies ist vor allem für Debugging-Zwecke relevant.
Argument ist ein boolescher Wert. Wenn das Argument weggelassen wird, wird es standardmäßig verwendet was immer dies auch sein sollte..

--default-standard-output=, --default-standard-error=
Legt die Standardausgabe oder Fehlerausgabe für alle Dienste bzw. Sockets fest.
Das heißt, steuert die Standardeinstellung für StandardOutput= und StandardError= (sehen
systemd.exe(5) für Einzelheiten). Nimmt einen davon erben, null, tty, Zeitschrift,
Journal+Konsole, syslog, Syslog+Konsole, kmsg, kmsg+Konsole. Wenn das Argument ist
ausgelassen --default-standard-output= Standardmäßig ist Zeitschrift und --default-standard-error=
zu erben.

--machine-id=
Überschreiben Sie die auf der Festplatte festgelegte Maschinen-ID, nützlich beim Netzwerkstart oder für
Behälter. Darf nicht ausschließlich auf Nullen gesetzt werden.

-h, --help
Drucken Sie einen kurzen Hilfetext und beenden Sie.

--Version
Drucken Sie eine kurze Versionsstring und beenden Sie.

KONZEPTE

systemd stellt ein Abhängigkeitssystem zwischen verschiedenen Entitäten bereit, die als „Einheiten“ von 12 bezeichnet werden
verschiedene Typen. Einheiten kapseln verschiedene Objekte, die für den Systemstart relevant sind
und Wartung. Die meisten Einheiten werden in Einheitenkonfigurationsdateien konfiguriert, deren
Die Syntax und der grundlegende Satz an Optionen werden in beschrieben systemd.einheit(5), jedoch werden einige erstellt
automatisch aus anderen Konfigurationen, dynamisch aus dem Systemstatus oder programmgesteuert
zur Laufzeit. Je nachdem können Einheiten „aktiv“ (also gestartet, gebunden, angeschlossen usw.) sein
der Einheitentyp, siehe unten) oder „inaktiv“ (bedeutet gestoppt, ungebunden, unplugged, ...), als
sowie im Prozess der Aktivierung bzw. Deaktivierung, also zwischen den beiden Zuständen
(Diese Zustände werden „Aktivieren“, „Deaktivieren“ genannt). Ein besonderer „fehlgeschlagener“ Zustand ist
verfügbar, was sehr ähnlich zu „inaktiv“ ist und beim Beenden des Dienstes eingetragen wird
ist auf irgendeine Weise fehlgeschlagen (der Prozess hat beim Beenden einen Fehlercode zurückgegeben, ist abgestürzt oder ein Vorgang ist zeitlich begrenzt).
aus). Wenn dieser Zustand erreicht wird, wird die Ursache zur späteren Bezugnahme protokolliert. Beachten Sie, dass
Die verschiedenen Einheitentypen können über eine Reihe zusätzlicher Unterzustände verfügen, die dem zugeordnet sind
fünf hier beschriebene verallgemeinerte Einheitszustände.

Folgende Gerätetypen stehen zur Verfügung:

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

2. Socket-Einheiten, die lokale IPC- oder Netzwerk-Sockets im System kapseln, nützlich für
Socket-basierte Aktivierung. Einzelheiten zu Sockeleinheiten finden Sie unter systemd.socket(5), z
Einzelheiten zur Socket-basierten Aktivierung und anderen Formen der Aktivierung finden Sie unter Daemon(7).

3. Zieleinheiten sind nützlich, um Einheiten zu gruppieren oder bekannte Synchronisationspunkte bereitzustellen
beim Hochfahren, siehe systemd.target(5).

4. Geräteeinheiten stellen Kernelgeräte in systemd bereit und können zur Implementierung verwendet werden
gerätebasierte Aktivierung. Einzelheiten finden Sie unter systemd.device(5).

5. Mount-Einheiten steuern Mount-Punkte im Dateisystem, Einzelheiten finden Sie unter systemd.mount(5).

6. Automount-Einheiten bieten Automount-Funktionen für das bedarfsgesteuerte Mounten von Dateisystemen
sowie parallelisiertes Booten. Sehen systemd.automount(5).

7. Timer-Einheiten sind nützlich, um die Aktivierung anderer Einheiten basierend auf Timern auszulösen. Du
Einzelheiten finden Sie möglicherweise in systemd.timer(5).

8. Swap-Einheiten sind Mount-Einheiten sehr ähnlich und kapseln Speicher-Swap-Partitionen oder
Dateien des Betriebssystems. Sie sind beschrieben in systemd.swap(5).

9. Pfadeinheiten können verwendet werden, um andere Dienste zu aktivieren, wenn sich Dateisystemobjekte ändern oder
werden geändert. Sehen systemd.pfad(5).

10. Slice-Einheiten können zum Gruppieren von Einheiten verwendet werden, die Systemprozesse (z. B. Dienste) verwalten
und Bereichseinheiten) in einem hierarchischen Baum für Ressourcenverwaltungszwecke. Sehen
systemd.slice(5).

11. Scope-Einheiten ähneln Service-Einheiten, verwalten jedoch stattdessen fremde Prozesse
starte sie auch. Sehen systemd.scope(5).

Einheiten werden nach ihren Konfigurationsdateien benannt. Einige Einheiten haben eine spezielle Semantik. A
Eine detaillierte Liste finden Sie in systemd.special(7).

systemd kennt verschiedene Arten von Abhängigkeiten, einschließlich positiver und negativer Anforderungen
Abhängigkeiten (z Erfordert= und Konflikte=) sowie Ordnungsabhängigkeiten (Nachher= und
Vorher=). Hinweis: Reihenfolge und Anforderungsabhängigkeiten sind orthogonal. Wenn nur eine Anforderung
Es besteht eine Abhängigkeit zwischen zwei Einheiten (z. B. erfordert foo.service bar.service), aber keine
Bestellabhängigkeit (z. B. foo.service nach bar.service) und beide werden zum Starten aufgefordert,
sie werden parallel gestartet. Es handelt sich um ein allgemeines Muster, das sowohl Anforderungen als auch Anforderungen erfüllt
Ordnungsabhängigkeiten werden zwischen zwei Einheiten platziert. Beachten Sie auch, dass die meisten
Abhängigkeiten werden implizit von systemd erstellt und verwaltet. In den meisten Fällen sollte es so sein
Es ist nicht notwendig, zusätzliche Abhängigkeiten manuell zu deklarieren, es ist jedoch möglich
Dies.

Anwendungsprogramme und Einheiten (über Abhängigkeiten) können Zustandsänderungen von Einheiten anfordern. In
systemd werden diese Anforderungen als „Jobs“ gekapselt und in einer Jobwarteschlange verwaltet. Jobs können
erfolgreich sind oder fehlschlagen können, wird ihre Ausführung basierend auf den Reihenfolgeabhängigkeiten der geordnet
Einheiten, für die sie eingeplant sind.

Beim Booten aktiviert systemd die Zieleinheit default.target, deren Aufgabe es ist, beim Booten zu aktivieren
Dienste und andere On-Boot-Einheiten, indem sie über Abhängigkeiten eingebunden werden. Normalerweise die Einheit
Name ist nur ein Alias ​​(symlink) für Graphical.target (für voll funktionsfähige Boot-Ins).
der Benutzeroberfläche) oder multi-user.target (für begrenzte Nur-Konsolen-Boots zur Verwendung in Embedded oder Server).
Umgebungen oder ähnliches; eine Teilmenge vongraphical.target). Es liegt jedoch im Ermessen
des Administrators, es als Alias ​​für eine beliebige andere Zieleinheit zu konfigurieren. Sehen
systemd.special(7) für Einzelheiten zu diesen Zieleinheiten.

Prozesse, die systemd erzeugen, werden in einzelnen Linux-Kontrollgruppen platziert, die nach dem benannt sind
Einheit, zu der sie in der privaten Systemd-Hierarchie gehören. (sehen cgroups.txt[1] für mehr
Informationen zu Kontrollgruppen, kurz „cgroups“). systemd nutzt dies effektiv
Behalten Sie den Überblick über Prozesse. Kontrollgruppeninformationen werden im Kernel verwaltet und sind es auch
über die Dateisystemhierarchie zugänglich (unten). /sys/fs/cgroup/systemd/) oder in Werkzeugen
wie systemd-cgls(1) oder ps(1) (ps xawf -eo pid,user,cgroup,args ist besonders nützlich
um alle Prozesse und die Systemd-Einheiten, zu denen sie gehören, aufzulisten.

systemd ist weitgehend mit dem SysV-Init-System kompatibel: SysV-Init-Skripte sind es
unterstützt und einfach als alternatives (wenn auch eingeschränktes) Konfigurationsdateiformat gelesen.
Die SysV /dev/initctl-Schnittstelle wird bereitgestellt und Kompatibilitätsimplementierungen davon
Es stehen verschiedene SysV-Client-Tools zur Verfügung. Darüber hinaus haben sich verschiedene Unix etabliert
Funktionalität wie z.B / etc / fstab oder die utmp-Datenbank werden unterstützt.

systemd verfügt über ein minimales Transaktionssystem: wenn eine Einheit zum Starten oder Herunterfahren aufgefordert wird
Es wird es und alle seine Abhängigkeiten zu einer temporären Transaktion hinzufügen. Dann wird es überprüft
ob die Transaktion konsistent ist (d. h. ob die Bestellung aller Einheiten zyklusfrei ist).
Ist dies nicht der Fall, versucht systemd, das Problem zu beheben, und entfernt nicht unbedingt erforderliche Jobs aus dem
Transaktion, die die Schleife entfernen könnte. Außerdem versucht systemd, nicht unbedingt erforderliche Jobs zu unterdrücken
in der Transaktion, die einen laufenden Dienst stoppen würde. Abschließend wird geprüft, ob die
Jobs der Transaktion stehen im Widerspruch zu Jobs, die bereits in die Warteschlange gestellt wurden, und optional die
Die Transaktion wird dann abgebrochen. Wenn alles geklappt hat und die Transaktion konsistent ist und
In seiner Wirkung minimiert, wird es mit allen bereits ausstehenden Jobs zusammengeführt und dem hinzugefügt
Warteschlange ausführen. Tatsächlich bedeutet dies, dass vor der Ausführung einer angeforderten Operation systemd
überprüft, ob es Sinn macht, repariert es, wenn möglich, und schlägt nur dann fehl, wenn es wirklich so ist
kann nicht arbeiten.

Systemd enthält native Implementierungen verschiedener Aufgaben, die als Teil ausgeführt werden müssen
des Bootvorgangs. Es legt beispielsweise den Hostnamen fest oder konfiguriert das Loopback-Netzwerk
Gerät. Außerdem werden verschiedene API-Dateisysteme eingerichtet und gemountet, z / sys oder /proc.

Weitere Informationen zu den Konzepten und Ideen hinter systemd finden Sie im
Original Design Dokument[2].

Beachten Sie, dass einige, aber nicht alle von systemd bereitgestellten Schnittstellen von abgedeckt werden Interface
Stabilität Versprechen[3].

Einheiten können beispielsweise beim Booten und beim Neuladen des Systemmanagers dynamisch generiert werden
basierend auf anderen Konfigurationsdateien oder Parametern, die auf der Kernel-Befehlszeile übergeben werden. Für
Details, siehe systemd.generator(7).

Systeme, die systemd in einer Container- oder Initrd-Umgebung aufrufen, sollten Folgendes implementieren
Container Interface[4] oder initrd Interface[5] Spezifikationen bzw.

VERZEICHNISSE

Verzeichnisse der Systemeinheiten
Der systemd-Systemmanager liest die Einheitenkonfiguration aus verschiedenen Verzeichnissen. Pakete
die Unit-Dateien installieren möchten, müssen diese in dem von zurückgegebenen Verzeichnis ablegen
pkg-config systemd --variable=systemdsystemunitdir. Andere überprüfte Verzeichnisse sind
/usr/local/lib/systemd/system und /lib/systemd/system. Die Benutzerkonfiguration dauert immer
Vorrang. pkg-config systemd --variable=systemdsystemconfdir gibt den Pfad von zurück
das Systemkonfigurationsverzeichnis. Pakete sollten deren Inhalt ändern
Verzeichnisse nur mit der ermöglichen und deaktivieren Befehle der systemctl(1) Werkzeug. Voll
Eine Liste der Verzeichnisse finden Sie in systemd.einheit(5).

Verzeichnisse der Benutzereinheiten
Ähnliche Regeln gelten für die Verzeichnisse der Benutzereinheiten. Allerdings hier die XDG Basis
Verzeichnis Spezifikation[6] wird befolgt, um Einheiten zu finden. Bewerbungen sollten eingereicht werden
Unit-Dateien im von zurückgegebenen Verzeichnis pkg-config systemd
--variable=systemduserunitdir. Die globale Konfiguration erfolgt im angegebenen Verzeichnis
by pkg-config systemd --variable=systemduserconfdirdem „Vermischten Geschmack“. Seine ermöglichen und deaktivieren Befehle
systemctl(1) Das Tool kann sowohl globale (d. h. für alle Benutzer) als auch private (für) verarbeiten
(ein Benutzer) Aktivieren/Deaktivieren von Einheiten. Eine vollständige Liste der Verzeichnisse finden Sie in
systemd.einheit(5).

Verzeichnis der SysV-Init-Skripte
Der Speicherort des SysV-Init-Skriptverzeichnisses variiert je nach Distribution. Wenn
systemd keine native Unit-Datei für einen angeforderten Dienst finden kann, sucht es nach einer
SysV-Init-Skript mit demselben Namen (ohne .service-Suffix).

Verzeichnis der SysV-Runlevel-Linkfarm
Der Speicherort des SysV-Runlevel-Linkfarmverzeichnisses variiert je nach Distribution.
systemd berücksichtigt die Linkfarm, wenn es darum geht, herauszufinden, ob ein Dienst dies tun soll
aktiviert sein. Beachten Sie, dass eine Serviceeinheit mit einer nativen Einheitenkonfigurationsdatei nicht vorhanden sein kann
Dies wurde durch die Aktivierung in der SysV-Runlevel-Linkfarm gestartet.

SIGNALE

ZIELLAUFZEIT
Beim Empfang dieses Signals serialisiert der systemd-Systemmanager seinen Status und führt ihn erneut aus
selbst und deserialisiert den gespeicherten Zustand erneut. Dies ist größtenteils gleichbedeutend mit systemctl
daemon-reexec.

Systemd-Benutzermanager starten die Einheit „exit.target“, wenn dieses Signal empfangen wird.
Dies ist größtenteils gleichbedeutend mit systemctl --Benutzer Anfang Exit.Ziel.

SIGINT
Beim Empfang dieses Signals startet der systemd-Systemmanager das
Strg-Alt-Entf.Zieleinheit. Dies ist größtenteils gleichbedeutend mit systemctl Anfang
ctl-alt-del.target. Wenn dieses Signal mehr als 7 Mal alle 2 Sekunden empfangen wird, erfolgt eine sofortige Meldung
Neustart wird ausgelöst. Beachten Sie, dass dies durch Drücken von Strg-Alt-Entf auf der Konsole ausgelöst wird
Signal. Wenn also ein Neustart hängen bleibt, drücken Sie Strg-Alt-Entf mehr als sieben Mal in 7 Sekunden
ist eine relativ sichere Möglichkeit, einen sofortigen Neustart auszulösen.

systemd-Benutzermanager behandeln dieses Signal genauso wie ZIELLAUFZEIT.

SIGWINCH
Wenn dieses Signal empfangen wird, startet der systemd-Systemmanager das
kbrequest.target-Einheit. Dies ist größtenteils gleichbedeutend mit systemctl Anfang kbrequest.target.

Dieses Signal wird von systemd-Benutzermanagern ignoriert.

SIGPWR
Wenn dieses Signal empfangen wird, startet der Systemd-Manager die Einheit sigpwr.target.
Dies ist größtenteils gleichbedeutend mit systemctl Anfang sigpwr.target.

SIGUSR1
Wenn dieses Signal empfangen wird, versucht der Systemmanager, die Verbindung zum D-Bus wiederherzustellen
Bus.

SIGUSR2
Wenn dieses Signal empfangen wird, protokolliert der Systemd-Manager seinen vollständigen Status
menschenlesbare Form. Die protokollierten Daten sind die gleichen, die von gedruckt wurden systemd-analyse abladen.

SEUFZEND
Lädt die komplette Daemon-Konfiguration neu. Dies ist größtenteils gleichbedeutend mit systemctl
Daemon-Neuladen.

SIGRTMIN+0
Wechselt in den Standardmodus und startet die Einheit „default.target“. Dies ist größtenteils gleichbedeutend mit
systemctl Anfang default.target.

SIGRTMIN+1
Wechselt in den Rettungsmodus und startet die Einheit „rescue.target“. Dies ist größtenteils gleichbedeutend mit
systemctl isolieren Rettungsziel.

SIGRTMIN+2
Wechselt in den Notfallmodus und startet die Notdiensteinheit. Dies ist größtenteils gleichbedeutend mit
systemctl isolieren Notdienst.

SIGRTMIN+3
Hält die Maschine an und startet die halt.target-Einheit. Dies ist größtenteils gleichbedeutend mit systemctl
Anfang halt.target.

SIGRTMIN+4
Schaltet die Maschine aus und startet die poweroff.target-Einheit. Dies ist größtenteils gleichbedeutend mit
systemctl Anfang poweroff.target.

SIGRTMIN+5
Startet die Maschine neu und startet die reboot.target-Einheit. Dies ist größtenteils gleichbedeutend mit
systemctl Anfang reboot.target.

SIGRTMIN+6
Startet die Maschine über kexec neu und startet die kexec.target-Einheit. Dies ist größtenteils gleichwertig
zu systemctl Anfang kexec.target.

SIGRTMIN+13
Stoppt die Maschine sofort.

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
Ermöglicht die Anzeige von Statusmeldungen auf der Konsole, gesteuert über
systemd.show_status=1 in der Kernel-Befehlszeile.

SIGRTMIN+21
Deaktiviert die Anzeige von Statusmeldungen auf der Konsole, wie über gesteuert
systemd.show_status=0 in der Kernel-Befehlszeile.

SIGRTMIN+22, SIGRTMIN+23
Setzt die Protokollebene auf „debug“ (oder „info“) SIGRTMIN+23), wie gesteuert über
systemd.log_level=debug (oder systemd.log_level=info on SIGRTMIN+23) auf dem Kernel
Befehlszeile.

SIGRTMIN+24
Beendet den Manager sofort (nur für --user-Instanzen verfügbar).

SIGRTMIN+26, SIGRTMIN+27, SIGRTMIN+28
Setzt die Protokollebene auf „journal-or-kmsg“ (oder „console“) SIGRTMIN+27, „kmsg“ an
SIGRTMIN+28), wie gesteuert über systemd.log_target=journal-or-kmsg (oder
systemd.log_target=console on SIGRTMIN+27 or systemd.log_target=kmsg on SIGRTMIN+28)
in der Kernel-Befehlszeile.

$SYSTEMD_LOG_LEVEL
systemd liest die Protokollebene aus dieser Umgebungsvariablen. Dies kann überschrieben werden
mit --log-level=.

$SYSTEMD_LOG_TARGET
systemd liest das Protokollziel aus dieser Umgebungsvariablen. Dies kann überschrieben werden
mit --log-target=.

$SYSTEMD_LOG_COLOR
Steuert, ob systemd wichtige Protokollmeldungen hervorhebt. Dies kann überschrieben werden
mit --log-color=.

$SYSTEMD_LOG_LOCATION
Steuert, ob systemd den Codespeicherort zusammen mit Protokollmeldungen druckt. Das kann sein
überschrieben mit --log-location=.

$XDG_CONFIG_HOME, $XDG_CONFIG_DIRS, $XDG_DATA_HOME, $XDG_DATA_DIRS
Der systemd-Benutzermanager verwendet diese Variablen gemäß XDG Basis Verzeichnis
Spezifikation[6], um seine Konfiguration zu finden.

$SYSTEMD_UNIT_PATH
Steuert, wo systemd nach Unit-Dateien sucht.

$SYSTEMD_SYSVINIT_PATH
Steuert, wo systemd nach SysV-Init-Skripten sucht.

$SYSTEMD_SYSVRCND_PATH
Steuert, wo systemd nach SysV-Init-Skript-Runlevel-Linkfarmen sucht.

$SYSTEMD_COLORS
Steuert, ob eine kolorierte Ausgabe generiert werden soll.

$LISTEN_PID, $LISTEN_FDS, $LISTEN_FDNAMES
Wird von systemd für überwachte Prozesse während der Socket-basierten Aktivierung festgelegt. Sehen
sd_listen_fds(3) für weitere Informationen.

$NOTIFY_SOCKET
Wird von systemd für überwachte Prozesse für Status und Startabschluss festgelegt
Benachrichtigung. Sehen sd_notify(3) für weitere Informationen.

KERN COMMAND LINE

Bei der Ausführung als Systeminstanz analysiert systemd eine Reihe von Kernel-Befehlszeilenargumenten[7]:

systemd.unit=, rd.systemd.unit=
Überschreibt die beim Booten zu aktivierende Einheit. Standardmäßig ist default.target. Dies darf genutzt werden
um vorübergehend in eine andere Boot-Einheit zu booten, zum Beispiel Rescue.target oder
Notdienst. Sehen systemd.special(7) für Einzelheiten zu diesen Einheiten. Die Option
mit dem Präfix „rd.“ wird nur in der anfänglichen RAM-Disk (initrd) berücksichtigt, während die eine
das wird nicht nur im Hauptsystem vorangestellt.

systemd.dump_core=
Akzeptiert ein boolesches Argument. Wenn ja, der Systemd-Manager (PID 1) gibt den Kern aus, wenn er
stürzt ab. Andernfalls wird kein Core-Dump erstellt. Standardmäßig ist ja.

systemd.crash_chvt=
Akzeptiert eine positive Ganzzahl oder ein boolesches Argument. Wenn eine positive ganze Zahl (im Bereich
1–63) angegeben wird, aktiviert der Systemmanager (PID 1) die angegebene virtuelle
Terminal (VT), wenn es abstürzt. Standardmäßig ist nicht, was bedeutet, dass es keinen solchen Schalter gibt
versucht. Wenn eingestellt auf ja, wird das VT ausgewählt, in das die Kernel-Nachrichten geschrieben werden.

systemd.crash_shell=
Akzeptiert ein boolesches Argument. Wenn ja, der Systemmanager (PID 1) erzeugt eine Shell, wenn er
stürzt nach einer Verzögerung von 10 Sekunden ab. Andernfalls wird keine Muschel gespawnt. Standardmäßig ist nichtZ.
Sicherheitsgründen, da die Shell nicht durch eine Passwortauthentifizierung geschützt ist.

systemd.crash_reboot=
Akzeptiert ein boolesches Argument. Wenn ja, startet der Systemmanager (PID 1) die Maschine neu
automatisch, wenn es abstürzt, nach einer Verzögerung von 10 Sekunden. Andernfalls bleibt das System hängen
unbegrenzt. Standardmäßig ist nicht, um eine Neustartschleife zu vermeiden. In Kombination mit
systemd.crash_shell=, wird das System nach dem Beenden der Shell neu gestartet.

systemd.confirm_spawn=
Akzeptiert ein boolesches Argument. Wenn ja, bittet der Systemmanager (PID 1) um Bestätigung
bei Laichprozessen. Standardmäßig ist nicht.

systemd.show_status=
Akzeptiert ein boolesches Argument oder die Konstante Auto. Wenn ja, der Systemd-Manager (PID 1)
Zeigt während des Startvorgangs knappe Aktualisierungen des Dienststatus auf der Konsole an. Auto benimmt sich wie
falsch bis ein Dienst ausfällt oder es zu einer erheblichen Verzögerung beim Booten kommt. Standardmäßig ist ja,
es sei denn ruhig wird als Kernel-Befehlszeilenoption übergeben, in diesem Fall ist es standardmäßig
Auto.

systemd.log_target=, systemd.log_level=, systemd.log_color=, systemd.log_location=
Steuert die Protokollausgabe mit dem gleichen Effekt wie $SYSTEMD_LOG_TARGET,
$SYSTEMD_LOG_LEVEL, $SYSTEMD_LOG_COLOR, $SYSTEMD_LOG_LOCATION Umgebungsvariablen
oben beschrieben.

systemd.default_standard_output=, systemd.default_standard_error=
Steuert die standardmäßige Standardausgabe und Fehlerausgabe für Dienste mit demselben Effekt
wie die --default-standard-output= und --default-standard-error= Kommandozeilenargumente
oben beschrieben.

systemd.setenv=
Akzeptiert ein Zeichenfolgenargument in der Form VARIABLE=VALUE. Kann zum Festlegen von Standardwerten verwendet werden
Umgebungsvariablen zum Hinzufügen zu gegabelten untergeordneten Prozessen. Kann mehr als einmal verwendet werden
Legen Sie mehrere Variablen fest.

systemd.machine_id=
Nimmt einen 32-stelligen Hexadezimalwert an, der zum Festlegen der Maschinen-ID verwendet wird. Größtenteils beabsichtigt
für Netzwerkstarts, bei denen für jeden Start dieselbe Maschinen-ID gewünscht wird.

ruhig
Deaktivieren Sie die Statusausgabe beim Booten, ähnlich wie systemd.show_status=false würde. Beachten Sie, dass
Diese Option wird auch vom Kernel selbst gelesen und deaktiviert die Kernel-Protokollausgabe. Vorbeigehen
Diese Option schaltet daher die übliche Ausgabe sowohl des Systemmanagers als auch des aus
Kernel.

debuggen
Aktivieren Sie die Debug-Ausgabe. Dies entspricht systemd.log_level=debug. Beachten Sie, dass
Diese Option wird auch vom Kernel selbst gelesen und ermöglicht die Kernel-Debug-Ausgabe. Vorbeigehen
Diese Option aktiviert daher die Debug-Ausgabe sowohl vom Systemmanager als auch vom
Kernel.

Notfall, -b
Booten Sie in den Notfallmodus. Dies entspricht systemd.unit=emergency.target und
wird aus Kompatibilitätsgründen und zur einfacheren Eingabe bereitgestellt.

retten, Single, s, S, 1
Booten Sie in den Rettungsmodus. Dies entspricht systemd.unit=rescue.target und zur Verfügung gestellt
aus Kompatibilitätsgründen und um die Eingabe zu erleichtern.

2, 3, 4, 5
Booten Sie in den angegebenen Legacy-SysV-Runlevel. Diese entsprechen
systemd.unit=runlevel2.target, systemd.unit=runlevel3.target,
systemd.unit=runlevel4.target und systemd.unit=runlevel5.targetbzw. und
wird aus Kompatibilitätsgründen und zur einfacheren Eingabe 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=
Legen Sie das zu verwendende Systemgebietsschema fest. Dies überschreibt die Einstellungen in /etc/locale.conf. Für
mehr Informationen, siehe locale.conf(5) und lokal(7).

Weitere Kernel-Befehlszeilenparameter, die von Komponenten des Kernbetriebssystems verstanden werden, finden Sie hier
beziehen sich auf Kernel-Befehlszeile(7).

STECKDOSEN UND FIFOS

/run/systemd/notify
Socket für Daemon-Statusbenachrichtigungen. Das ist ein AF_UNIX Datagramm-Socket und ist daran gewöhnt
Implementieren Sie die Daemon-Benachrichtigungslogik, wie von implementiert sd_notify(3).

/run/systemd/private
Wird intern als Kommunikationskanal zwischen verwendet systemctl(1) und der systemd-Prozess.
Hier ist eine AF_UNIX Stream-Socket. Diese Schnittstelle ist für systemd privat und sollte dies nicht tun
in externen Projekten verwendet werden.

/dev/initctl
Eingeschränkte Kompatibilitätsunterstützung für die SysV-Clientschnittstelle, wie von implementiert
systemd-initctl.service-Einheit. Dies ist eine Named Pipe im Dateisystem. Diese Schnittstelle
ist veraltet und sollte nicht in neuen Anwendungen verwendet werden.

Verwenden Sie systemd online über die Dienste von onworks.net