oracular (1) init.1.gz

Provided by: manpages-de_4.23.1-1_all bug

BEZEICHNUNG

       systemd, init - Systemd-System und Diensteverwalter

ÜBERSICHT

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

       init [OPTIONEN…] {BEFEHL}

BESCHREIBUNG

       Systemd ist ein System- und Diensteverwalter für das Linux-Betriebssystem. Wird es beim Systemstart als
       erster Prozess (als PID 1) ausgeführt, agiert es als Init-System, das das System hochfährt und Dienste
       auf Anwendungsebene verwaltet. Für angemeldete Benutzer zum Starten ihrer Dienste werden separate
       Instanzen gestartet.

       systemd wird normalerweise nicht direkt durch den Benutzer aufgerufen, sondern wird als Symlink
       /sbin/init installiert und während der frühen Systemstartphase ausgeführt. Die Benutzerverwalterinstanzen
       werden automatisch durch den Dienst user@.service(5) gestartet.

       Für die Kompatibilität mit SysV wird das Programm, falls es init genannt und nicht der erste Prozess auf
       der Maschine ist (PID ist nicht 1), telinit ausführen und alle Befehlszeilenargumente unverändert
       weitergeben. Das bedeutet, dass init und telinit beim Aufruf von normalen Anmeldesitzungen größtenteils
       äquivalent sind. Siehe telinit(8) für weitere Informationen.

       Systemd interpretiert die Konfigurationsdatei system.conf und die Dateien in Verzeichnissen
       system.conf.d, wenn es als Systeminstanz läuft. Wenn es als Benutzerinstanz läuft, interpretiert Systemd
       die Konfigurationsdatei user.conf und die Dateien in Verzeichnissen user.conf.d. Siehe
       systemd-system.conf(5) für weitere Informationen.

