Man page - systemd(1)

Packages contas this manual

Available languages:

en fr zh_TW zh_CN de

Manual

SYSTEMD(1) systemd SYSTEMD(1)

systemd, init - Systemd-System und Diensteverwalter

ÜBERSICHT

/usr/lib/systemd/systemd [OPTIONEN…]

init [OPTIONEN…] {BEFEHL}

Systemd ist ein System- und Diensteverwalter für das Linux-Betriebssystem. Wird es beim Systemstart als erster Prozess (als PID 1) ausgeführt, agiert es als Init-System, das das System hochfährt und 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.

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/, /proc/ und /dev/, ein und hängt sie ein.

systemd wird während der frühen Systemstartphase auch die Uhr zurücksetzen, falls sie anscheinend falls gesetzt ist. Siehe den nachfolgenden Abschnitt »Systemuhr-Epoch«.

Beachten Sie, dass einige, aber nicht alle, durch Systemd bereitgestellte Schnittstellen von der Schnittstellenportierungs und -stabilitätszusage[1] abgedeckt sind.

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[2] bzw. initrd-Schnittstelle[3] implementieren.

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 in einer Reihe von Zuständen sein, die in der nachfolgenden Tabelle beschrieben sind. Beachten Sie, dass die verschiedenen Unit-Typen eine Reihe von zusätzlichen Unterzuständen haben können, die auf die hier beschriebenen generalisierten Unit-Zustände abgebildet werden.

Tabelle 1. Unit-AKTIVITÄTS-Zustände

Zustand Beschreibung
active Gestartet, gebunden, eingesteckt … abhängig vom Unit-Typ.
inactive Gestoppt, losgelöst, ausgesteckt … abhängig vom Unit-Typ.
failed Ähnlich zu inactive, aber die Unit schlug irgendwie fehl (Prozess lieferte beim Exit einen Fehler-Code, stürzte ab, eine Aktion ist in eine Zeitüberschreitung gelaufen oder nach zu vielen Neustarts).
activating Änderung von inactive auf active.
deactivating Änderung von active auf inactive.
maintenance Unit ist inactive und eine Wartungsaktion läuft derzeit.
reloading Unit ist active und sie lädt ihre Konfiguration neu.
refreshing Unit ist active und es wird eine neue Einhängung in ihrem Namensraum aktiviert.

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[4] 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.

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

System-Unit-Verzeichnisse

Der Systemd-Systemverwalter liest Unit-Konfigurationen aus verschiedenen Verzeichnissen. Pakete, die Unit-Dateien installieren möchten, sollten sie in dem durch pkg-config systemd --variable=systemdsystemunitdir zurückgelieferten Verzeichnis ablegen. Weitere geprüfte Verzeichnisse sind /usr/local/lib/systemd/system und /usr/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[5] 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.

Der Dienste wartet auf die Signale verschiedener UNIX-Prozesse, die dazu verwandt werden können, verschiedene Aktionen asynchron zu erbitten. Die Signal-Handhabung wird sehr früh im Systemstart aktiviert, bevor irgendwelche Prozesse aufgerufen werden. Allerdings muss ein überwachender Container-Verwalter oder ähnliches, der plant, diese Aktionen mittels dieses Mechanismus zu erbitten, berücksichtigen, dass diese Funktionalität nicht während der allerfrühsten Initialisierungsphase verfügbar ist. Wie nachfolgend beschrieben wird wird eine sd_notify(3)-Nachricht ausgesandt, die das Feld X_SYSTEMD_SIGNALS_LEVEL=2 enthält, sobald die Signalhandhaber aktiviert sind. Dies kann dazu verwandt werden, die Einreichung dieser Signale korrekt einzuplanen.

SIGTERM

Nach Empfang dieses Signals serialisiert der Systemd-Systemverwalter seinen Zustand, führt sich selbst erneut aus und deseriealisiert den gespeicherten Zustand wieder. Dies ist größtenteils äquivalent zu systemctl daemon-reexec.

Systemd-Benutzerverwalter werden die Unit exit.target starten, wenn dieses Signal empfangen wird. Dies ist größtenteils äquivalent zu systemctl --user start exit.target --job-mode=replace-irreversibly.

SIGINT

