systemd, init - System- und Dienstemanager
SYNOPSIS
/usr/lib/systemd/systemd [OPTIONEN...]
init [OPTIONEN...]
BESCHREIBUNG
systemd ist ein System- und Dienstemanager für Linux-Betriebssysteme. Wenn es als erster Prozess beim Booten (als PID 1) ausgeführt wird, fungiert es als Init-System, das Benutzerraumdienste startet und verwaltet. Separate Instanzen werden für angemeldete Benutzer gestartet, um deren Dienste zu starten.
systemd wird normalerweise nicht direkt vom Benutzer aufgerufen, sondern als Symlink /sbin/init installiert und während des frühen Bootvorgangs gestartet. Die Benutzerinstanzen werden automatisch über den Dienst [email protected](5) gestartet.
Wenn es als Systeminstanz ausgeführt wird, interpretiert systemd die Konfigurationsdatei system.conf und die Dateien in den Verzeichnissen system.conf.d; wenn es als Benutzerinstanz ausgeführt wird, interpretiert systemd die Konfigurationsdatei user.conf und die Dateien in den Verzeichnissen user.conf.d. Weitere Informationen finden Sie in systemd-system.conf(5).
systemd enthält native Implementierungen verschiedener Aufgaben, die als Teil des Bootvorgangs ausgeführt werden müssen. Zum Beispiel setzt es den Hostnamen oder konfiguriert das Loopback-Netzwerkgerät. Es richtet auch verschiedene API-Dateisysteme ein und bindet sie ein, wie z. B. /sys/, /proc/ und /dev/.
systemd setzt die Systemuhr während des frühen Bootvorgangs zurück, wenn sie falsch eingestellt zu sein scheint. Siehe den Abschnitt „System Clock Epoch“ unten.
Beachten Sie, dass nicht alle von systemd bereitgestellten Schnittstellen durch die Interface Portability and Stability Promise[1] abgedeckt sind.
Die D-Bus-API von systemd wird in org.freedesktop.systemd1(5) und org.freedesktop.LogControl1(5) beschrieben.
Systeme, die systemd in einer Container- oder Initrd-Umgebung aufrufen, sollten die Container Interface[2] bzw. die Initrd Interface[3]-Spezifikationen implementieren.
EINHEITEN
systemd bietet ein Abhängigkeitssystem zwischen verschiedenen Entitäten, die als „Einheiten“ bezeichnet werden, von 11 verschiedenen Typen. Einheiten kapseln verschiedene Objekte, die für den Systemstart und die Wartung relevant sind. Die Mehrheit der Einheiten wird in Konfigurationsdateien für Einheiten konfiguriert, deren Syntax und grundlegende Optionen in systemd.unit(5) beschrieben sind, jedoch werden einige automatisch aus anderen Konfigurationsdateien, dynamisch aus dem Systemstatus oder programmgesteuert zur Laufzeit erstellt. Einheiten können sich in einer Reihe von Zuständen befinden, die in der folgenden Tabelle beschrieben sind. Beachten Sie, dass die verschiedenen Einheitentypen eine Reihe zusätzlicher Unterzustände haben können, die den hier beschriebenen verallgemeinerten Einheitenzuständen zugeordnet werden.
Tabelle 1. Einheitliche ACTIVE-Zustände
┌──────────────┬─────────────────────────────────────┐
│ Zustand │ Beschreibung │
├──────────────┼─────────────────────────────────────┤
│ aktiv │ Gestartet, gebunden, eingesteckt, ..., │
│ │ abhängig vom Einheitentyp. │
├──────────────┼─────────────────────────────────────┤
│ inaktiv │ Gestoppt, nicht gebunden, ausgezogen, ...,│
│ │ abhängig vom Einheitentyp. │
├──────────────┼─────────────────────────────────────┤
│ fehlgeschlagen │ Ähnlich wie inaktiv, aber die Einheit │
│ │ ist auf irgendeine Weise fehlgeschlagen │
│ │ (der Prozess hat einen Fehlercode bei │
│ │ der Beendigung zurückgegeben, ist │
│ │ abgestürzt, eine Operation ist abgelaufen oder │
│ │ nach zu vielen Neustarts. │
├──────────────┼─────────────────────────────────────┤
│ aktivierend │ Übergang von inaktiv zu aktiv. │
├──────────────┼─────────────────────────────────────┤
│ deaktivierend │ Übergang von aktiv zu inaktiv. │
├──────────────┼─────────────────────────────────────┤
│ Wartung │ Einheit ist inaktiv und eine Wartungs- │
│ │ operation ist im Gange. │
├──────────────┼─────────────────────────────────────┤
│ neu laden │ Einheit ist aktiv und konfiguriert ihre │
│ │ Konfiguration neu. │
├──────────────┼─────────────────────────────────────┤
│ aktualisieren │ Einheit ist aktiv und ein neues Mount │
│ │ wird in ihrem Namespace aktiviert. │
└──────────────┴─────────────────────────────────────┘
Folgende Einheitentypen stehen zur Verfügung:
Service-Einheiten, die Daemons starten und die darin enthaltenen Prozesse steuern.
Weitere Informationen finden Sie unter systemd.service(5).
Socket-Einheiten, die lokale IPC- oder Netzwerksockets im System kapseln und für die Socket-basierte Aktivierung nützlich sind. Weitere Informationen zu Socket-Einheiten finden Sie unter systemd.socket(5). Weitere Informationen zur Socket-basierten Aktivierung und anderen Aktivierungsformen finden Sie unter daemon(7).
Ziel-Einheiten sind nützlich, um Einheiten zu gruppieren oder bekannte Synchronisationspunkte während des
Bootvorgangs bereitzustellen, siehe systemd.target(5).
Geräte-Einheiten stellen Kernel-Geräte in systemd dar und können verwendet werden, um eine gerätebasierte
Aktivierung zu implementieren. Einzelheiten finden Sie in systemd.device(5).
Mount-Einheiten steuern Mount-Punkte im Dateisystem, Einzelheiten finden Sie in systemd.mount(5).
Automount-Einheiten bieten Automount-Funktionen für die bedarfsgerechte Mountung von Dateisystemen sowie für die parallele Ausführung während des Bootvorgangs. Siehe systemd.automount(5).
Timer-Einheiten sind nützlich, um die Aktivierung anderer Einheiten basierend auf Timern auszulösen. Einzelheiten finden Sie in systemd.timer(5).
Swap-Einheiten sind sehr ähnlich wie Mount-Einheiten und kapseln Speicher-Swap-Partitionen oder -Dateien des Betriebssystems. Sie werden in systemd.swap(5) beschrieben.
Path-Einheiten können verwendet werden, um andere Dienste zu aktivieren, wenn sich Dateisystemobjekte ändern oder modifiziert werden. Siehe systemd.path(5).
Slice-Einheiten können verwendet werden, um Einheiten zu gruppieren, die Systemprozesse (z. B. Service- und Scope-Einheiten) in einer hierarchischen Struktur für Ressourcenverwaltungszwecke verwalten. Siehe systemd.slice(5).
Scope-Einheiten sind ähnlich wie Service-Einheiten, verwalten aber fremde Prozesse anstelle von deren Start. Siehe systemd.scope(5).
Einheiten werden nach ihren Konfigurationsdateien benannt. Einige Einheiten haben eine besondere Bedeutung. Eine detaillierte Liste finden Sie in systemd.special(7).
systemd kennt verschiedene Arten von Abhängigkeiten, darunter positive und negative Anforderungsabhängigkeiten (d. h. Requires= und Conflicts=) sowie Ordnungsabhängigkeiten (After= und Before=). Beachten Sie: Ordnungs- und Anforderungsabhängigkeiten sind orthogonal. Wenn nur eine Anforderungsabhängigkeit zwischen zwei Einheiten besteht (z. B. foo.service erfordert bar.service), aber keine Ordnungsabhängigkeit (z. B. foo.service nach bar.service) und beide zum Start angefordert werden, werden sie parallel gestartet. Es ist ein übliches Muster, dass sowohl Anforderungs- als auch Ordnungsabhängigkeiten zwischen zwei Einheiten platziert werden. Beachten Sie außerdem, dass die Mehrheit der Abhängigkeiten implizit von systemd erstellt und verwaltet wird. In den meisten Fällen sollte es unnötig sein, zusätzliche Abhängigkeiten manuell zu deklarieren, dies ist jedoch möglich.
Anwendungsprogramme und Einheiten (über Abhängigkeiten) können Statusänderungen von Einheiten anfordern. In systemd werden diese Anforderungen als „Jobs“ gekapselt und in einer Job-Warteschlange verwaltet. Jobs können erfolgreich sein oder fehlschlagen, ihre Ausführung wird basierend auf den Ordnungsabhängigkeiten der Einheiten, für die sie geplant wurden, geordnet.
Beim Bootvorgang aktiviert systemd die Ziel-Einheit default.target, deren Aufgabe es ist, beim Bootvorgang Dienste und andere Einheiten zu aktivieren, indem sie diese über Abhängigkeiten einbezieht. Normalerweise ist der Einheitsname nur ein Alias (symbolischer Link) für entweder graphical.target (für voll ausgestattete Boots mit grafischer Oberfläche) oder multi-user.target (für eingeschränkte, reine Konsolen-Boots für den Einsatz in eingebetteten oder Serverumgebungen oder ähnliches; eine Teilmenge von graphical.target). Es liegt jedoch im Ermessen des Administrators, diese als Alias für eine andere Ziel-Einheit zu konfigurieren. Einzelheiten finden Sie in systemd.special(7) zu diesen Ziel-Einheiten.
Beim ersten Start aktiviert oder deaktiviert systemd Units gemäß einer vordefinierten Richtlinie. Siehe systemd.preset(5) und „Semantik beim ersten Start“ in machine-id(5).
systemd hält nur einen minimalen Satz von Units im Speicher. Konkret werden nur die Units im Speicher gehalten, für die mindestens eine der folgenden Bedingungen zutrifft:
Sie befindet sich in einem aktiven, aktivierenden, deaktivierenden oder fehlgeschlagenen Zustand (d. h. in einem Unit-Status außer „inaktiv“).
Für sie ist ein Job in der Warteschlange.
Sie ist eine Abhängigkeit von mindestens einer anderen Unit, die im Speicher geladen ist.
Sie hat noch eine Art von Ressource zugewiesen (z. B. eine Service-Unit, die inaktiv ist, aber für die ein Prozess noch vorhanden ist, der die Anforderung zum Beenden ignoriert hat).
Sie wurde programmatisch über einen D-Bus-Aufruf im Speicher angepinnt.
systemd lädt Units automatisch und implizit von der Festplatte, falls sie noch nicht geladen sind, sobald Operationen für sie angefordert werden. In vielerlei Hinsicht ist die Tatsache, ob eine Unit geladen ist oder nicht, für Clients unsichtbar. Verwenden Sie `systemctl list-units --all`, um alle aktuell geladenen Units umfassend aufzulisten. Jede Unit, für die keine der oben genannten Bedingungen zutrifft, wird umgehend aus dem Speicher entfernt. Beachten Sie, dass beim Entladen einer Unit aus dem Speicher auch ihre Abrechnungsdaten gelöscht werden. Diese Daten gehen jedoch in der Regel nicht verloren, da ein Journal-Protokolleintrag generiert wird, der die verbrauchten Ressourcen erfasst, wenn eine Unit herunterfährt.
Von systemd erzeugte Prozesse werden in einzelnen Linux-Kontrollgruppen platziert, die nach der Unit benannt sind, zu der sie gehören, in der privaten systemd-Hierarchie. (Siehe Control Groups v2[4] für weitere Informationen über Kontrollgruppen oder kurz „cgroups“). systemd verwendet dies, um die Prozesse effektiv zu verfolgen. Informationen über Kontrollgruppen werden im Kernel gespeichert und sind über die Dateisystemhierarchie (unterhalb von /sys/fs/cgroup/) oder in Tools wie systemd-cgls(1) oder [ps]({filename}../../ps)(1) zugänglich (ps xawf -eo pid,user,cgroup,args ist besonders nützlich, um alle Prozesse und die systemd-Units aufzulisten, zu denen sie gehören).
systemd ist mit verschiedenen etablierten Unix-Funktionen wie /etc/fstab oder der utmp-Datenbank kompatibel.
systemd verfügt über ein minimales Transaktionssystem: Wenn eine Unit zum Starten oder Herunterfahren angefordert wird, fügt es diese und alle ihre Abhängigkeiten einer temporären Transaktion hinzu. Anschließend wird überprüft, ob die Transaktion konsistent ist (d. h., ob die Reihenfolge aller Units zyklusfrei ist). Wenn dies nicht der Fall ist, versucht systemd, dies zu beheben, und entfernt nicht wesentliche Jobs aus der Transaktion, die die Schleife beheben könnten. Außerdem versucht systemd, nicht wesentliche Jobs in der Transaktion zu unterdrücken, die einen laufenden Dienst stoppen würden. Schließlich wird überprüft, ob die Jobs der Transaktion Jobs widersprechen, die bereits in der Warteschlange stehen, und optional wird die Transaktion dann abgebrochen. Wenn alles geklappt hat und die Transaktion konsistent ist und ihre Auswirkungen minimiert wurden, wird sie mit allen bereits ausstehenden Jobs zusammengeführt und der Ausführungswarteschlange hinzugefügt. Im Wesentlichen bedeutet dies, dass systemd vor der Ausführung einer angeforderten Operation überprüft, ob diese sinnvoll ist, sie gegebenenfalls korrigiert und nur dann fehlschlägt, wenn dies wirklich nicht möglich ist.
Beachten Sie, dass Transaktionen unabhängig vom Zustand einer Einheit zur Laufzeit generiert werden. Wenn beispielsweise ein Startauftrag für eine bereits gestartete Einheit angefordert wird, wird dennoch eine Transaktion generiert und alle inaktiven Abhängigkeiten werden aktiviert (und es kommt zur Auslösung anderer Aufträge gemäß den definierten Beziehungen). Dies liegt daran, dass der in die Warteschlange eingereihte Auftrag zum Zeitpunkt der Ausführung mit dem Zustand der Zieleinheit verglichen wird und als erfolgreich und abgeschlossen markiert wird, wenn beide Bedingungen erfüllt sind. Dieser Auftrag ruft jedoch auch andere Abhängigkeiten aufgrund der definierten Beziehungen auf und führt so, in unserem Beispiel, dazu, dass auch Startaufträge für alle inaktiven Einheiten in die Warteschlange gestellt werden.
Einheiten können dynamisch beim Booten und beim erneuten Laden des Systemmanagers generiert werden, beispielsweise basierend auf anderen Konfigurationsdateien oder Parametern, die an die Kernel-Kommandozeile übergeben werden. Einzelheiten finden Sie unter systemd.generator(7).
VERZEICHNISSE
Systemeinheitsverzeichnisse
Der Systemd-Systemmanager liest Einheitskonfigurationen aus verschiedenen Verzeichnissen. Pakete, die Einheitsdateien installieren möchten, sollten diese in das Verzeichnis legen, das von pkg-config systemd --variable=systemdsystemunitdir zurückgegeben wird. Weitere überprüfte Verzeichnisse sind /usr/local/lib/systemd/system und /usr/lib/systemd/system. Benutzerkonfigurationen haben immer Vorrang. pkg-config systemd --variable=systemdsystemconfdir gibt den Pfad des Systemkonfigurationsverzeichnisses zurück.
Pakete sollten den Inhalt dieser Verzeichnisse nur mit den Befehlen enable und disable des Tools systemctl(1) ändern. Eine vollständige Liste der Verzeichnisse finden Sie in systemd.unit(5).
Benutzereinheitsverzeichnisse
Ähnliche Regeln gelten für die Benutzereinheitsverzeichnisse. Hier wird jedoch die XDG Base Directory Specification[5] verwendet, um die Einheiten zu finden. Anwendungen sollten ihre Einheitsdateien in das Verzeichnis legen, das von pkg-config systemd --variable=systemduserunitdir zurückgegeben wird. Die globale Konfiguration erfolgt in dem Verzeichnis, das von pkg-config systemd --variable=systemduserconfdir gemeldet wird. Die Befehle enable und disable des Tools systemctl(1) können sowohl das globale (d. h. für alle Benutzer) als auch das private (für einen Benutzer) Aktivieren/Deaktivieren von Einheiten verarbeiten. Eine vollständige Liste der Verzeichnisse finden Sie in systemd.unit(5).
SIGNALE
Der Dienst lauscht auf verschiedene UNIX-Prozesssignale, die verwendet werden können, um verschiedene Aktionen asynchron anzufordern. Die Signalbehandlung wird sehr früh während des Bootvorgangs aktiviert, bevor weitere Prozesse aufgerufen werden. Ein übergeordneter Container-Manager oder ein ähnliches System, das beabsichtigt, diese Operationen über diesen Mechanismus anzufordern, muss jedoch berücksichtigen, dass diese Funktionalität während der frühesten Initialisierungsphase nicht verfügbar ist. Eine sd_notify()-Nachricht, die das Feld X_SYSTEMD_SIGNALS_LEVEL=2 enthält, wird gesendet, sobald die Signalhandler aktiviert sind, siehe unten. Dies kann verwendet werden, um die korrekte Einreichung dieser Signale zu planen.
SIGTERM
Wenn dieses Signal empfangen wird, serialisiert der Systemd-Systemmanager seinen Zustand, führt sich selbst erneut aus
und deserialisiert den gespeicherten Zustand erneut. Dies entspricht im Wesentlichen `systemctl daemon-reexec`.
Systemd-Benutzermanager starten die `exit.target`-Einheit, wenn dieses Signal empfangen wird. Dies entspricht im Wesentlichen `systemctl --user start exit.target --job-mode=replace-irreversibly`.
SIGINT
Wenn dieses Signal empfangen wird, startet der Systemd-Systemmanager die `ctrl-alt-del.target`-Einheit. Dies entspricht im Wesentlichen `systemctl start ctrl-alt-del.target --job-mode=replace-irreversibly`. Wenn dieses Signal innerhalb von 2 Sekunden mehr als 7 Mal empfangen wird, wird ein sofortiger Neustart ausgelöst. Beachten Sie, dass das Drücken von Strg+Alt+Entf auf der Konsole dieses Signal auslöst. Wenn ein Neustart fehlschlägt, ist das mehrmalige (mehr als 7 Mal innerhalb von 2 Sekunden) Drücken von Strg+Alt+Entf eine relativ sichere Möglichkeit, einen sofortigen Neustart auszulösen.
Systemd-Benutzermanager behandeln dieses Signal genauso wie SIGTERM.
SIGWINCH
Wenn dieses Signal empfangen wird, startet der Systemd-Systemmanager die `kbrequest.target`-Einheit. Dies entspricht im Wesentlichen `systemctl start kbrequest.target`.
Dieses Signal wird von Systemd-Benutzermanagern ignoriert.
SIGPWR
Wenn dieses Signal empfangen wird, startet der Systemd-Manager die `sigpwr.target`-Einheit. Dies entspricht im Wesentlichen `systemctl start sigpwr.target`.
SIGUSR1
Wenn dieses Signal empfangen wird, versucht der Systemd-Manager, sich erneut mit dem D-Bus-Bus zu verbinden.
SIGUSR2
Wenn dieses Signal empfangen wird, protokolliert der Systemd-Manager seinen vollständigen Zustand in einem für Menschen lesbaren Format. Die protokollierten Daten sind die gleichen, die mit `systemd-analyze dump` ausgegeben werden.
SIGHUP
Lädt die vollständige Daemon-Konfiguration neu. Dies entspricht im Wesentlichen `systemctl daemon-reload`.
SIGRTMIN+0
Wechselt in den Standardmodus, startet die `default.target`-Einheit. Dies entspricht im Wesentlichen `systemctl isolate default.target`.
SIGRTMIN+1
Wechselt in den Rettungsmodus, startet die `rescue.target`-Einheit. Dies entspricht im Wesentlichen `systemctl isolate rescue.target`.
SIGRTMIN+2
Wechselt in den Notfallmodus, startet die `emergency.service`-Einheit. Dies entspricht im Wesentlichen `systemctl isolate emergency.service`.
SIGRTMIN+3
Hält die Maschine an, startet die `halt.target`-Einheit. Dies entspricht im Wesentlichen `systemctl start halt.target --job-mode=replace-irreversibly`.
SIGRTMIN+4
Schaltet die Maschine aus, startet die `poweroff.target`-Einheit. Dies entspricht im Wesentlichen `systemctl start poweroff.target --job-mode=replace-irreversibly`.
SIGRTMIN+5
Startet die Maschine neu, startet die `reboot.target`-Einheit. Dies entspricht im Wesentlichen `systemctl start reboot.target --job-mode=replace-irreversibly`.
SIGRTMIN+6
Startet die Maschine über Kexec neu, startet die `kexec.target`-Einheit. Dies entspricht im Wesentlichen `systemctl start kexec.target --job-mode=replace-irreversibly`.
SIGRTMIN+7
Startet den Benutzeraum neu, startet die soft-reboot.target-Einheit. Dies entspricht im Wesentlichen systemctl start soft-reboot.target --job-mode=replace-irreversibly.
Hinzugefügt in Version 254.
SIGRTMIN+13
Hält die Maschine sofort an.
SIGRTMIN+14
Schaltet die Maschine sofort aus.
SIGRTMIN+15
Startet die Maschine sofort neu.
SIGRTMIN+16
Startet die Maschine sofort mit kexec neu.
SIGRTMIN+17
Startet den Benutzeraum sofort neu.
Hinzugefügt in Version 254.
SIGRTMIN+20
Aktiviert die Anzeige von Statusmeldungen auf der Konsole, wie durch systemd.show_status=1 auf der Kernel-Kommandozeile gesteuert.
Möglicherweise möchten Sie stattdessen SetShowStatus() anstelle von SIGRTMIN+20 verwenden, um Race Conditions zu vermeiden. Siehe org.freedesktop.systemd1(5).
SIGRTMIN+21
Deaktiviert die Anzeige von Statusmeldungen auf der Konsole, wie durch systemd.show_status=0 auf der Kernel-Kommandozeile gesteuert.
Möglicherweise möchten Sie stattdessen SetShowStatus() anstelle von SIGRTMIN+21 verwenden, um Race Conditions zu vermeiden. Siehe org.freedesktop.systemd1(5).
SIGRTMIN+22
Setzt die Protokollebene des Service-Managers auf „debug“, und zwar auf eine Weise, die systemd.log_level=debug auf der Kernel-Kommandozeile entspricht.
SIGRTMIN+23
Stellt die Protokollebene auf ihren konfigurierten Wert zurück. Der konfigurierte Wert wird – in der folgenden Reihenfolge der Priorität – aus dem Wert abgeleitet, der mit systemd.log-level= auf der Kernel-Kommandozeile angegeben wird, oder aus dem Wert, der mit LogLevel= in der Konfigurationsdatei angegeben wird, oder aus dem integrierten Standardwert „info“.
Hinzugefügt in Version 239.
SIGRTMIN+24
Beendet den Manager sofort (nur für Instanzen von --user verfügbar).
Hinzugefügt in Version 195.
SIGRTMIN+25
Wenn dieses Signal empfangen wird, führt der Systemd-Manager sich selbst erneut aus. Dies entspricht im Wesentlichen systemctl daemon-reexec, außer dass dies asynchron geschieht.
Der Systemd-Systemmanager behandelt dieses Signal wie SIGTERM.
Hinzugefügt in Version 250.
SIGRTMIN+26
Stellt das Protokollziel auf seinen konfigurierten Wert zurück. Der konfigurierte Wert wird – in der folgenden Reihenfolge der Priorität – aus dem Wert abgeleitet, der mit systemd.log-target= auf der Kernel-Kommandozeile angegeben wird, oder aus dem Wert, der mit LogTarget= in der Konfigurationsdatei angegeben wird, oder aus dem integrierten Standardwert.
Hinzugefügt in Version 239.
SIGRTMIN+27, SIGRTMIN+28
Setzt das Protokollziel auf „Konsole“ bei SIGRTMIN+27 (oder auf „kmsg“ bei SIGRTMIN+28), und zwar auf eine Weise, die systemd.log_target=console (oder systemd.log_target=kmsg bei SIGRTMIN+28) auf der Kernel-Kommandozeile entspricht.
Hinzugefügt in Version 239.
UMGEBUNG
Der Umgebungspfad für den Systemmanager wird zunächst vom Kernel festgelegt. (Insbesondere werden „Schlüssel=Wert“-Zuweisungen auf der Kernel-Kommandozeile in Umgebungsvariablen für PID 1 umgewandelt.) Für den Benutzermanager legt der Systemmanager die Umgebung fest, wie im Abschnitt „Umgebungsvariablen in gestarteten Prozessen“ von systemd.exec(5) beschrieben. Die Einstellung DefaultEnvironment= im Systemmanager gilt für alle Dienste, einschließlich [email protected]. Zusätzliche Einträge können (wie bei jedem anderen Dienst) über die Einstellungen Environment= und EnvironmentFile= für [email protected] konfiguriert werden (siehe systemd.exec(5)). Darüber hinaus können zusätzliche Umgebungsvariablen über die Einstellung ManagerEnvironment= in systemd-system.conf(5) und systemd-user.conf(5) festgelegt werden.
Einige der von systemd unterstützten Variablen:
$SYSTEMD_LOG_LEVEL
Das maximale Log-Level der ausgegebenen Nachrichten (Nachrichten mit einem höheren Log-Level, d. h. weniger wichtigen Nachrichten, werden unterdrückt). Nimmt eine durch Kommas getrennte Liste von Werten an. Ein Wert kann entweder einer der folgenden sein (in absteigender Reihenfolge der Wichtigkeit): emerg, alert, crit, err, warning, notice, info, debug oder eine ganze Zahl im Bereich 0...7. Weitere Informationen finden Sie in syslog(3). Jeder Wert kann optional mit einem der folgenden Präfixe versehen werden: console, syslog, kmsg oder journal, gefolgt von einem Doppelpunkt, um das maximale Log-Level für das jeweilige Log-Ziel festzulegen (z. B. SYSTEMD_LOG_LEVEL=debug,console:info gibt an, dass Nachrichten auf Debug-Level protokolliert werden sollen, außer wenn sie in die Konsole geschrieben werden, wo sie auf Info-Level protokolliert werden sollen). Beachten Sie, dass das globale maximale Log-Level Vorrang vor allen zielspezifischen maximalen Log-Leveln hat.
Dies kann mit --log-level= überschrieben werden.
$SYSTEMD_LOG_COLOR
Ein boolescher Wert. Wenn true, werden Nachrichten, die in das TTY geschrieben werden, entsprechend ihrer Priorität farbig dargestellt.
Dies kann mit --log-color= überschrieben werden.
$SYSTEMD_LOG_TIME
Ein boolescher Wert. Wenn true, werden Konsolen-Log-Nachrichten mit einem Zeitstempel versehen.
Dies kann mit --log-time= überschrieben werden.
Hinzugefügt in Version 246.
$SYSTEMD_LOG_LOCATION
Ein boolescher Wert. Wenn true, werden Nachrichten mit dem Dateinamen und der Zeilennummer in dem Quellcode versehen, aus dem die Nachricht stammt.
Dies kann mit --log-location= überschrieben werden.
$SYSTEMD_LOG_TID
Ein boolescher Wert. Wenn true, werden Nachrichten mit der aktuellen numerischen Thread-ID (TID) versehen.
Hinzugefügt in Version 247.
$SYSTEMD_LOG_TARGET
Das Ziel für Log-Nachrichten. Eines von: console (Protokollierung in das angeschlossene TTY), console-prefixed (Protokollierung in das angeschlossene TTY, aber mit Präfixen, die das Log-Level und die „Facility“ kodieren, siehe syslog(3)), kmsg (Protokollierung in den Kernel-Ringpuffer), journal (Protokollierung im Journal), journal-or-kmsg (Protokollierung im Journal, falls verfügbar, und andernfalls in kmsg), auto (automatisches Bestimmen des geeigneten Log-Ziels, Standard), null (Deaktivieren der Log-Ausgabe).
Dies kann mit --log-target= überschrieben werden.
$SYSTEMD_LOG_RATELIMIT_KMSG
Gibt an, ob die Kmsg-Ausgabe begrenzt werden soll oder nicht. Nimmt einen booleschen Wert an. Standardmäßig ist dies „true“. Wenn deaktiviert, begrenzt systemd keine Nachrichten, die in Kmsg geschrieben werden.
Hinzugefügt in Version 254.
$XDG_CONFIG_HOME, $XDG_CONFIG_DIRS, $XDG_DATA_HOME, $XDG_DATA_DIRS
Der systemd-User-Manager verwendet diese Variablen gemäß der XDG Base Directory Spezifikation[5], um seine Konfiguration zu finden.
$SYSTEMD_UNIT_PATH, $SYSTEMD_GENERATOR_PATH, $SYSTEMD_ENVIRONMENT_GENERATOR_PATH
Steuert, wo systemd nach Unit-Dateien und Generatoren sucht.
Diese Variablen können eine Liste von Pfaden enthalten, die durch Doppelpunkte (":") getrennt sind. Wenn die Liste mit einem leeren Element ("...:") endet, wird diese Liste an den Anfang der üblichen Liste von Pfaden gesetzt. Andernfalls ersetzt die angegebene Liste die übliche Liste von Pfaden.
$SYSTEMD_PAGER, $PAGER
Der Pager, der verwendet wird, wenn --no-pager nicht angegeben ist. $SYSTEMD_PAGER wird verwendet, falls er gesetzt ist; andernfalls wird $PAGER verwendet. Wenn weder $SYSTEMD_PAGER noch $PAGER gesetzt sind, wird eine Reihe bekannter Pager-Implementierungen nacheinander ausprobiert, darunter less(1) und more(1), bis eine gefunden wird. Wenn keine Pager-Implementierung gefunden wird, wird kein Pager aufgerufen. Das Setzen dieser Umgebungsvariablen auf eine leere Zeichenkette oder den Wert "cat" entspricht der Verwendung von --no-pager.
Hinweis: Wenn $SYSTEMD_PAGERSECURE nicht gesetzt ist, können $SYSTEMD_PAGER und $PAGER nur verwendet werden, um den Pager zu deaktivieren (mit "cat" oder ""), und werden ansonsten ignoriert.
$SYSTEMD_LESS
Überschreibt die an less übergebenen Optionen (standardmäßig "FRSXMK").
Benutzer möchten möglicherweise zwei Optionen ändern:
K
Diese Option weist den Pager an, sofort nach dem Drücken von Strg+C zu beenden. Um less zu erlauben, Strg+C selbst zu verarbeiten, um zur Pager-Befehlszeile zurückzukehren, entfernen Sie diese Option.
Wenn der Wert von $SYSTEMD_LESS "K" nicht enthält und der aufgerufene Pager less ist, wird Strg+C vom ausführbaren Programm ignoriert und muss vom Pager verarbeitet werden.
X
Diese Option verhindert, dass der Pager Terminalinitialisierungs- und -deinitialisierungszeichenketten an das Terminal sendet. Sie ist standardmäßig gesetzt, damit die Befehlsausgabe auch nach dem Beenden des Pagers im Terminal sichtbar bleibt. Dies verhindert jedoch einige Pager-Funktionen, insbesondere die Möglichkeit, die Paginierung mit der Maus zu steuern.
Beachten Sie, dass das Setzen der normalen $LESS-Umgebungsvariable keinen Einfluss auf less-Aufrufe durch Systemd-Tools hat.
Siehe less(1) für weitere Informationen.
$SYSTEMD_LESSCHARSET
Überschreibt die an less übergebene Zeichenkodierung (standardmäßig "utf-8", wenn das aufrufende Terminal als UTF-8-kompatibel erkannt wird).
Beachten Sie, dass das Setzen der normalen $LESSCHARSET-Umgebungsvariable keinen Einfluss auf less-Aufrufe durch Systemd-Tools hat.
$SYSTEMD_PAGERSECURE
Übliche Pager-Befehle wie less(1) unterstützen zusätzlich zum "Paginieren", d. h. dem Durchblättern der Ausgabe, das Öffnen oder Schreiben anderer Dateien und das Ausführen beliebiger Shell-Befehle. Wenn Befehle mit erhöhten Rechten aufgerufen werden, z. B. unter sudo(8) oder pkexec(1), wird der Pager zu einer Sicherheitsgrenze. Es muss darauf geachtet werden, dass nur Programme mit streng begrenzter Funktionalität als Pager verwendet werden, und dass unbeabsichtigte interaktive Funktionen wie das Öffnen oder Erstellen neuer Dateien oder das Starten von Unterprozessen nicht zulässig sind. Der "sichere Modus" für den Pager kann wie unten beschrieben aktiviert werden, falls der Pager dies unterstützt (die meisten Pager sind nicht so geschrieben, dass dies berücksichtigt wird). Es wird empfohlen, entweder explizit den "sicheren Modus" zu aktivieren oder den Pager mit --no-pager oder PAGER=cat vollständig zu deaktivieren, wenn nicht vertrauenswürdige Benutzer Befehle mit erhöhten Rechten ausführen dürfen.
Diese Option nimmt ein boolesches Argument entgegen. Wenn sie auf „true“ gesetzt ist, wird der „sichere Modus“ des Pagers aktiviert.
Im „sicheren Modus“ wird beim Aufrufen des Pagers LESSSECURE=1 gesetzt, wodurch der Pager angewiesen wird, Befehle zu deaktivieren, die neue Dateien öffnen oder erstellen oder neue Teilprozesse starten.
Derzeit ist nur less(1) bekannt, der diese Variable versteht und den „sicheren Modus“ implementiert.
Wenn sie auf „false“ gesetzt ist, werden keine Einschränkungen für den Pager vorgenommen. Das Setzen von SYSTEMD_PAGERSECURE=0 oder das Nicht-Entfernen aus der geerbten Umgebung kann es dem Benutzer ermöglichen, beliebige Befehle auszuführen.
Wenn SYSTEMD_PAGERSECURE nicht gesetzt ist, versuchen die Systemd-Tools, automatisch zu ermitteln, ob der „sichere Modus“ aktiviert werden soll und ob der Pager dies unterstützt. Der „sichere Modus“ wird aktiviert, wenn die effektive UID nicht mit der des Besitzers der Anmeldesitzung übereinstimmt, siehe geteuid(2) und sd_pid_get_owner_uid(3), oder wenn unter sudo(8) oder ähnlichen Tools ausgeführt wird (SUDO_UID ist gesetzt [6]). In diesen Fällen wird SYSTEMD_PAGERSECURE=1 gesetzt, und Pager, die den „sicheren Modus“ nicht implementieren, werden überhaupt nicht verwendet. Beachten Sie, dass diese automatische Erkennung nur die gängigsten Mechanismen zur Privilegieneskalation abdeckt und als Komfortfunktion gedacht ist. Es wird empfohlen, SYSTEMD_PAGERSECURE explizit zu setzen oder den Pager zu deaktivieren.
Beachten Sie, dass, wenn die Variablen SYSTEMD_PAGER oder PAGER verwendet werden sollen, außer um den Pager zu deaktivieren, auch SYSTEMD_PAGERSECURE gesetzt werden muss.
^ YSTEMD_COLORS
Nimmt ein boolesches Argument entgegen. Wenn auf „true“ gesetzt, verwenden Systemd und zugehörige Dienstprogramme Farben in ihrer Ausgabe; andernfalls ist die Ausgabe monochrom. Darüber hinaus kann die Variable einen der folgenden speziellen Werte annehmen: „16“ oder „256“, um die Verwendung von Farben auf die Basis-16- oder 256-ANSI-Farben zu beschränken. Dies kann angegeben werden, um die automatische Entscheidung basierend auf TERM und der Art der Verbindung zum Terminal außer Kraft zu setzen.
^ YSTEMD_URLIFY
Der Wert muss boolesch sein. Steuert, ob in der Ausgabe klickbare Links für Terminalemulatoren, die dies unterstützen, generiert werden sollen. Dies kann angegeben werden, um die Entscheidung, die Systemd basierend auf TERM und anderen Bedingungen trifft, außer Kraft zu setzen.
^ ISTEN_PID, LISTEN_PIDFDID, LISTEN_FDS, LISTEN_FDNAMES
Von Systemd für überwachte Prozesse während der Socket-basierten Aktivierung gesetzt. Siehe sd_listen_fds(3) für weitere Informationen.
^ OTIFY_SOCKET
Von dem Service Manager für seine Dienste für Status- und Bereitschaftsbenachrichtigungen gesetzt. Wird auch vom Service Manager verwendet, um übergeordnete Container-Manager oder Service Manager über seinen Fortschritt zu informieren. Siehe sd_notify(3) und den entsprechenden Abschnitt unten für weitere Informationen.
Weitere Umgebungsvariablen, die von Systemd und seinen verschiedenen Komponenten verwendet werden, finden Sie unter Bekannte Umgebungsvariablen[7].
KERNEL-BEFEHLSZEILE
Wenn als Systeminstanz ausgeführt, analysiert Systemd eine Reihe von Optionen, die unten aufgeführt sind. Diese können als Kernel-Befehlszeilenargumente angegeben werden, die aus einer Reihe von Quellen gelesen werden, je nachdem, in welcher Umgebung Systemd ausgeführt wird. Wenn innerhalb eines Linux-Containers ausgeführt, werden diese Optionen aus den Systemd selbst übergebenen Befehlszeilenargumenten sowie aus allen Befehlszeilenoptionen gelesen, die im Abschnitt „Optionen“ oben aufgeführt sind. Wenn außerhalb von Linux-Containern ausgeführt, werden diese Argumente stattdessen aus /proc/cmdline gelesen.
Die folgenden Variablen werden verstanden:
systemd.unit=, rd.systemd.unit=
Überschreibt die beim Booten zu aktivierende Einheit. Standardmäßig ist dies default.target. Dies kann verwendet werden, um vorübergehend in eine andere Booteinheit zu booten, z. B. rescue.target oder emergency.service.
Siehe systemd.special(7) für Details zu diesen Einheiten. Die mit "rd." versehene Option gilt nur im Initrd, während die Option ohne Präfix nur im Hauptsystem gilt.
systemd.dump_core
Akzeptiert ein boolesches Argument oder aktiviert die Option, wenn sie ohne Argument angegeben wird. Wenn aktiviert, erstellt der Systemd-Manager (PID 1) beim Absturz eine Core-Datei. Andernfalls wird keine Core-Datei erstellt. Standardmäßig aktiviert.
Hinzugefügt in Version 233.
systemd.crash_chvt
Akzeptiert eine positive Ganzzahl oder ein boolesches Argument. Kann auch ohne Argument angegeben werden, was die gleiche Wirkung hat wie ein positives boolesches Argument. Wenn eine positive Ganzzahl (im Bereich von 1–63) angegeben wird, aktiviert der Systemmanager (PID 1) beim Absturz das angegebene virtuelle Terminal. Standardmäßig deaktiviert, d. h., es wird kein Wechsel versucht. Wenn auf aktiviert gesetzt, wird stattdessen das virtuelle Terminal verwendet, in das die Kernelmeldungen geschrieben werden.
Hinzugefügt in Version 233.
systemd.crash_shell
Akzeptiert ein boolesches Argument oder aktiviert die Option, wenn sie ohne Argument angegeben wird. Wenn aktiviert, startet der Systemd-Manager (PID 1) beim Absturz eine Shell. Andernfalls wird keine Shell gestartet. Standardmäßig deaktiviert, aus Sicherheitsgründen, da die Shell nicht durch eine Passwortauthentifizierung geschützt ist.
Hinzugefügt in Version 233.
systemd.crash_action=
Akzeptiert einen der Werte "freeze", "reboot" oder "poweroff". Standardmäßig ist dies "freeze". Wenn auf "freeze" gesetzt, hängt das System unbegrenzt, wenn der Systemd-Manager (PID 1) abstürzt. Wenn auf "reboot" gesetzt, startet der Systemd-Manager (PID 1) die Maschine automatisch nach einer Verzögerung von 10 Sekunden neu, wenn er abstürzt. Wenn auf "poweroff" gesetzt, schaltet der Systemd-Manager (PID 1) die Maschine sofort aus, wenn er abstürzt. Wenn in Kombination mit systemd.crash_shell verwendet, wird die konfigurierte Absturzakton ausgeführt, nachdem die Shell beendet wurde.
Hinzugefügt in Version 256.
systemd.confirm_spawn
Akzeptiert ein boolesches Argument oder einen Pfad zum virtuellen Terminal, auf dem die Bestätigungsmeldungen ausgegeben werden sollen. Kann auch ohne Argument angegeben werden, was die gleiche Wirkung hat wie ein positives boolesches Argument. Wenn aktiviert, fragt der Systemd-Manager (PID 1) beim Starten von Prozessen über /dev/console nach einer Bestätigung. Wenn ein Pfad oder ein Konsolenname (z. B. "ttyS0") angegeben wird, wird stattdessen das virtuelle Terminal verwendet, auf das dieser Pfad zeigt oder das durch den angegebenen Namen beschrieben wird.
Standardmäßig deaktiviert.
Hinzugefügt in Version 233.
systemd.service_watchdogs=
Akzeptiert ein boolesches Argument. Wenn deaktiviert, werden alle Service-Laufzeit-Watchdogs (WatchdogSec=) und Notfallaktionen (z. B. OnFailure= oder StartLimitAction=) vom Systemmanager (PID 1) ignoriert; siehe systemd.service(5). Standardmäßig ist es aktiviert, d. h. Watchdogs und Fehleraktionen werden normal verarbeitet. Der Hardware-Watchdog wird von dieser Option nicht beeinflusst.
Hinzugefügt in Version 237.
systemd.show_status
Akzeptiert ein boolesches Argument oder die Konstanten error und auto. Kann auch ohne Argument angegeben werden, was die gleiche Wirkung hat wie ein positives boolesches Argument. Wenn aktiviert, zeigt der Systemd-Manager (PID 1) während des Bootvorgangs kurze Service-Statusmeldungen auf der Konsole an. Bei error werden nur Meldungen über Fehler angezeigt, der Bootvorgang ist ansonsten ruhig. auto verhält sich wie false, bis es eine deutliche Verzögerung beim Bootvorgang gibt. Standardmäßig ist es aktiviert, es sei denn, quiet wird als Kernel-Kommandozeilenoption übergeben, in diesem Fall ist der Standardwert error. Wenn angegeben, überschreibt es die Konfigurationsdateieinstellung ShowStatus= des Systemmanagers, siehe systemd-system.conf(5).
Hinzugefügt in Version 233.
systemd.status_unit_format=
Akzeptiert name, description oder combined als Wert. Wenn name, verwendet der Systemmanager Einheitsnamen in Statusmeldungen. Wenn combined, verwendet der Systemmanager Einheitsnamen und -beschreibungen in Statusmeldungen. Wenn angegeben, überschreibt es die Konfigurationsdateieinstellung StatusUnitFormat= des Systemmanagers, siehe systemd-system.conf(5).
Hinzugefügt in Version 243.
systemd.log_color, systemd.log_level=, systemd.log_location, systemd.log_target=,
systemd.log_time, systemd.log_tid, systemd.log_ratelimit_kmsg
Steuert die Protokollausgabe, mit der gleichen Wirkung wie die oben beschriebenen Umgebungsvariablen $SYSTEMD_LOG_COLOR, $SYSTEMD_LOG_LEVEL, $SYSTEMD_LOG_LOCATION, $SYSTEMD_LOG_TARGET, $SYSTEMD_LOG_TIME, $SYSTEMD_LOG_TID und $SYSTEMD_LOG_RATELIMIT_KMSG. systemd.log_color, systemd.log_location, systemd.log_time, systemd.log_tid und systemd.log_ratelimit_kmsg können ohne Argument angegeben werden, was die gleiche Wirkung hat wie ein positives boolesches Argument.
systemd.default_standard_output=, systemd.default_standard_error=
Steuert die Standardausgabe und -fehlerausgabe für Dienste und Sockets. Steuert also den Standardwert für StandardOutput= und StandardError= (siehe systemd.exec(5) für Details). Akzeptiert einen der Werte inherit, null, tty, journal, journal+console, kmsg, kmsg+console. Wenn das Argument fehlt, setzt systemd.default-standard-output= den Standardwert auf journal und systemd.default-standard-error= auf inherit.
systemd.setenv=
Akzeptiert ein String-Argument in der Form VARIABLE=VALUE. Kann verwendet werden, um Standardumgebungsvariablen festzulegen, die für abgeleitete Kindprozesse hinzugefügt werden sollen. Kann mehr als einmal verwendet werden, um mehrere Variablen festzulegen.
systemd.machine_id=
Akzeptiert einen 32-stelligen Hexadezimalwert, der zum Festlegen der machine-id verwendet werden soll. Hauptsächlich für das Netzwerk-Booting gedacht, bei dem für jeden Bootvorgang die gleiche machine-id gewünscht wird.
In Version 229 hinzugefügt.
systemd.set_credential=, systemd.set_credential_binary=
Legt eine Systemanmeldeinformation fest, die dann mit der Einstellung ImportCredential= oder LoadCredential= an Systemdienste weitergegeben werden kann, siehe systemd.exec(5) für Details. Nimmt ein Paar aus Anmeldeinformationen und Wert entgegen, getrennt durch einen Doppelpunkt. Der Parameter systemd.set_credential= erwartet den Wert der Anmeldeinformation in Form von Klartext, der Parameter systemd.set_credential_binary= nimmt binäre Daten entgegen, die in Base64 kodiert sind. Beachten Sie, dass die Kernel-Befehlszeile typischerweise von nicht privilegierten Programmen unter /proc/cmdline aus zugänglich ist. Dieser Mechanismus ist daher nicht für die Übertragung sensibler Daten geeignet. Verwenden Sie ihn nur für nicht sensible Daten (z. B. öffentliche Schlüssel/Zertifikate und nicht private Schlüssel) oder in Test-/Debugumgebungen.
Weitere Informationen finden Sie in der Dokumentation System- und Service-Anmeldeinformationen[8].
In Version 251 hinzugefügt.
systemd.import_credentials=
Akzeptiert ein boolesches Argument. Wenn auf false gesetzt, wird das Importieren von Anmeldeinformationen aus der Kernel-Befehlszeile, der DMI/SMBIOS-OEM-Stringtabelle, dem qemu_fw_cfg-Subsystem oder dem EFI-Kernel-Stub deaktiviert.
In Version 251 hinzugefügt.
quiet
Deaktiviert die Statusausgabe beim Booten, ähnlich wie systemd.show_status=no. Beachten Sie, dass diese Option auch vom Kernel selbst gelesen wird und die Kernel-Protokollausgabe deaktiviert. Durch das Übergeben dieser Option wird die übliche Ausgabe sowohl vom Systemmanager als auch vom Kernel deaktiviert.
In Version 186 hinzugefügt.
debug
Aktiviert die Debug-Ausgabe. Dies entspricht systemd.log_level=debug. Beachten Sie, dass diese Option auch vom Kernel selbst gelesen wird und die Kernel-Debug-Ausgabe aktiviert. Durch das Übergeben dieser Option wird die Debug-Ausgabe sowohl vom Systemmanager als auch vom Kernel aktiviert.
In Version 205 hinzugefügt.
emergency, rd.emergency, -b
Bootet in den Notfallmodus. Dies entspricht systemd.unit=emergency.target oder rd.systemd.unit=emergency.target und wird aus Kompatibilitätsgründen und zur einfacheren Eingabe bereitgestellt.
In Version 186 hinzugefügt.
rescue, rd.rescue, single, s, S, 1
Bootet in den Rettungsmodus. Dies entspricht systemd.unit=rescue.target oder rd.systemd.unit=rescue.target und wird aus Kompatibilitätsgründen und zur einfacheren Eingabe bereitgestellt.
In Version 186 hinzugefügt.
2 3, 4, 5
Bootet in die angegebene Legacy-SysV-Runlevel. 2, 3 und 4 entsprechen systemd.unit=multi-user.target; und 5 entspricht systemd.unit=graphical.target und wird aus Kompatibilitätsgründen und zur einfacheren Eingabe bereitgestellt.
In Version 186 hinzugefügt.
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=
Legt die zu verwendende Systemsprache fest. Dies überschreibt die Einstellungen in /etc/locale.conf. Weitere Informationen finden Sie in locale.conf(5) und locale(7).
In Version 186 hinzugefügt.
Für andere Kernel-Befehlszeilenparameter, die von Komponenten des Core-Betriebssystems verwendet werden, siehe kernel-command-line(7).
SYSTEMANMELDUNGEN
Während der Initialisierung importiert der Service-Manager Anmeldeinformationen aus verschiedenen Quellen in das System der Anmeldeinformationen, die dann an Dienste weitergegeben und von Generatoren verwendet werden können:
Wenn der Service-Manager zum ersten Mal initialisiert wird, liest er Systemanmeldeinformationen aus den SMBIOS-Typ-11-Anbieterzeichenketten io.systemd.credential:name=value und
io.systemd.credential.binary:name=value.
Gleichzeitig werden Anmeldeinformationen aus QEMU „fw_cfg“ importiert. (Beachten Sie, dass der SMBIOS-Mechanismus im Allgemeinen bevorzugt wird, da er schneller und allgemeiner ist.)
Anmeldeinformationen können über die Kernel-Kommandozeile übergeben werden, indem der Parameter systemd.set-credential= verwendet wird, siehe oben.
Anmeldeinformationen können aus der UEFI-Umgebung über systemd-stub(7) übergeben werden.
Wenn der Service-Manager während des Übergangs von Initrd zu Host aufgerufen wird, importiert er alle
Dateien in /run/credentials/@initrd/ als Systemanmeldeinformationen.
Rufen Sie systemd-creds(1) wie folgt auf, um die Liste der an das System übergebenen Anmeldeinformationen anzuzeigen:
# systemd-creds --system list
Weitere Informationen finden Sie in der Dokumentation [8] zu System- und Serviceanmeldeinformationen.
Der Service-Manager verbraucht, wenn er als PID 1 ausgeführt wird, die folgenden Systemanmeldeinformationen:
`vmm.notify_socket`
Enthält eine AF_VSOCK- oder AF_UNIX-Adresse, an die eine READY=1-Benachrichtigungsnachricht gesendet werden soll, wenn der
Service-Manager das Booten abgeschlossen hat. Siehe sd_notify(3) und den nächsten Abschnitt für weitere
Informationen. Beachten Sie, dass, falls der Hypervisor kein SOCK_DGRAM über AF_VSOCK unterstützt, stattdessen SOCK_SEQPACKET versucht wird. Die Anmeldeinformations-Payload für AF_VSOCK sollte eine Zeichenkette in der Form „vsock:CID:PORT“ sein. „vsock-stream“, „vsock-dgram“ und „vsock-seqpacket“ können verwendet werden, um stattdessen die Verwendung des entsprechenden Socket-Typs zu erzwingen.
Dieses Feature ist nützlich für Maschinen-Manager oder andere Prozesse auf dem Host, um über VSOCK eine Benachrichtigung zu erhalten, wenn eine virtuelle Maschine das Booten abgeschlossen hat.
Hinzugefügt in Version 254.
`system.machine_id`
Nimmt eine 128-Bit-hexadezimale ID entgegen, um /etc/machine-id zu initialisieren, falls die Datei noch nicht eingerichtet ist. Siehe machine-id(5) für Details.
Hinzugefügt in Version 254.
Eine Liste der Systemanmeldeinformationen, die von verschiedenen anderen Komponenten von Systemd verwendet werden, finden Sie unter systemd.systemcredentials(7).
BEREITSCHAFTSPROTOKOLL
Der Service-Manager implementiert ein Bereitschaftsbenachrichtigungsprotokoll sowohl zwischen dem Manager und seinen
Diensten (d. h. in Richtung der darunter liegenden Schicht) als auch zwischen dem Manager und einem potenziellen Supervisor in der darüber liegenden Schicht (letzteres könnte ein Maschinen- oder Container-Manager sein oder im Fall eines Service-Managers pro Benutzer die Systeminstanz des Service-Managers). Das grundlegende Protokoll (und die vorgeschlagene API dafür) wird in sd_notify(3) beschrieben.
Die Benachrichtigungssocket, die der Service-Manager (einschließlich PID 1) zur Meldung der Bereitschaft an seinen
eigenen Supervisor verwendet, wird über die übliche Umgebungsvariable $NOTIFY_SOCKET eingestellt (siehe oben). Da dies nur für Container-Manager und für die Instanz des Service-Managers pro Benutzer direkt einstellbar ist, steht ein zusätzlicher Mechanismus zur Konfiguration zur Verfügung, insbesondere für den Einsatz in VM-Umgebungen: Die Systemanmeldeinformation vmm.notify_socket kann über SMBIOS-Typ-11-Anbieterzeichenketten auf eine geeignete Socket (typischerweise eine AF_VSOCK-Socket) gesetzt werden. Weitere Einzelheiten finden Sie oben.
Das Benachrichtigungsprotokoll vom Service-Manager nach oben zur Supervisor-Ebene unterstützt eine Reihe von Erweiterungsfeldern, die es einem Supervisor ermöglichen, bestimmte Eigenschaften des Systems zu erfahren und den Boot-Fortschritt zu verfolgen. Insbesondere werden die folgenden Felder gesendet:
Eine X_SYSTEMD_HOSTNAME=...-Nachricht wird gesendet, sobald der anfängliche Hostname des Systems bestimmt wurde. Beachten Sie, dass der Hostname während der späteren Laufzeit programmatisch erneut geändert werden kann, und (derzeit) werden in diesem Fall keine weiteren Benachrichtigungen gesendet.
Eingeführt in Version 256.
Eine X_SYSTEMD_MACHINE_ID=...-Nachricht wird gesendet, sobald die Maschinen-ID des Systems bestimmt wurde. Siehe machine-id(5) für Details.
Eingeführt in Version 256.
Eine X_SYSTEMD_SIGNALS_LEVEL=...-Nachricht wird gesendet, sobald der Service-Manager die verschiedenen UNIX-Prozesssignal-Handler installiert hat, die oben beschrieben sind. Der Wert des Feldes ist eine nicht-signierte Ganzzahl, die als Dezimalzahl formatiert ist, und gibt die unterstützte UNIX-Prozesssignal-Funktionsebene des Service-Managers an. Derzeit ist nur eine einzige Funktionsebene definiert:
X_SYSTEMD_SIGNALS_LEVEL=2 umfasst die verschiedenen UNIX-Prozesssignale, die oben dokumentiert sind – und die eine Obermenge derjenigen sind, die vom historischen SysV-Init-System unterstützt werden.
Signale, die an PID 1 gesendet werden, bevor diese Nachricht gesendet wird, werden möglicherweise nicht korrekt verarbeitet. Ein Empfänger dieser Nachrichten sollte den Wert als nicht-signierte Ganzzahl interpretieren, die die Support-Ebene angibt. Im Moment ist nur die oben genannte Ebene 2 definiert, aber später können zusätzliche Ebenen mit höheren Ganzzahlen definiert werden, die eine Obermenge des aktuell definierten Verhaltens implementieren.
Eingeführt in Version 256.
X_SYSTEMD_UNIT_ACTIVE=...- und X_SYSTEMD_UNIT_INACTIVE=...-Nachrichten werden für jede Ziel-Unit gesendet, wenn diese aktiv wird oder nicht mehr aktiv ist. Dies ist nützlich, um den Boot-Fortschritt und die Funktionalität zu verfolgen. Zum Beispiel, sobald die ssh-access.target-Unit als gestartet gemeldet wird, ist der SSH-Zugriff in der Regel verfügbar, siehe systemd.special(7) für Details.
Eingeführt in Version 256.
Eine X_SYSTEMD_SHUTDOWN=...-Nachricht wird kurz vor dem Herunterfahren des Systems gesendet. Der Wert ist eine der Zeichenketten "reboot", "halt", "poweroff", "kexec" und gibt an, welche Art von Herunterfahren ausgeführt wird.
Eingeführt in Version 256.
Eine X_SYSTEMD_REBOOT_PARAMETER=...-Nachricht wird ebenfalls kurz vor dem Herunterfahren des Systems gesendet. Ihr Wert ist das Neustart-Argument, wie es mit systemctl --reboot-argument=... konfiguriert wurde.
Eingeführt in Version 256.
Beachten Sie, dass diese Erweiterungsfelder zusätzlich zu den regulären "READY=1"- und "RELOADING=1"-Benachrichtigungen gesendet werden.
OPTIONEN
systemd wird nur sehr selten direkt aufgerufen, da es früh gestartet wird und bereits ausgeführt wird, wenn Benutzer mit ihm interagieren. Normalerweise werden Tools wie systemctl(1) verwendet, um dem Manager Befehle zu geben. Da systemd normalerweise nicht direkt aufgerufen wird, sind die unten aufgeführten Optionen hauptsächlich für Debugging- und spezielle Zwecke nützlich.
Optionen für Introspektion und Debugging
Diese Optionen werden für Tests und Introspektion verwendet, und systemd kann jederzeit mit ihnen aufgerufen werden:
--dump-configuration-items
Gibt die verstandenen Konfigurationselemente der Einheit aus. Dies erzeugt eine prägnante, aber vollständige Liste der in den Unit-Definitionsdateien verstandenen Konfigurationselemente.
--dump-bus-properties
Gibt die freigegebenen Bus-Eigenschaften aus. Dies erzeugt eine prägnante, aber vollständige Liste der Eigenschaften, die über D-Bus freigegeben werden.
Hinzugefügt in Version 239.
--test
Ermittelt die anfängliche Starttransaktion (d. h. die Liste der beim Start gestarteten Jobs), gibt diese aus und beendet das Programm – ohne die ermittelten Jobs tatsächlich auszuführen. Diese Option ist nur für Debugging-Zwecke nützlich. Beachten Sie, dass während des regulären Starts des Service Managers zusätzliche Units gestartet werden können, die von dieser Operation nicht angezeigt werden, da Hardware-, Socket-, Bus- oder andere Arten von Aktivierungen während der Ausführung der Transaktion zusätzliche Jobs hinzufügen können. Verwenden Sie --system, um die anfängliche Transaktion des System-Service-Managers anzufordern (dies ist auch die implizite Standardeinstellung), und kombinieren Sie dies mit --user, um die anfängliche Transaktion des Service-Managers für einen bestimmten Benutzer anzufordern.
--system, --user
Wenn sie in Verbindung mit --test verwendet werden, wird ausgewählt, ob die anfängliche Transaktion für die Systeminstanz oder für eine Instanz pro Benutzer berechnet werden soll. Diese Optionen haben keine Auswirkungen, wenn sie ohne --test aufgerufen werden, da der Service Manager bei regulären (d. h. nicht --test-) Aufrufen automatisch erkennt, ob er im System- oder im Modus pro Benutzer arbeiten soll, indem er überprüft, ob die PID, mit der er ausgeführt wird, 1 ist oder nicht. Beachten Sie, dass es nicht unterstützt wird, ein System mit dem Service Manager im --system-Modus, aber mit einer anderen PID als 1, zu booten und zu betreiben.
-h, --help
Gibt einen kurzen Hilfetext aus und beendet das Programm.
--version
Gibt eine kurze Versionszeichenfolge aus und beendet das Programm.
Optionen, die die Kernel-Befehlszeileneinstellungen duplizieren
Diese Optionen entsprechen direkt den oben in "Kernel-Befehlszeile" aufgeführten Optionen. Beide Formen können für den System-Manager gleichwertig verwendet werden, aber es wird empfohlen, die in diesem Kontext aufgeführten Formen zu verwenden, da diese ordnungsgemäß benannt sind. Wenn eine Option sowohl in der Kernel-Befehlszeile als auch als normales Befehlszeilenargument angegeben wird, hat letztere Vorrang.
Wenn systemd als Benutzer-Manager verwendet wird, wird die Kernel-Befehlszeile ignoriert und nur die unten beschriebenen Optionen werden unterstützt. In der Regel wird systemd jedoch in diesem Modus über den Dienst [email protected](5) gestartet, der allen Benutzern gemeinsam ist. Es kann bequemer sein, Konfigurationsdateien zu verwenden, um Einstellungen zu ändern (siehe systemd-user.conf(5)) oder Umgebungsvariablen. Siehe den Abschnitt "Umgebung" oben, um eine Diskussion darüber, wie der Umgebungspuffer festgelegt wird.
--unit=
Setze die Standardeinheit, die beim Start aktiviert werden soll. Wenn nicht angegeben, wird standardmäßig `default.target` verwendet. Siehe
`systemd.unit=` oben.
--dump-core
Aktiviere die Erstellung von Core-Dumps bei einem Absturz. Diese Option hat keine Auswirkungen, wenn systemd als Benutzerinstanz ausgeführt wird. Entspricht `systemd.dump_core=` oben.
--crash-vt=VT
Wechsle bei einem Absturz zu einer bestimmten virtuellen Konsole (VT). Diese Option hat keine Auswirkungen, wenn systemd als Benutzerinstanz ausgeführt wird. Entspricht `systemd.crash_chvt=` oben (aber nicht in der Schreibweise!).
Hinzugefügt in Version 227.
--crash-shell
Starte eine Shell bei einem Absturz. Diese Option hat keine Auswirkungen, wenn systemd als Benutzerinstanz ausgeführt wird. Siehe
`systemd.crash_shell=` oben.
--crash-action=
Gib an, was bei einem Absturz des Systemmanagers (PID 1) geschehen soll. Diese Option hat keine Auswirkungen, wenn systemd als Benutzerinstanz ausgeführt wird. Siehe `systemd.crash_action=` oben.
Hinzugefügt in Version 256.
--confirm-spawn
Fordere eine Bestätigung an, wenn Prozesse gestartet werden. Diese Option hat keine Auswirkungen, wenn systemd als Benutzerinstanz ausgeführt wird. Siehe `systemd.confirm_spawn` oben.
--show-status
Zeige während des Boot- und Shutdown-Prozesses kurze Statusinformationen der Einheit auf der Konsole an. Siehe
`systemd.show_status` oben.
Hinzugefügt in Version 244.
--log-color
Hebe wichtige Log-Nachrichten hervor. Siehe `systemd.log_color` oben.
Hinzugefügt in Version 244.
--log-level=
Setze die Log-Level. Siehe `systemd.log_level` oben.
--log-location
Füge den Code-Speicherort in die Log-Nachrichten ein. Siehe `systemd.log_location` oben.
Hinzugefügt in Version 244.
--log-target=
Setze das Log-Ziel. Siehe `systemd.log_target` oben.
--log-time=
Füge der Konsole einen Zeitstempel vor den Nachrichten hinzu. Siehe `systemd.log_time` oben.
Hinzugefügt in Version 246.
--machine-id=
Überschreibe die auf der Festplatte gespeicherte Machine-ID. Siehe `systemd.machine_id=` oben.
Hinzugefügt in Version 229.
--service-watchdogs
Aktiviere oder deaktiviere global alle Service-Watchdog-Timeouts und Notfallaktionen. Siehe
`systemd.service_watchdogs` oben.
Hinzugefügt in Version 237.
--default-standard-output=, --default-standard-error=
Setzt die Standardausgabe bzw. die Standardfehlerausgabe für alle Dienste und Sockets. Siehe
`systemd.default_standard_output=` und `systemd.default_standard_error=` oben.
SYSTEM CLOCK EPOCH
Wenn systemd gestartet oder neu gestartet wird, kann es die Systemuhr auf die "Epoche" setzen. Dieser Mechanismus wird verwendet, um sicherzustellen, dass die Systemuhr über Neustarts hinweg einigermaßen stabil und ungefähr monoton bleibt, falls keine batteriegesicherte lokale RTC vorhanden ist oder diese nicht korrekt funktioniert.
Die Epoche ist das früheste Datum, ab dem davon ausgegangen wird, dass die Zeit der Systemuhr korrekt gesetzt ist. Beim Initialisieren wird die lokale Uhr auf die Epoche vorwärts bewegt, falls sie auf einen früheren Wert gesetzt wurde. Als Sonderfall wird, falls die lokale Uhr ausreichend weit in der Zukunft liegt (standardmäßig 15 Jahre, dies kann jedoch zur Build-Zeit konfiguriert werden), davon ausgegangen, dass die Hardware-Uhr defekt ist, und die Systemuhr wird auf die Epoche zurückgesetzt.
Die Epoche wird auf den höchsten Wert der folgenden Werte gesetzt: die Build-Zeit von systemd, die Änderungszeit ("mtime") von /usr/lib/clock-epoch und die Änderungszeit von /var/lib/systemd/timesync/clock.
DATEIEN
/run/systemd/notify
Socket für die Benachrichtigung über den Daemon-Status. Dies ist ein AF_UNIX-Datagramm-Socket und wird verwendet, um die Daemon-Benachrichtigungslogik zu implementieren, wie sie in sd_notify(3) implementiert ist.
/run/systemd/private
Wird intern als Kommunikationskanal zwischen systemctl(1) und dem systemd-Prozess verwendet. Dies ist ein AF_UNIX-Stream-Socket. Diese Schnittstelle ist systemd-spezifisch und sollte nicht in externen Projekten verwendet werden.
/usr/lib/clock-epoch
Die Änderungszeit ("mtime") dieser Datei wird für die Zeit-Epoche verwendet, siehe vorheriger Abschnitt.
Hinzugefügt in Version 247.
/var/lib/systemd/timesync/clock
Die Änderungszeit ("mtime") dieser Datei wird von systemd-timesyncd.service(8) aktualisiert. Wenn vorhanden, wird die Änderungszeit der Datei für die Epoche verwendet, siehe vorheriger Abschnitt.
Hinzugefügt in Version 257.
HISTORIE
systemd 252
Die Kernel-Befehlszeilenargumente systemd.unified_cgroup_hierarchy und systemd.legacy_systemd_cgroup_controller wurden als veraltet markiert. Bitte wechseln Sie zur einheitlichen Cgroup-Hierarchie.
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), org.freedesktop.systemd1(5)
Weitere Informationen über die Konzepte und Ideen hinter systemd finden Sie im Original Design-Dokument[10].
HINWEISE
Schnittstellen-Portabilität und Stabilitätsversprechen
https://systemd.io/PORTABILITY_AND_STABILITY/
Container-Schnittstelle
https://systemd.io/CONTAINER_INTERFACE
initrd-Schnittstelle
https://systemd.io/INITRD_INTERFACE/
Control Groups v2
https://docs.kernel.org/admin-guide/cgroup-v2.html
XDG-Basisverzeichnis-Spezifikation
https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
Es wird empfohlen, dass andere Tools $SUDO_UID bei Bedarf setzen und überprüfen, um es als
gemeinsame Schnittstelle zu behandeln.
Bekannte Umgebungsvariablen
https://systemd.io/ENVIRONMENT
System- und Dienst-Anmeldeinformationen
https://systemd.io/CREDENTIALS
systemd-Homepage
https://systemd.io/
Originales Design-Dokument
https://0pointer.de/blog/projects/systemd.html