KONZEPTE

       Systemd stellt ein Abhängigkeitssystem zwischen verschiedenen Einheiten namens »Units« in 11
       verschiedenen Typen bereit. Units kapseln verschiedene Objekte, die für den Systemstart und -betrieb
       relevant sind. Der Großteil der Units wird in Unit-Konfigurationsdateien, deren Syntax und grundlegenden
       Menge an Optionen in systemd.unit(5) beschrieben ist, konfiguriert. Einige Units werden allerdings
       automatisch aus anderen Konfigurationsdateien, dynamisch aus Systemzuständen oder programmatisch zur
       Laufzeit erstellt. Units können »aktiv« (dies bedeutet gestartet, gebunden, eingesteckt, …, abhängig vom
       Unit-Typ, siehe unten) oder »inaktiv« (dies bedeutet gestoppt, nicht gebunden, ausgesteckt, … ) sowie im
       Prozess der Aktivierung oder Deaktivierung, d.h. zwischen den zwei Zuständen (diese Zustände werden
       »Aktivierung« und »Deaktivierung« genannt) sein. Ein besonderer Zustand »fehlgeschlagen« ist auch
       verfügbar, der sehr ähnlich zu »inaktiv« ist und der erreicht wird, wenn der Dienst auf irgendeine Art
       fehlgeschlagen ist (Prozess lieferte beim Beenden einen Fehlercode, ist abgestürzt, eine Aktion erlebte
       eine Zeitüberschreitung oder nach zu vielen Neustarts). Falls dieser Zustand erreicht wird, wird die
       Ursache für spätere Einsichtnahme protokolliert. Beachten Sie, dass die verschiedenen Unit-Typen eine
       Reihe von zusätzlichen Unterzuständen haben können, die auf die fünf hier beschriebenen generalisierten
       Unit-Zustände abgebildet werden.

       Die folgenden Unit-Typen sind verfügbar:

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

        2. Socket-Units, die lokale IPC- oder Netzwerk-Sockets in dem System kapseln, nützlich für
           Socket-basierte Aktivierung. Für Details über Socket-Units siehe systemd.socket(5), für Details über
           Socket-basierte Aktivierung und andere Formen der Aktivierung siehe daemon(7).

        3. Ziel-Units sind für die Gruppierung von Units nützlich. Sie stellen während des Systemstarts auch gut
           bekannte Synchronisationspunkte zur Verfügung, siehe systemd.target(5).

        4. Geräte-Units legen Kernel-Geräte in Systemd offen und können zur Implementierung Geräte-basierter
           Aktivierung verwandt werden. Für Details siehe systemd.device(5).

        5. Einhänge-Units steuern Einhängepunkte in dem Dateisystem, für Details siehe systemd.mount(5).

        6. Automount-Units stellen Selbsteinhänge-Fähigkeiten bereit, für bedarfsgesteuertes Einhängen von
           Dateisystemen sowie parallelisiertem Systemstart. Siehe systemd.automount(5).

        7. Timer-Units sind für das Auslösen der Aktivierung von anderen Units basierend auf Timern nützlich.
           Sie können Details in systemd.timer(5) finden.

        8. Auslagerungs-Units sind ähnlich zu Einhänge-Units und kapseln Speicherauslagerungspartitionen oder
           -dateien des Betriebssystems. Sie werden in systemd.swap(5) beschrieben.

        9. Pfad-Units können zur Aktivierung andere Dienste, wenn sich Dateisystemobjekte ändern oder verändert
           werden, verwandt werden. Siehe systemd.path(5).

       10. Scheiben-Units können zur Gruppierung von Units, die Systemprozesse (wie Dienste- und Bereichs-Units)
           in einem hierarchischen Baum aus Ressourcenverwaltungsgründen verwalten, verwandt werden. Siehe
           systemd.slice(5).

       11. Bereichs-Units sind ähnlich zu Dienste-Units, verwalten aber fremde Prozesse, statt sie auch zu
           starten. Siehe systemd.scope(5).

       Units werden wie ihre Konfigurationsdateien benannt. Einige Units habe besondere Semantiken. Eine
       detaillierte Liste ist in systemd.special(7) verfügbar.

       Systemd kennt verschiedene Arten von Abhängigkeiten, einschließlich positiven und negativen
       Bedingungsabhängigkeiten (d.h. Requires= und Conflicts=) sowie Ordnungsabhängigkeiten (After= und
       Before=). Wohlgemerkt: Ordnungs- und Bedingungsabhängigkeiten sind orthogonal. Falls zwischen zwei Units
       nur eine Bedingungsabhängigkeit (z.B. foo.service bedingt bar.service) aber keine Ordnungsabhängigkeit
       (z.B. foo.service nach bar.service) existiert und beide zum Start angefragt werden, werden sie parallel
       gestartet. Es ist ein häufiges Muster, dass sowohl Bedingungs- als auch Ordnungsabhängigkeiten zwischen
       zwei Units angelegt werden. Beachten Sie auch, dass die Mehrzahl der Abhängigkeiten von Systemd implizit
       erstellt und verwaltet werden. In den meisten Fällen sollte es unnötig sein, zusätzliche Abhängigkeiten
       manuell zu deklarieren, allerdings ist dies möglich.

       Anwendungsprogramme und Units (über Abhängigkeiten) können Statusänderungen von Units erbitten. In
       Systemd werden diese Anfragen als »Aufträge« gekapselt und in einer Aufträgewarteschlange verwaltet.
       Aufträge können erfolgreich sein und fehlschlagen, ihre Ausführungsreihenfolge basiert auf den
       Ordnungsabhängigkeiten der Units, für die sie eingeplant wurden.

       Beim Systemstart aktiviert Systemd die Ziel-Unit default.target, deren Aufgabe es ist, die
       bei-Systemstart-Dienste und andere bei-Systemstart-Units zu aktivieren, indem sie sie mittels
       Abhängigkeiten hereinzieht. Normalerweise ist der Unit-Name nur ein Alias (Symlink) für entweder
       graphical.target (für vollfunktionale Systemstarts in die UI) oder multi-user.target (für begrenzte, rein
       konsolenbasierte Systemstarts zur Verwendung in eingebetteten oder Server-Umgebungen oder ähnlichen, eine
       Untermenge von graphical.target). Es obliegt aber dem Administrator, sie als Alias zu jeder anderen
       Ziel-Unit zu konfigurieren. Siehe systemd.special(7) für Details über diese Ziel-Units.

       Beim ersten Systemstart wird systemd Units gemäß der Voreinstellungs-Richtlinie aktivieren oder
       deaktivieren. Siehe systemd.preset(5) und »Semantik beim ersten Systemstart« in machine-id(5).

       Systemd behält nur eine minimale Gruppe an Units im Speicher geladen. Konkret werden nur die Units im
       Speicher geladen gehalten, für die mindestens eine der nachfolgenden Bedingungen zutrifft:

        1. Sie ist in einem aktiven, aktivierenden, deaktivierenden oder fehlgeschlagenen Zustand (d.h. in jedem
           Zustand außer »inactive«)

        2. Für sie ist ein Auftrag in der Warteschlange

        3. Sie ist eine Abhängigkeit von mindestens einer anderen im Speicher geladenen Unit

        4. Ihr ist noch irgendeine Form von Ressourcen zugewiesen (z.B. eine inaktive Dienste-Unit, für die aber
           ein Prozess noch herumlungert, der die Aufforderung zum Beenden ignorierte)

        5. Sie wurde durch einen D-Bus-Aufruf programmatisch im Speicher festgepinnt

       Systemd wird automatisch und implizit Units von der Platte laden — falls sie noch nicht geladen sind —
       sobald eine Aktion für sie angefordert wird. Daher ist in vielerlei Hinsicht die Tatsache, ob eine Unit
       geladen ist oder nicht, für Clients unsichtbar. Verwenden Sie systemctl list-units --all, um eine
       vollumfängliche Liste aller derzeit geladenen Units zu erhalten. Jede Unit, für die eine der oben
       aufgeführten Bedingungen zutrifft, wird sofort entladen. Beachten Sie, dass beim Entladen einer Unit aus
       dem Speicher die Buchführungsdaten auch entfernt werden. Allerdings sind diese Daten im Allgemeinen nicht
       verloren, da ein Journal-Protokolleintrag erstellt wird, der die verbrauchten Ressourcen deklariert, wann
       immer eine Unit herunterfährt.

       Prozesse, die Systemd startet, werden in einer privaten Systemd-Hierarchie in individuellen
       Control-Gruppen von Linux, die nach der Unit, zu der sie gehören, benannt sind, gelegt (siehe Control
       Groups v2[1] für weitere Informationen über Control-Gruppen oder kurz »cgroups«). Systemd verwendend
       dies, um Prozesse effektiv nachzuverfolgen. Control-Gruppen-Informationen werden im Kernel verwaltet und
       sind über die Dateisystemhierarchie (unterhalb von /sys/fs/cgroup/) oder über Werkzeuge wie
       systemd-cgls(1) oder ps(1) verfügbar. (ps xawf -eo pid,user,cgroup,args ist besonders nützlich, um alle
       Prozesse und die Systemd-Units, zu denen sie gehören, aufzulisten.)

       Systemd ist zu einem großen Teil zu SysV kompatibel: SysV-Init-Skripte werden unterstützt und werden
       einfach als ein alternatives (wenn auch begrenztes) Konfigurationsdateiformat verstanden. Die
       SysV-Schnittstelle /dev/initctl wird bereitgestellt und Kompatibilitätsimplementierungen der
       verschiedenen SysV-Client-Werkzeuge sind verfügbar. Zusätzlich werden verschiedene etablierte
       Unix-Funktionalitäten wie /etc/fstab oder die Utmp-Datenbank unterstützt.

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

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

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

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

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

       Units können dynamisch zum Systemstartzeitpunkt und zum Systemverwalter-Neuladezeitpunkt erstellt werden,
       beispielsweise basierend auf anderen Konfigurationsdateien oder auf von der Kernelbefehlszeile
       übergebenen Parametern. Für Details siehe systemd.generator(7).

       Das D-Bus-API von systemd wird in org.freedesktop.systemd1(5) und org.freedesktop.LogControl1(5)
       beschrieben.

       Systeme, die Systemd in einem Container oder in einer Initrd-Umgebung aufrufen, sollten die Spezifikation
       Container-Schnittstelle[4] bzw. initrd-Schnittstelle[5] implementieren.