Nach Empfang dieses Signals wird der Systemverwalter die Unit ctrl-alt-del.target starten. Dies ist größtenteils äquivalent zu systemctl start ctrl-alt-del.target --job-mode=replace-irreversibly. Falls dieses Signal mehr als sieben Mal in zwei Sekunden empfangen wird, wird ein sofortiger Systemneustart ausgelöst. Beachten Sie, dass Drücken von Strg+Alt+Entf auf der Konsole dieses Signal auslösen wird. Hängt daher ein Neustart, ist das siebenmalige Drücken von Strg+Alt+Entf in zwei Sekunden eine relativ sichere Art, einen sofortigen Neustart auszulösen.

Systemd-Benutzerverwalter behandeln dieses Signal auf die gleiche Art wie SIGTERM.

SIGWINCH

Wenn dieses Signal empfangen wird, startet der Systemd-Systemverwalter die Unit kbrequest.target. Dies ist größtenteils äquivalent zu systemctl start kbrequest.target.

Dieses Signal wird von Systemd-Benutzerverwaltern ignoriert.

SIGPWR

Wenn dieses Signal empfangen wird, startet der Systemd-Systemverwalter die Unit sigpwr.target. Dies ist größtenteils äquivalent zu systemctl start sigpwr.target.

SIGUSR1

Wenn dieses Signal empfangen wird, versucht der Systemd-Systemverwalter, sich erneut mit dem D-Bus-Bus zu verbinden.

SIGUSR2

Wenn dieses Signal empfangen wird, protokolliert der Systemd-Systemverwalter seinen kompletten Zustand in menschenlesbarer Form. Die protokollierten Daten sind identisch zu den von systemd-analyze dump ausgegebenen.

SIGHUP

Lädt die komplette Daemon-Konfiguration neu. Dies ist größtenteils äquivalent zu systemctl daemon-reload.

SIGRTMIN+0

Betritt den Standardmodus, startet die Unit default.target. Dies ist größtenteils äquivalent zu systemctl isolate default.target.

SIGRTMIN+1

Betritt den Rettungsmodus, startet die Unit rescue.target. Dies ist größtenteils äquivalent zu systemctl isolate rescue.target.

SIGRTMIN+2

Betritt den Notfallmodus, startet die Unit emergency.service. Dies ist größtenteils äquivalent zu systemctl isolate emergency.service.

SIGRTMIN+3

Hält die Maschine an, startet die Unit halt.target. Dies ist größtenteils äquivalent zu systemctl start halt.target --job-mode=replace-irreversibly.

SIGRTMIN+4

Schaltet die Maschine aus, startet die Unit poweroff.target. Dies ist größtenteils äquivalent zu systemctl start poweroff.target --job-mode=replace-irreversibly.

SIGRTMIN+5

Startet die Maschine neu, startet die Unit reboot.target. Dies ist größtenteils äquivalent zu systemctl start reboot.target --job-mode=replace-irreversibly.

SIGRTMIN+6

Startet die Maschine mittels kexec neu, startet die Unit kexec.target. Dies ist größtenteils äquivalent zu systemctl start kexec.target --job-mode=replace-irreversibly.

SIGRTMIN+7

Startet den Benutzerraum neu, startet die Unit soft-reboot.target. Dies ist größtenteils äquivalent zu 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 Benutzerraum sofort neu.

Hinzugefügt in Version 254.

SIGRTMIN+20

Aktiviert die Anzeige von Statusmeldungen auf der Konsole, wie dies mit systemd.show_status=1 auf der Kernelbefehlszeile gesteuert wird.

Um Ressourcenwettlauf-Bedingungen zu vermeiden, sollten Sie SetShowStatus() anstelle von SIGRTMIN+20 verwenden. Siehe org.freedesktop.systemd1(5).

SIGRTMIN+21

Deaktiviert die Anzeige von Statusmeldungen auf der Konsole, wie dies mit systemd.show_status=0 auf der Kernelbefehlszeile gesteuert wird.

Um Ressourcenwettlauf-Bedingungen zu vermeiden, sollten Sie SetShowStatus() anstelle von SIGRTMIN+21 verwenden. Siehe org.freedesktop.systemd1(5).

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.

Hinzugefügt in Version 239.

SIGRTMIN+24

Verlässt den Verwalter sofort (nur für --user-Instanzen verfügbar).

Hinzugefügt in Version 195.

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.

Hinzugefügt in Version 250.

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.

Hinzugefügt in Version 239.

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.