VERZEICHNISSE

       System-Unit-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[6] zum Finden von Units gefolgt. Anwendungen sollten ihre
           Unit-Dateien in dem durch pkg-config systemd --variable=systemduserunitdir zurückgelieferten
           Verzeichnis ablegen. Globale Konfiguration erfolgt in dem durch pkg-config systemd
           --variable=systemduserconfdir gemeldeten Verzeichnis. Die Befehle enable und disable des Werkzeugs
           systemctl(1) können sowohl mit globaler (d.h. für alle Benutzer) als auch privater (für einen
           Benutzer) Freigabe/Ausschaltung von Units umgehen. Eine vollständige Auflistung von Verzeichnissen
           wird in systemd.unit(5) bereitgestellt.

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

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

SIGNALE

       The service listens to various UNIX process signals that can be used to request various actions
       asynchronously. The signal handling is enabled very early during boot, before any further processes are
       invoked. However, a supervising container manager or similar that intends to request these operations via
       this mechanism must take into consideration that this functionality is not available during the earliest
       initialization phase. An sd_notify() notification message carrying the X_SYSTEMD_SIGNALS_LEVEL=2 field is
       emitted once the signal handlers are enabled, see below. This may be used to schedule submission of these
       signals correctly.

       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.

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

       SIGRTMIN+22
           Setzt die Protokollierstufe des Diensteverwalters auf »debug«, in einer Art, die äquivalent zu
           systemd.log_level=debug auf der Kernelbefehlszeile ist.

       SIGRTMIN+23
           Stellt die Protokollierstufe wieder auf ihren konfigurierten Wert her. Der konfigurierte Wert wird,
           in dieser Prioritätsreihenfolge, von dem mit systemd.log-level= auf der Kernelbefehlszeile
           angegebenen Wert oder dem mit LogLevel= in der Konfigurationsdatei angegebenen Wert oder dem
           eingebauten Wert »info« abgeleitet.

           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.

UMGEBUNGSVARIABLEN

       Der Umgebungsblock für den Systemverwalter wird anfänglich vom Kernel gesetzt. (Insbesondere werden
       »Schlüssel=Wert«-Zuweisungen auf der Kernelbefehlszeile in Umgebungsvariablen für PID 1 umgewandelt). Für
       den Benutzerverwalter setzt der Systemverwalter den Umgebungsblock, wie im Abschnitt »Umgebungsvariablen
       in erzeugten Prozessen« von systemd.exec(5) beschrieben. Die Einstellung DefaultEnvironment= im
       Systemverwalter gilt für alle Dienste, einschließlich 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 einer 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 wahr, werden auf das TTY geschriebene Nachrichten gemäß ihrer Priorität
           eingefärbt.

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

       $SYSTEMD_LOG_TIME
           Ein logischer Wert. Falls wahr, wird den Protokollnachrichten der Konsole ein Zeitstempel
           vorangestellt.

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

           Hinzugefügt in Version 246.

       $SYSTEMD_LOG_LOCATION
           Ein logischer Wert. Falls wahr, wird den Protokollnachrichten ein Dateinamen und eine Zeilenummer in
           dem Quellcode, aus dem die Nachrichten stammen, vorangestellt.

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

       $SYSTEMD_LOG_TID
           Ein logischer Wert. Falls wahr, wird den Nachrichten die aktuelle numerische Thread-Kennung (TID)
           vorangestellt.

           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[6], um seine Konfiguration zu finden.

       $SYSTEMD_UNIT_PATH, $SYSTEMD_GENERATOR_PATH, $SYSTEMD_ENVIRONMENT_GENERATOR_PATH
           Steuert, wo Systemd nach Unit-Dateien und Generatoren schaut.

           Diese Variablen können eine Liste von Pfaden, getrennt durch Doppelpunkte (»:«), enthalten. Ist dies
           gesetzt und endet mit der leeren Komponente (»…:«), wird diese Liste der normalen Gruppe an Pfaden
           vorangestellt. Andernfalls ersetzt die angegebene Liste die normale Gruppe an Pfaden.

       $SYSTEMD_PAGER
           Zu verwendendes Textanzeigeprogramm, wenn --no-pager nicht angegeben ist; setzt $PAGER außer Kraft.
           Falls weder $SYSTEMD_PAGER noch $PAGER gesetzt sind, wird eine Reihe wohlbekannter 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 der Umgebungsvariablen auf die leere Zeichenkette oder den Wert »cat« ist
           äquivalent zur Übergabe von --no-pager.

           Beachten Sie: Falls $SYSTEMD_PAGERSECURE nicht gesetzt ist, dann wird $SYSTEMD_PAGER (sowie $PAGER)
           ohne Rückmeldung ignoriert.

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

           Benutzer könnten insbesondere zwei Optionen ändern wollen:

           K
               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ührungen 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
           Akzeptiert einen logischen Wert. Wenn wahr, wird der »sichere« Modus des Textanzeigeprogramms
           verwandt, falls falsch, wird dieser deaktiviert. Falls $SYSTEMD_PAGERSECURE überhaupt nicht gesetzt
           ist, dann wird der sichere Modus aktiviert, falls die effektive Kennung nicht identisch zu dem
           Eigentümer der Anmeldesitzung ist, siehe geteuid(2) und sd_pid_get_owner_uid(3). Im sicheren Modus
           wird LESSSECURE=1 beim Aufruf des Textanzeigeprogramms gesetzt und das Textanzeigeprogramm muss
           Befehle deaktivieren, die neue Dateien öffnen oder erstellen oder die einen neuen Unterprozess
           starten. Falls $SYSTEMD_PAGERSECURE überhaupt nicht gesetzt ist, werden Textanzeigeprogramme, bei
           denen unbekannt ist, ob sie einen sicheren Modus implementieren, nicht verwandt. (Derzeit
           implementiert nur less(1) einen sicheren Modus.)

           Hinweis: Wenn Befehle mit erhöhten Rechten ausgeführt werden, beispielsweise mittels sudo(8) oder
           pkexec(1), muss Vorsicht walten gelassen werden, um sicherzustellen, dass keine ungeplanten
           interaktiven Funktionalitäten aktiviert werden. Der »sichere« Modus für das Textanzeigeprogramm kann
           wie oben beschrieben automatisch aktiviert werden. Durch Setzen von SYSTEMD_PAGERSECURE=0 oder durch
           Nichtenfernen dieser Einstellung aus der ererbten Umgebung wird es dem Benutzer ermöglicht, beliebige
           Befehle auszuführen. Beachten Sie, dass auch $SYSTEMD_PAGERSECURE gesetzt werden muss, falls die
           Variablen $SYSTEMD_PAGER oder $PAGER berücksichtigt werden sollen. Es kann sinnvoll sein, stattdessen
           das Textanzeigeprogramm komplett mit --no-pager zu deaktivieren.

       $SYSTEMD_COLORS
           Akzeptiert ein logisches Argument. Wenn wahr, werden systemd und verwandte Hilfswerkzeuge Farben in
           ihrer Ausgabe verwenden, andernfalls wird die Ausgabe einfarbig sein. Zusätzlich kann die Variable
           eine der folgenden besonderen Werte annehmen: »16«, »256«, um die Verwendung von Farbe auf die
           grundlegenden 16 bzw. 256 ANSI-Farben zu beschränken. Dies kann festgelegt werden, um die auf $TERM
           und der vorliegenden Verbindung der Konsole basierende automatische Entscheidung außer Kraft zu
           setzen.

       $SYSTEMD_URLIFY
           Dies muss ein logischer Wert sein. Er steuert, ob anklickbare Links für Terminal-Emulatoren, die dies
           unterstützen, erstellt werden sollen. Dies kann angegeben werden, um die Entscheidung, die systemd
           basierend auf $TERM und anderen Bedingungen trifft, außer Kraft zu setzen.

       $LISTEN_PID, $LISTEN_FDS, $LISTEN_FDNAMES
           Wird durch Systemd für überwachte Prozesse während Socket-basierter Aktivierung gesetzt. Siehe
           sd_listen_fds(3) für weitere Informationen.

       $NOTIFY_SOCKET
           Set by service manager for its services for status and readiness notifications. Also consumed by
           service manager for notifying supervising container managers or service managers up the stack about
           its own progress. See sd_notify(3)  and the relevant section below for more information.

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