Hinzugefügt in Version 239.

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 user@.service. Mittels der Einstellungen Environment= und EnvironmentFile= für user@.service 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_LEVEL

Die maximale Protokollierstufe für ausgegebene Meldungen (Meldungen mit einer höheren Protokollierstufe, d.h. weniger wichtige, werden unterdrückt). Akzeptiert eine Kommata-getrennte Liste von Werten. Ein Wert kann einer der folgenden sein (in Reihenfolge absteigender Bedeutung): emerg, alert, crit, err, warning, notice, info, debug oder eine Ganzzahl im Bereich 0…7. Siehe syslog(3) für weitere Informationen. Jedem Wert kann optional eine Zeichenkette aus console, syslog, kmsg oder journal gefolgt von einem Doppelpunkt vorangestellt werden, um die maximale Protokollierstufe für dieses spezielle Protokollierziel zu setzen (d.h. SYSTEMD_LOG_LEVEL=debug,console:info legt fest, dass auf der Stufe »debug« protokolliert werden soll, außer beim Protokollieren auf die Konsole, die auf Stufe »info« erfolgen soll). Beachten Sie, dass die globale maximale Protokollierstufe Priorität gegenüber jeder zielbezogenen maximalen Protokollierstufe hat.

Dies kann mit --log-level= außer Kraft gesetzt werden.

$SYSTEMD_LOG_COLOR

Ein logischer Wert. Falls true, 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 true, wird den Protokollnachrichten der Konsole ein Zeitstempel vorangestellt.

Dies kann mit --log-time= außer Kraft gesetzt werden.

Hinzugefügt in Version 246.

$SYSTEMD_LOG_LOCATION

Ein logischer Wert. Falls true, wird den Protokollnachrichten ein Dateiname 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 true, wird den Nachrichten die aktuelle numerische Thread-Kennung (TID) vorangestellt.

Hinzugefügt in Version 247.

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

$SYSTEMD_LOG_RATELIMIT_KMSG

Ob Kmsg ratenlimitiert werden soll oder nicht. Akzeptiert einen logischen Wert. Standardmäßig »true«. Falls deaktiviert, wird Systemd die nach Kmsg geschriebenen Meldungen nicht ratenlimitieren.

Hinzugefügt in Version 254.

$XDG_CONFIG_HOME, $XDG_CONFIG_DIRS, $XDG_DATA_HOME, $XDG_DATA_DIRS

Der Systemd-Benutzerverwalter verwendet diese Variablen in Übereinstimmung mit der XDG-Basisverzeichnisspezifikation[5], 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, $PAGER

Zu verwendendes Textanzeigeprogramm, wenn --no-pager nicht angegeben ist. Falls gesetzt, wird $SYSTEMD_PAGER verwandt, andernfalls $PAGER. setzt $PAGER außer Kraft. Falls weder $SYSTEMD_PAGER noch $PAGER gesetzt sind, wird eine Reihe wohlbekannter Implementierungen von Textanzeigeprogrammen der Reihe nach ausprobiert, einschließlich less(1) und more(1), bis eines gefunden wird. Falls keine Implementierung eines Textanzeigeprogramms gefunden wird, wird keines aufgerufen. Setzen dieser Umgebungsvariablen auf die leere Zeichenkette oder den Wert »cat« ist äquivalent zur Übergabe von --no-pager.

Beachten Sie: Falls $SYSTEMD_PAGERSECURE nicht gesetzt ist, können $SYSTEMD_PAGER und $PAGER nur zum Deaktivieren des Seitenanzeigeprogramms (mit »cat« oder »«) verwandt werden und werden ansonsten ignoriert.

$SYSTEMD_LESS

Setzt die an less übergebenen Optionen (standardmäßig »FRSXMK«) außer Kraft.

Benutzer könnten insbesondere zwei Optionen ändern wollen:

K

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.

Beachten Sie, dass das Setzen der regulären Umgebungsvariablen $LESS keine Auswirkungen auf die Ausführung von less(1) durch systemd(1)-Werkzeuge hat.

Siehe less(1) für weitere Ausführungen.

$SYSTEMD_LESSCHARSET

Setzt den an less zu übergebenden Zeichensatz (standardmäßig »utf-8«, falls das aufrufende Terminal als UTF-8-kompatibel erkannt wurde) außer Kraft.

Beachten Sie, dass das Setzen der regulären Umgebungsvariablen $LESSCHARSET keine Auswirkungen auf die Ausführungen von less(1) durch systemd(1)-Werkzeuge hat.

$SYSTEMD_PAGERSECURE

Typische Seitenanzeigeprogramme wie less(1) unterstützen nebem dem seitenweisen Anzeigen (d.h. dem Durchlaufen der Ausgabe) das Öffnen von oder Schreiben in andere Dateien und die Ausführung von beliebigen Shell-Befehlen. Werden Befehle mit erhöhten Berechtigungen, beispielsweise unter sudo(8) oder pkexec(1), aufgerufen, wird das Seitenanzeigeprogramm zur Sicherheitsgrenze. Es muss darauf geachtet werden, dass nur Programme mit streng begrenzter Funktionalität als Seitenanzeigeprogramm verwandt werden und unerwünschte interaktive Funktionalitäten wie das Öffnen oder Erstellen von neuen Dateien oder das Starten von Subprozessen nicht erlaubt sind. Der »Sichere Modus« für das Seitenanzeigeprogramm kann wie nachfolgend beschrieben aktiviert werden, falls das Seitenanzeigeprogramm dies unterstützt (die meisten Seitenanzeigeprogramme sind nicht so geschrieben, dass sie dies berücksichtigen). Es wird empfohlen, den »Sicheren Modus« explizit zu aktivieren oder das Seitenanzeigeprogramm komplett mittels --no-pager oder PAGER=cat zu deaktivieren, wenn nicht vertrauenswürdigen Benutzern die Ausführung von Programmen mit erhöhten Privilegien erlaubt wird.

Diese Option akzeptiert ein logisches Argument. Ist es auf »true« gesetzt, wird der »Sichere Modus« des Seitenanzeigeprogramms aktiviert. Im »Sicheren Modus« wird LESSSECURE=1 beim Aufruf des Seitenanzeigeprogramms gesetzt. Dies weist das Seiteanzeigeprogramm an, Befehle zum Öffnen oder Erstellen von neuen Dateien sowie das Starten von Subprozessen zu deaktivieren. Derzeit ist nur von less(1) bekannt, dass es diese Variable versteht und den »Sicheren Modus« implementiert.

Ist diese Variable auf »false« gesetzt, unterliegt das Seitenanzeigeprogramm keinen Beschränkungen. Setzen auf SYSTEMD_PAGERSECURE=0 oder das Beibehalten der Variable von der geerbten Umgebung könnte den Benutzern die Ausführung beliebiger Befehle erlauben.

Ist $SYSTEMD_PAGERSECURE nicht gesetzt, versuchen die Systemd-Werkzeuge automatisch herauszufinden, ob der »Sicheren Modus« aktiviert werden soll und ob das Seitenanzeigeprogramm dies unterstützt. Der »Sichere Modus« wird aktiviert, falls die effektive UID nicht mit der UID des Eigentümers der Anmeldesitzung übereinstimmt, siehe geteuid(2) und sd_pid_get_owner_uid(3), oder wenn die Ausführung unter Werkzeugen wie sudo(8) oder ähnlichem erfolgt ($SUDO_UID ist gesetzt [6]). In diesen Fällen wird SYSTEMD_PAGERSECURE=1 gesetzt und Seitenanzeigeprogramme, von denen nicht bekannt ist, dass sie den »Sicheren Modus« unterstützen, werden überhaupt nicht verwandt. Beachten Sie, dass diese automatische Erkennung nur die typischsten Mechanismen zur Erlangung von Privilegien abdeckt und dem Komfort dient. Es wird empfohlen, explizit $SYSTEMD_PAGERSECURE zu setzen oder das Seitenanzeigeprogramm zu deaktivieren.

Beachten Sie, dass auch $SYSTEMD_PAGERSECURE gesetzt sein muss, damit die Variablen $SYSTEMD_PAGER oder $PAGER (außer zum Deaktivieren des Seitenanzeigeprogramms) berücksichtigt werden.

$SYSTEMD_COLORS

Akzeptiert ein logisches Argument. Wenn true, 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 den Diensteverwalter für seine Dienste für die Status- und Bereitschaftsbenachrichtigungen gesetzt. Wird auch vom Diensteverwalter zur Benachrichtigungen von überwachenden Container-Verwaltern oder übergeordneten Dienstervewaltern über seine eigenen Fortschritt konsumiert. Siehe sd_notify(3) und den relevanten nachfolgenden Abschnitt für weitere Informationen.