KERNEL-BEFEHLSZEILE

       Bei der Ausführung als Systeminstanz wertet Systemd eine Reihe von nachfolgend aufgeführten Optionen aus.
       Diese können als Kernelbefehlszeilenargumente angegeben werden, die von einer Reihe von Quellen
       ausgewertet werden, abhängig von der Umgebung, in der Systemd ausgeführt wird. Beim Betrieb innerhalb
       eines Linux-Containers werden diese Optionen, die von der Befehlszeile übergeben werden, von Systemd
       selbst ausgewertet, neben allen Befehlzeilenoptionen, die in obigem Abschnitt Options aufgeführt sind.
       Beim Betrieb von außerhalb von Linux-Containern werden diese Argumente stattdessen aus /proc/cmdline und
       der EFI-Variable »SystemdOptions« (auf EFI-Systemen) auswerten. Optionen von /proc/cmdline haben höhere
       Priorität.

       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) nach einer Verzögerung von 10 Sekunden eine Shell
           starten, wenn er abstürzt. Andernfalls wird keine Shell gestartet. Aus Sicherheitsgründen
           standardmäßig deaktiviert, da die Shell nicht durch Passwortauthentifizierung geschützt ist.

           Hinzugefügt in Version 233.

       systemd.crash_action=
           Takes one of "freeze", "reboot" or "poweroff". Defaults to "freeze". If set to "freeze", the system
           will hang indefinitely when the system manager (PID 1) crashes. If set to "reboot", the system
           manager (PID 1) will reboot the machine automatically when it crashes, after a 10s delay. If set to
           "poweroff", the system manager (PID 1) will power off the machine immediately when it crashes. If
           combined with systemd.crash_shell, the configured crash action is executed after the shell exits.

           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 falsch, deaktiviert den Import von Zugangsberechtigungen aus
           der Kernel-Befehlszeile, der DMI/SMBIOS-OEM-Zeichenketten-Tabelle, dem qemu_fw_cfg-Sybsystem oder dem
           EFI-Kernel-Rumpf.

           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. Dies ist zu systemd.unit=runlevel2.target,
           systemd.unit=runlevel3.target, systemd.unit=runlevel4.target bzw. systemd.unit=runlevel5.target
           äquivalent und wird aus Kompatibilitätsgründen und da es leichter zu tippen ist, bereitgestellt.

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