Für weitere Umgebungsvariablen, die von Systemd und seinen verschiedenen Komponenten verstanden werden, siehe Bekannte Umgebungsvariablen[7].

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.

Hinweis: Die Verwendung von »SystemdOptions« wird missbilligt.

Die folgenden Variablen werden verstanden:

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.

Hinzugefügt in Version 233.

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.

Hinzugefügt in Version 233.

systemd.crash_shell

Akzeptiert ein logisches Argument oder aktiviert die Option, falls ohne Argument angegeben. Falls aktiviert, wird der Systemverwalter (PID 1) 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.

Hinzugefügt in Version 233.

systemd.crash_action=

Akzeptiert entweder »freeze«, »reboot« oder »poweroff«. Standardmäßig »freeze«. Falls auf »freeze« gesetzt, wird das System auf unbestimmte Zeit hängen, wenn der Systemverwalter (PID 1) abstürzt. Falls auf »reboot« gesetzt, wird der Systemverwalter (PID 1) die Maschine automatisch nach einer Verzögerung von 10 Sekunden neu starten, wenn er abstürzt. Falls auf »poweroff« gesetzt, wird der Systemverwalter (PID 1) die Maschine ausschalten, wenn er abstürzt. Falls mit systemd.crash_shell kombiniert, wird die konfigurierte Absturzaktion ausgeführt, nachdem die Shell sich beendet.

Hinzugefügt in Version 256.

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.

Hinzugefügt in Version 233.

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.

Hinzugefügt in Version 237.

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

Hinzugefügt in Version 233.

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

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 dem gleichen Effekt 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 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.

Hinzugefügt in Version 229.

systemd.set_credential=, systemd.set_credential_binary=

Setzt eine Systemzugangsberechtigung, die mittels der Einstellung ImportCredential= oder LoadCredential= an Systemdienste weitergeleitet werden kann, siehe systemd.exec(5) für Details. Akzeptiert ein Paar bestehend aus Zugangsberechtigung und -namen, getrennt durch Doppelpunkt. Der Parameter systemd.set_credential= erwartet den Zugangsberechtigungswert in wörtlicher Textform, der Parameter systemd.set_credential_binary= akzeptiert als Base64 kodierte Binärdaten. 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.

Hinzugefügt in Version 251.

systemd.import_credentials=

Akzeptiert ein logisches Argument. Falls false, 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.

Hinzugefügt in Version 251.

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.

Hinzugefügt in Version 186.

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.

Hinzugefügt in Version 205.

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.

Hinzugefügt in Version 186.

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.

Hinzugefügt in Version 186.

2, 3, 4, 5

Systemstart in den angegebenen veralteten SysV-Runlevel. 2, 3 und 4 sind zu systemd.unit=multi-user.target äquivalent und 5 ist zu systemd.unit=graphical.target äquivalent und sie werden aus Kompatibilitätsgründen und da es leichter zu tippen ist, bereitgestellt.

Hinzugefügt in Version 186.

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

Hinzugefügt in Version 186.

Für weitere von Komponenten des Kernbetriebssystems verstandene Kernelbefehlszeilenparameter siehe kernel-command-line(7).

Während der Initialisierung wird der Diensteverwalter Zugangsberechtigungen aus verschiedenen Stellen in den Satz der Zugangsberechtigungen des Systems importieren. Dies kann dann an Dienste weitergeleitet und von Generatoren verwandt werden:

•Wenn sich der Diensteverwalter erstmals initialisiert, wird er die Systemzugangsberechtigungen aus SMBIOS-Typ-11-Lieferantenzeichenketten io.systemd.credential:Name=Wert und io.systemd.credential.binary:Name=Wert lesen.

•Gleichzeitig wird er Zugangsberechtigungen von QEMUs »fw_cfg« importieren. (Beachten Sie, dass der SMBIOS-Mechanismus im Allgemeinen bevorzugt wird, da er scheller und generisch ist.)

•Zugangsberechtigungen können wie oben beschrieben über die Kernelbefehlszeile mittels des Parameters systemd.set-credential= übergeben werden.

•Zugangsberechtigungen können von der UEFI-Umgebung mittels systemd-stub(7) übergeben werden.

•Wenn der Diensteverwalter während des Übergangs Initrd → Hauptsystem aufgerufen wird, wird er alle Dateien in /run/credentials/@initrd/ als Systemzugangsberechtigungen importieren.

Rufen Sie systemd-creds(1) wie folgt auf, um eine Liste der an das System übergebenen Zugangsberechtigungen zu sehen:

# systemd-creds --system list

Siehe die Dokumentation der System- und Dienste-Zugangsberechtigungen[8] für weitere Details.

Wenn der Diensteverwalter als PID 1 ausgeführt wird, verwendet er die folgenden Systemzugangsberechtigungen:

vmm.notify_socket

Enthält eine AF_VSOCK- oder AF_UNIX-Adresse, an die eine Benachrichtigungsmeldung READY=1 gesandt werden soll, wenn das System den Start abgeschlossen hat. Siehe sd_notify(3) und den nächsten Abschnitt für weitere Informationen. Beachten Sie, dass im Falle von Hypervisoren, die SOCK_DGRAM über AF_VSOCK nicht unterstützen stattdessen SOCK_SEQPACKET versucht wird. Der Inhalt der Zugangsberechtigung für AF_VSOCK sollte eine Zeichenkette in der Form »vsock:CID:PORT« sein. »vsock-stream«, »vsock-dgram« und »vsock-seqpacket« können anstelle von »vsock« verwandt werden, um den entsprechenden Socket-Typ zu erzwingen.

Diese Funktionalität ist für Maschinenverwalter oder andere Prozesse auf dem Rechner nützlich, um eine Benachrichtigung über VSOCK zu erhalten, wenn eine virtuelle Maschine mit dem Starten fertig ist.

Hinzugefügt in Version 254.

system.machine_id

Akzeptiert eine hexadezimale 128-bit Kennung, aus der /etc/machine-id initialisiert wird, falls die Datei noch nicht eingerichtet ist. Siehe machine-id(5) zu Details.

Hinzugefügt in Version 254.

Eine Liste von Systemzugangsberechtigungen, die verschiedene andere Komponenten von Systemd konsumieren, finden Sie in systemd.system-credentials(7).

Der Diensteverwalter implementiert ein Bereitschafts-Benachrichtigungsprotokoll, sowohl zwischen dem Verwalter und seinen Diensten (d. zu den nachgeordneten Teilen) als auch zwischen dem Verwalter und einem möglichen übergeordneten Überwacher (letzerer könnte ein Maschinen- oder Container-Verwalter sein, oder im Falle eines benutzerbezogenen Diensteverwalters die Instanz des System-Diensteverwalters). Das grundlegende Protokoll (und die dafür vorgeschlagene API) sind in sd_notify(3) beschrieben.

Das vom Diensteverwalter (einschließlich PID 1) für die Meldung der Bereitschaft an seinen eigenen Supervisor verwandte Benachrichtigungs-Socket wird mittels der Umgebungsvariablen $NOTIFY_SOCKET gesetzt (siehe oben). Da diese nur für Container-Verwalter und für die benutzerbezogene Instanz des Diensteverwalters setzbar ist, ist ein zusätzlicher Mechanismus zur Konfiguration davon verfügbar, der insbesondere für VM-Umgebungen gedacht ist: Die Systemzugangsberechtigung vmm.notify_socket (siehe oben) kann mittels SMBIOS-Type-11-Lieferantenzeichenketten auf ein geeignetes Socket (typischerweise der Art AF_VSOCK) gesetzt werden. Details hierzu finden Sie weiter oben.

Das Benachrichtigungsprotokoll vom Diensteverwalter zu übergeordneten Supervisoren unterstützt eine Reihe von Erweiterungsfeldern, die es einem Supervisor ermöglichen, Informationen über bestimmte Eigenschaften des Systems zu erlangen und dessen Systemstartvorgang nachzuverfolgen. Konkret werden die folgenden Felder gesandt:

•Eine Meldung X_SYSTEMD_HOSTNAME=\[u2026] wird ausgesandt, sobald der anfängliche Rechnername für das System bestimmt wurde. Beachten Sie, dass während der weiteren Laufzeit der Rechnername programatisch geändert werden kann und (derzeit) in diesem Fall keine weiteren Benachrichtigungen ausgesandt werden.

Hinzugefügt in Version 256.