SYSTEMZUGANGSBERECHTIGUNGEN

       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
           Contains a AF_VSOCK or AF_UNIX address where to send a READY=1 notification message when the service
           manager has completed booting. See sd_notify(3)  and the next section for more information. Note that
           in case the hypervisor does not support SOCK_DGRAM over AF_VSOCK, SOCK_SEQPACKET will be tried
           instead. The credential payload for AF_VSOCK should be a string in the form "vsock:CID:PORT".
           "vsock-stream", "vsock-dgram" and "vsock-seqpacket" can be used instead of "vsock" to force usage of
           the corresponding socket type.

           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.

       For a list of system credentials various other components of systemd consume, see
       systemd.system-credentials(7).

READINESS PROTOCOL

       The service manager implements a readiness notification protocol both between the manager and its
       services (i.e. down the stack), and between the manager and a potential supervisor further up the stack
       (the latter could be a machine or container manager, or in case of a per-user service manager the system
       service manager instance). The basic protocol (and the suggested API for it) is described in
       sd_notify(3).

       The notification socket the service manager (including PID 1) uses for reporting readiness to its own
       supervisor is set via the usual $NOTIFY_SOCKET environment variable (see above). Since this is directly
       settable only for container managers and for the per-user instance of the service manager, an additional
       mechanism to configure this is available, in particular intended for use in VM environments: the
       vmm.notify_socket system credential (see above) may be set to a suitable socket (typically an AF_VSOCK
       one) via SMBIOS Type 11 vendor strings. For details see above.

       The notification protocol from the service manager up the stack towards a supervisor supports a number of
       extension fields that allow a supervisor to learn about specific properties of the system and track its
       boot progress. Specifically the following fields are sent:

       •   An X_SYSTEMD_HOSTNAME=... message will be sent out once the initial hostname for the system has been
           determined. Note that during later runtime the hostname might be changed again programmatically, and
           (currently) no further notifications are sent out in that case.

           Hinzugefügt in Version 256.

       •   An X_SYSTEMD_MACHINE_ID=... message will be sent out once the machine ID of the system has been
           determined. See machine-id(5)  for details.

           Hinzugefügt in Version 256.

       •   An X_SYSTEMD_SIGNALS_LEVEL=... message will be sent out once the service manager installed the
           various UNIX process signal handlers described above. The field's value is an unsigned integer
           formatted as decimal string, and indicates the supported UNIX process signal feature level of the
           service manager. Currently, only a single feature level is defined:

           •   X_SYSTEMD_SIGNALS_LEVEL=2 covers the various UNIX process signals documented above – which are a
               superset of those supported by the historical SysV init system.

           Signals sent to PID 1 before this message is sent might not be handled correctly yet. A consumer of
           these messages should parse the value as an unsigned integer indication the level of support. For now
           only the mentioned level 2 is defined, but later on additional levels might be defined with higher
           integers, that will implement a superset of the currently defined behaviour.

           Hinzugefügt in Version 256.

       •   X_SYSTEMD_UNIT_ACTIVE=... and X_SYSTEMD_UNIT_INACTIVE=... messages will be sent out for each target
           unit as it becomes active or stops being active. This is useful to track boot progress and
           functionality. For example, once the ssh-access.target unit is reported started SSH access is
           typically available, see systemd.special(7)  for details.

           Hinzugefügt in Version 256.

       •   An X_SYSTEMD_SHUTDOWN=... message will be sent out very shortly before the system shuts down. The
           value is one of the strings "reboot", "halt", "poweroff", "kexec" and indicates which kind of
           shutdown is being executed.

           Hinzugefügt in Version 256.

       •   An X_SYSTEMD_REBOOT_PARAMETER=... message will also be sent out very shortly before the system shuts
           down. Its value is the reboot argument as configured with systemctl --reboot-argument=....

           Hinzugefügt in Version 256.

       Note that these extension fields are sent in addition to the regular "READY=1" and "RELOADING=1"
       notifications.