•Eine Meldung X_SYSTEMD_MACHINE_ID=… wird ausgesandt, sobald die Maschinenkennung des Systems bestimmt wurde. Siehe machine-id(5) zu Details.

Hinzugefügt in Version 256.

•Eine Meldung X_SYSTEMD_SIGNALS_LEVEL=… wird ausgesandt, sobald der Diensteverwalter die oben beschriebenen verschiedenen UNIX-Prozesssignalhandhaber installiert hat. Der Wert des Feldes ist eine vorzeichenlose Ganzzahl, formatiert als dezimale Zeichenkette. Er zeigt die unterstützte UNIX-Prozesssignal-Funktionalitätsstufe des Diensteverwalters an. Derzeit ist nur eine einzelne Funktionalitätsstufe definiert:

•X_SYSTEMD_SIGNALS_LEVEL=2 deckt die oben beschriebenen verschiedenen UNIX-Prozesssignale ab. Diese sind eine Obermenge der durch das historische SysV-Init-System unterstützten Signale

Signale, die an PID 1 vor dieser Meldung gesandt werden, könnten nicht korrekt behandelt werden. Ein Konsument dieser Meldungen sollte die Werte als eine vorzeichenfrei Ganzzahl auswerten, die die Unterstützungsstufe anzeigt. Aktuell ist nur die erwähnte Stufe 2 definiert, aber später könnten zusätzliche Stufen mit größeren Ganzzahlen definiert werden, die eine Obermenge des aktuell definierten Verhaltens implementieren.

Hinzugefügt in Version 256.

•Meldungen X_SYSTEMD_UNIT_ACTIVE=… und X_SYSTEMD_UNIT_INACTIVE=… werden für jede Ziel-Unit ausgesandt, wenn sie aktiv werden oder aufhören, aktiv zu sein. Dies ist zur Nachverfolgung des Systemstartvorgangs und deren Funktionalität nützlich. Beispielsweise ist SSH-Zugriff typischerweise verfügbar, sobald die Meldung erfolgt ist, dass die Unit ssh-access.target gestartet wurde, siehe systemd.special(7) zu Details.

Hinzugefügt in Version 256.

•Eine Meldung X_SYSTEMD_SHUTDOWN=… wird sehr kurz vor dem Herunterfahren des Systems ausgesandt. Der Wert ist einer der Zeichenketten »reboot«, »halt«, »poweroff«, »kexec« und zeigt an, welche Art von Herunterfahren ausgeführt wird.

Hinzugefügt in Version 256.

•Eine Meldung X_SYSTEMD_REBOOT_PARAMETER=… wird auch sehr kurz bevor das System herunterfährt ausgesandt. Ihr Wert ist das Neustartargument, wie es mit systemctl --reboot-argument=… konfiguriert ist.

Hinzugefügt in Version 256.

Beachten Sie, dass diese Erweiterungsfelder zusätzlich zu den regulären Benachrichtigungen »READY=1« und »RELOADING=1« gesandt werden.

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.

Diese Optionen werden zum Testen und zur Selbstprüfung verwandt und systemd kann mit ihnen jederzeit aufgerufen werden:

--dump-configuration-items

Gibt die verstandenen Unit-Konfigurationselemente aus. Diese Ausgabe ist eine knappe, aber komplette Liste aller Konfigurationselemente in Unit-Definitionsdateien.

--dump-bus-properties

Gibt offengelegte Buseigenschaften aus. Diese Ausgabe ist eine knappe, aber komplette Liste von Eigenschaften, die auf D-Bus offengelegt sind.

Hinzugefügt in Version 239.

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

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

Hinzugefügt in Version 227.

--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-action=

Legt fest, was beim Absturz des Systemverwalters (PID 1) getan werden soll. Dieser Schalter hat beim Betrieb von systemd als Benutzerinstanz keinen Effekt. Siehe systemd.crash_action weiter oben.

Hinzugefügt in Version 256.

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

Hinzugefügt in Version 244.

--log-color

Hebt wichtige Protokollmeldungen hervor. Siehe systemd.log_color oben.

Hinzugefügt in Version 244.

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

Hinzugefügt in Version 244.

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

Hinzugefügt in Version 246.

--machine-id=

Setzt die auf der Festplatte gesetzte Maschinenkennung außer Kraft. Siehe systemd.machine_id= oben.