OPTIONEN

       Systemd wird nur sehr selten direkt aufgerufen, da es früh gestartet wird und bereits läuft, wenn
       Benutzer mit ihm interagieren. Normalerweise werden Werkzeuge wie systemctl(1) verwandt, um Befehle an
       den Verwalter abzusetzen. Da systemd normalerweise nicht direkt aufgerufen wird, sind die nachfolgend
       aufgeführten Optionen hauptsächlich zur Fehlersuche und für besondere Zwecke nützlich.

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

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

   Optionen, die Kernelbefehlszeileneinstellungen duplizieren
       Diese Optionen entsprechen direkt den oben unter »Kernel-Befehlszeile« aufgeführten Optionen. Beide
       Formen können gleichwertig für den Systemverwalter verwandt werden, aber es wird empfohlen, in diesem
       Zusammenhang die oben aufgeführten Formen einzusetzen, da ihnen ein korrekter Namensraum zugewiesen ist.
       Wenn eine Option sowohl auf der Kernelbefehlszeile als auch als normales Befehlszeilenargument angegeben
       ist, hat letztere höheren Vorrang.

       Wird systemd als Benutzerverwalter eingesetzt, wird die Kernelbefehlzeile ignoriert und nur die
       beschriebenen Optionen werden verstanden. Da systemd normalerweise durch den Dienst user@.service(5) in
       diesem Modus gestartet wird und der Dienst von allen Benutzer gemeinsam verwandt wird, kann es bequemer
       sein, die Konfigurationsdatei oder Umgebungsvariablen zu verwenden, um Einstellungen zu verändern (siehe
       systemd-user.conf(5)). Siehe den obigen Abschnitt »Umgebungsvariablen« für eine Diskussion, wie der
       Umgebungsblock gesetzt wird.

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

       --dump-core
           Beim Absturz Kernspeicherabzüge aktivieren. Dieser Schalter hat beim Betrieb als Benutzerinstanz
           keinen Effekt. Identisch zu systemd.dump_core= weiter oben.

       --crash-vt=VT
           Beim Absturz auf eine bestimmte virtuelle Konsole (VT) umschalten. Dieser Schalter hat beim Betrieb
           als Benutzerinstanz keine Wirkung. Identisch zu systemd.crash_chvt= oben (beachten Sie aber die
           andere Schreibweise).

           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=
           Specify what to do when the system manager (PID 1) crashes. This switch has no effect when systemd is
           running as user instance. See systemd.crash_action= above.

           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.