Hinzugefügt in Version 229.

--service-watchdogs

Global alle Dienste-Watchdog-Zeitüberschreitungen und Notfallaktionen aktivieren/deaktivieren. Siehe systemd.service_watchdogs weiter oben.

Hinzugefügt in Version 237.

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

Wenn systemd gestartet oder neugestartet wird, könnte es die Systemuhr auf die »Epoch« stellen. Dieser Mechanismus wird verwandt, um sicherzustellen, dass die Uhr einigermaßen vernünftig initialisiert bleibt und über Neustarts hinweg grob monoton verläuft, falls keine lokale, Batterie-gestützte RTC vorhanden ist oder diese nicht korrekt funktioniert.

Der Epoch ist das kleinste Datum, über dem die Systemuhrzeit als korrekt gesetzt angenommen werden kann. Bei der Initialisierung wird die lokale Uhr auf die Epoch vorgestellt, falls sie auf einen niederigeren Wert gestellt war. Als Spezialfall wird die Systemuhr auf die Epoch zurückgestellt, falls die lokale Uhr hinreichend weit in der Zukunft ist (standardmäßig 15 Jahre, aber dies kann zum Compile-Zeitpunkt konfiguriert werden).

Die Epoch wird auf das höchste der folgenden gesetzt: Dem Bauzeitpunkt von Systemd, der Veränderungszeit (»mtime«) von /usr/lib/clock-epoch und der Veränderungszeit von /var/lib/systemd/timesync/clock.

/run/systemd/notify

Daemon-Statusbenachrichtigungs-Socket. Dies ist ein AF_UNIX-Datagram-Socket, das zur Implementierung der Benachrichtigungslogik des Daemons mit sd_notify(3) verwandt wird.

/run/systemd/private

Wird intern als Kommunikationskanal zwischen systemctl(1) und dem Systemd-Prozess verwandt. Dies ist ein AF_UNIX-Stream-Socket. Diese Schnittstelle ist für Systemd privat und sollte in externen Projekten nicht verwandt werden.

/dev/initctl

Eingeschränkte Kompatibilitätsunterstützung für SysV-Client-Schnittstellen, wie sie von der Unit systemd-initctl.service implementiert wird. Dies ist eine benannte Pipe im Dateisystem. Diese Schnittstelle ist veraltet und sollte in neuen Anwendungen nicht verwandt werden.

/usr/lib/clock-epoch

Die Veränderungszeit (»mtime«) dieser Datei wird für die Zeit-Epoch genutzt, siehe den vorherigen Abschnitt.

Hinzugefügt in Version 247.

/var/lib/systemd/timesync/clock

Die Veränderungszeit (»mtime«) dieser Datei wird von systemd-timesyncd.service(8) aktualisiert. Falls vorhanden, wird die Veränderungszeit dieser Datei für die Epoch verwandt, siehe den vorherigen Abschnitt.

Hinzugefügt in Version 257.

systemd 252

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

Hinzugefügt in Version 252.

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)

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

1.
Schnittstellenportabilitäts- und -stabilitätszusage
https://systemd.io/PORTABILITY_AND_STABILITY/
2.
Container-Schnittstelle
https://systemd.io/CONTAINER_INTERFACE
3.
Initrd-Schnittstelle
https://systemd.io/INITRD_INTERFACE/
4.
Control-Gruppen v2
https://docs.kernel.org/admin-guide/cgroup-v2.html
5.
XDG-Basisverzeichnisspezifikation
https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
6.
Es wird für andere Werkzeuge empfohlen, $SUDO_UID geeignet zu setzen und zu überprüfen und es als allgemeine Schnittstelle zu behandeln.
7.
Bekannte Umgebungsvariablen
https://systemd.io/ENVIRONMENT
8.
System- und Dienste-Zugangsberechtigungen
https://systemd.io/CREDENTIALS
9.
Systemd-Homepage
https://systemd.io/
10.
Ursprüngliches Designdokument
https://0pointer.de/blog/projects/systemd.html

ÜBERSETZUNG

Die deutsche Übersetzung dieser Handbuchseite wurde von Helge Kreutzmann <debian@helgefjell.de> erstellt.

Diese Übersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 3 oder neuer bezüglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG übernommen.

Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an die Mailingliste der Übersetzer: debian-l10n-german@lists.debian.org.

systemd 257.6