SOCKETS UND FIFOS

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

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

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

GESCHICHTE

       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.

SIEHE AUCH

       Die Systemd-Homepage[9], systemd-system.conf(5), locale.conf(5), systemctl(1), journalctl(1),
       systemd-notify(1), daemon(7), sd-daemon(3), org.freedesktop.systemd1(5), systemd.unit(5),
       systemd.special(7), pkg-config(1), kernel-command-line(7), bootup(7), systemd.directives(7)

ANMERKUNGEN

        1. Control-Gruppen v2
           https://docs.kernel.org/admin-guide/cgroup-v2.html

        2. Ursprüngliches Designdokument
           https://0pointer.de/blog/projects/systemd.html

        3. Schnittstellenportabilitäts- und -stabilitätszusage
           https://systemd.io/PORTABILITY_AND_STABILITY/

        4. Container-Schnittstelle
           https://systemd.io/CONTAINER_INTERFACE

        5. Initrd-Schnittstelle
           https://systemd.io/INITRD_INTERFACE/

        6. XDG-Basisverzeichnisspezifikation
           https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html

        7. Bekannte Umgebungsvariablen
           https://systemd.io/ENVIRONMENT

        8. System- und Dienste-Zugangsberechtigungen
           https://systemd.io/CREDENTIALS

        9. Systemd-Homepage
           https://systemd.io/

Ü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
       ⟨https://www.gnu.org/licenses/gpl-3.0.html⟩ 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⟩.