Provided by: manpages-de_4.13-4_all bug

BEZEICHNUNG

       systemd, init - Systemd-System und Diensteverwalter

ÜBERSICHT

       /lib/systemd/systemd [OPTIONEN…]

       init [OPTIONEN…] {BEFEHL}

BESCHREIBUNG

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

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

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

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

KONZEPTE

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

       Die folgenden Unit-Typen sind verfügbar:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

       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 cgroups.txt[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/systemd/) 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
           /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

       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+13
           Hält die Maschine sofort an.

       SIGRTMIN+14
           Schaltet die Maschine sofort aus.

       SIGRTMIN+15
           Startet die Maschine sofort neu.

       SIGRTMIN+16
           Startet die Maschine sofort mit kexec neu.

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

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

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

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

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

       SIGRTMIN+25
           Nach Empfang dieses Signals führt der Systemd-Systemverwalter sich selbst erneut aus.
           Dies ist größtenteils äquivalent zu systemctl daemon-reexec, außer dass es asynchron
           erfolgt.

           Der Systemd Systemverwalter behandelt dieses Signal auf die gleiche Art wie SIGTERM.

       SIGRTMIN+26
           Stellt das Protokollierziel wieder auf seinen konfigurierten Wert her. Der
           konfigurierte Wert wird, in dieser Prioritätsreihenfolge, von dem mit
           systemd.log-target= auf der Kernelbefehlszeile angegebenen Wert oder dem mit
           LogTarget= in der Konfigurationsdatei angegebenen Wert oder dem eingebauten Wert
           abgeleitet.

       SIGRTMIN+27, SIGRTMIN+28
           Setzt das Protokollierziel auf »console« bei SIGRTMIN+27 (oder »kmsg« bei
           SIGRTMIN+28), in einer Art äquivalent zu systemd.log_target=console (oder
           systemd.log_target=kmsg bei SIGRTMIN+28) auf der Kernelbefehlszeile.

UMGEBUNGSVARIABLEN

       Der Umgebungsblock für den Systemverwalter wird anfänglich vom Kernel gesetzt.
       (Insbesondere werden »Schlüssel=Wert«-Zuweisungen auf der Kernelbefehlszeile als
       Umgebungsvariablen für PID 1 zurückgeliefert). 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 ausgesandter Nachrichten (Nachrichten mit einer höheren
           Protokollierstufe, d.h. weniger wichtige, werden unterdrückt). Sie muss (in
           absteigender Reihenfolge) entweder alert, crit, err, warning, notice, info, debug oder
           eine Ganzzahl im Bereich 0…7 sein. Siehe syslog(3) für weitere Informationen.

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

       $SYSTEMD_LOG_COLOR
           Ein logischer Wert. Falls wahr, werden auf das TTY geschriebene Nachrichten gemäß
           ihrer Priorität eingefärbt.

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

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

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

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

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

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

       $SYSTEMD_LOG_TARGET
           Das Ziel für Protokolliernachrichten. Entweder console (auf das angehängte TTY
           protokollieren), console-prefixed (auf das angehängte TTY protokollieren, aber die
           Protokollierstufe und »Einrichtung« voranstellen, siehe syslog(3)), kmsg (in den
           zirkulären Kernel-Protokollpuffer protokollieren), journal (in das Journal
           protokollieren (journal-or-kmsg (in das Journal protokollieren, falls verfügbar, und
           andernfalls nach Kmsg), auto (das geeignete Protokollierziel automatisch ermitteln,
           die Vorgabe) oder null (die Protokollierung deaktivieren).

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

       $XDG_CONFIG_HOME, $XDG_CONFIG_DIRS, $XDG_DATA_HOME, $XDG_DATA_DIRS
           Der Systemd-Benutzerverwalter verwendet diese Variablen in Übereinstimmung mit der
           XDG-Basisverzeichnisspezifikation[6], um seine Konfiguration zu finden.

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

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

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

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

           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.

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

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

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

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

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

       $NOTIFY_SOCKET
           Wird durch Systemd für überwachte Prozesse für Status- und
           Hochfahrabschlussbenachrichtigungen gesetzt. Siehe sd_notify(3) für weitere
           Informationen.

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

KERNEL-BEFEHLSZEILE

       Bei der Ausführung als Systeminstanz wertet Systemd eine Reihe von nachfolgend
       aufgeführten Optionen aus. Sie können als Kernelbefehlszeilenargumente[8] oder durch die
       EFI-Variable »SystemdOptions« (auf EFI-Systemen) angegeben werden. Die Kernelbefehlszeile
       hat eine höhere Priorität. Folgende Variablen werden interpretiert:

       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 anfänglichen RAM-Platte (Initrd) berücksichtigt, während die
           Option ohne diese Zeichenkette am Anfang nur im Hauptsystem berücksichtigt wird.

       systemd.dump_core
           Akzeptiert ein logisches Argument oder aktiviert die Option, falls ohne Argument
           angegeben. Falls aktiviert, wird der Systemverwalter (PID 1) einen Speicherauszug
           schreiben, wenn er abstürzt. Andernfalls wird kein Speicherauszug erstellt.
           Standardmäßig aktiviert.

       systemd.crash_chvt
           Akzeptiert eine positive Ganzzahl oder ein logisches Argument. Kann auch ohne Argument
           angegeben werden; dies hat den gleichen Effekt wie ein positiver logischer Wert. Falls
           eine positive Ganzzahl (im Bereich 1…63) angegeben ist, wird der Systemverwalter (PID
           1) die angegebene Anzahl an virtuellen Terminals erstellen, wenn er abstürzt.
           Standardmäßig deaktiviert, was bedeutet, dass dies nicht versucht wird. Falls auf
           aktiviert gesetzt, wird stattdessen das virtuelle Terminal, auf den die
           Kernelnachrichten geschrieben werden, verwandt.

       systemd.crash_shell
           Akzeptiert ein logisches Argument oder aktiviert die Option, falls ohne Argument
           angegeben. Falls aktiviert, wird der Systemverwalter (PID 1) nach einer Verzögerung
           von 10 Sekunden eine Shell starten, wenn er abstürzt. Andernfalls wird keine Shell
           gestartet. Aus Sicherheitsgründen standardmäßig deaktiviert, da die Shell nicht durch
           Passwortauthentifizierung geschützt ist.

       systemd.crash_reboot
           Akzeptiert ein logisches Argument oder aktiviert die Option, falls ohne Argument
           angegeben. Falls aktiviert, wird der Systemverwalter (PID 1) nach einer Verzögerung
           von 10 Sekunden die Maschine neustarten, wenn er abstürzt. Andernfalls wird das System
           unbegrenzt hängen. Standardmäßig deaktiviert, um eine Neustartschleife zu verhindern.
           Falls mit systemd.crash_shell kombiniert, wird das System neu gestartet, nachdem die
           Shell sich beendet.

       systemd.confirm_spawn
           Akzeptiert ein logisches Argument oder einen Pfad zu einer virtuellen Konsole, auf der
           Bestätigungsmeldungen ausgegeben werden sollen. Kann auch ohne Argument angegeben
           werden; dies hat den gleichen Effekt wie ein positiver logischer Wert. Falls
           aktiviert, wird der Systemverwalter (PID 1) um Bestätigung bitten, wenn er einen
           Prozess mittels /dev/console startet. Falls ein Pfad oder Konsolename (wie »ttyS0«)
           bereitgestellt wird, wird stattdessen die durch diesen Pfad angezeigte virtuelle
           Konsole oder durch den übergebenen Namen beschriebene stattdessen verwandt.
           Standardmäßig deaktiviert.

       systemd.service_watchdogs=
           Akzeptiert ein logisches Argument. Falls deaktiviert, werden alle Laufzeit-Watchdogs
           für Dienste (WatchdogSec=) und Notfallaktionen (z.B. OnFailure= oder
           StartLimitAction=) durch den Systemverwalter (PID 1) ignoriert, siehe
           systemd.service(5). Standardmäßig deaktiviert, d.h. Watchdogs und Fehlschlagaktionen
           werden normal verarbeitet. Der Hardware-Watchdog ist durch diese Option nicht
           betroffen.

       systemd.show_status
           Akzeptiert ein logisches Argument oder die Konstanten error und auto. Kann auch ohne
           Argument angegeben werden; dies hat den gleichen Effekt wie ein positiver logischer
           Wert. Falls aktiviert, wird der Systemverwalter (PID 1) auf der Konsole beim
           Systemstart knappe Dienstestatusaktualisierungen anzeigen. Bei error werden nur
           Meldungen über Fehler angezeigt, der Systemstart erfolgt ansonsten still. auto verhält
           sich wie false, bis es beim Systemstart zu signifikanten Verzögerungen kommt.
           Standardmäßig aktiviert, außer quiet wird als Kernelbefehlszeilenoption angegeben. In
           letzterem Fall ist die Vorgabe error. Ist dies angegeben, setzt es die
           Konfigurationsdateioption ShowStatus= des Systemverwalters außer Kraft, siehe
           systemd-system.conf(5).

       systemd.status_unit_format=
           Akzeptiert name, description oder combined als Wert. Falls name, wird der
           Diensteverwalter Unit-Namen in Statusmeldungen verwenden. Falls combined, wird der
           Systemverwalter Unit-Namen und -Beschreibungen in Statusmeldungen verwenden. Wenn
           angegeben, setzt dies die Konfigurationsoption StatusUnitFormat= des Systemverwalters
           außer Kraft, siehe systemd-system.conf(5).

       systemd.log_color, systemd.log_level=, systemd.log_location, systemd.log_target=,
       systemd.log_time, systemd.log_tid
           Steuert die Protokollausgabe, mit dem gleichen Effekt wie die oben beschriebenen
           Umgebungsvariablen $SYSTEMD_LOG_COLOR, $SYSTEMD_LOG_LEVEL, $SYSTEMD_LOG_LOCATION,
           $SYSTEMD_LOG_TARGET, $SYSTEMD_LOG_TIME und $SYSTEMD_LOG_TID. systemd.log_color,
           systemd.log_location, systemd.log_time und systemd.log_tid= können ohne Argumente
           angegeben werden; dies hat den gleichen Effekt wie ein positiver logischer Wert.

       systemd.default_standard_output=, systemd.default_standard_error=
           Steuert die Standardausgabe und Fehlerausgabe für alle Dienste und Sockets. D.h.
           steuert die Vorgabe für StandardOutput= und StandardError= (siehe systemd.exec(5) für
           Details). Akzeptiert einen aus inherit, null, tty, journal, journal+console, kmsg,
           kmsg+console. Falls kein Argument angegeben wird, ist die Vorgabe für
           systemd.default-standard-output= journal und für systemd.default-standard-error=
           inherit.

       systemd.setenv=
           Akzeptiert ein Zeichenkettenargument in der Form VARIABLE=WERT. Kann zum Setzen der
           Standardumgebungsvariablen, die mit Fork erstellten Kindern hinzugefügt werden sollen,
           verwandt werden. Kann mehr als einmal verwandt werden, um mehrere Variablen zu setzen.

       systemd.machine_id=
           Akzeptiert einen 32-Zeichen-Hexadezimalwert zum Setzen der Maschinenkennung.
           Hauptsächlich für den Systemstart über das Netzwerk gedacht, bei dem die gleiche
           Maschinenkennung für jeden Systemstart erwünscht ist.

       systemd.unified_cgroup_hierarchy
           Wird das ohne Argument oder mit einem wahren Argument angegeben, aktiviert dies die
           Verwendung der vereinigten Cgroup-Hierarchie[9] (auch als cgroups-v2 bekannt). Wird es
           mit einem falschen Argument angegeben, wird es auf hybride oder die komplette
           veraltete Cgroup-Hierarchie zurückfallen.

           Falls diese Option nicht angegeben ist, wird das Standardverhalten während der
           Kompilierung (mit der Meson-Option -Ddefault-hierarchy=) bestimmt. Falls der Kernel
           die vereinigte Cgroup-Hierarchie nicht unterstützt, wird die alte Hierarchie verwandt,
           selbst wenn diese Option angegeben ist.

       systemd.legacy_systemd_cgroup_controller
           Wird wirksam, falls die komplette vereinigte Cgroup-Hierarchie nicht verwandt wird
           (siehe vorherige Option). Deaktiviert die »hybride« Cgroup-Hierarchie (d.h. eines von
           Systemd verwandten cgroups-v2-Baumes und der alten Cgroup-Hierarchie[10], für andere
           Controller auch als cgroups-v1 bekannt), falls ohne oder mit einem wahren Argument
           angegeben und erzwingt den vollständigen »alten« Modus. Aktiviert die Verwendung der
           »hybriden« Hierarchie, falls mit einem falschen Argument angegeben.

           Falls diese Option nicht angegeben ist, wird das Standardverhalten während der
           Kompilierung (mit der Meson-Option -Ddefault-hierarchy=) bestimmt. Falls der Kernel
           die vereinigte Cgroup-Hierarchie nicht unterstützt, wird die alte Hierarchie verwandt,
           selbst wenn diese Option angegeben ist.

       quiet
           Schaltet Statusausgaben beim Systemstart aus, ähnlich wie dies systemd.show_status=no
           täte. Beachten Sie, dass diese Option auch vom Kernel selbst gelesen wird und
           Kernelprotokollierungsausgaben deaktiviert. Die Übergabe dieser Option schaltet daher
           die normale Ausgabe sowohl vom Systemverwalter als auch dem Kernel aus.

       debug
           Schaltet den Fehlersuchmodus ein. Dies ist äquivalent zu systemd.log_level=debug.
           Beachten Sie, dass diese Option auch vom Kernel selbst gelesen wird und die
           Kernel-Fehlersuchausgabe aktiviert. Die Übergabe dieser Option schaltet daher die
           Fehlersuchausgabe sowohl vom Systemverwalter als auch des Kernels ein.

       emergency, rd.emergency, -b
           Systemstart in den Notfallmodus. Dies ist zu systemd.unit=emergency.target bzw.
           rd.systemd.unit=emergency.target äquivalent und wird aus Kompatibilitätsgründen und da
           es leichter zu tippen ist, bereitgestellt.

       rescue, rd.rescue, single, s, S, 1
           Systemstart in den Rettungsmodus. Dies ist zu systemd.unit=rescue.target bzw.
           rd.systemd.unit=rescue.target äquivalent und wird aus Kompatibilitätsgründen und da es
           leichter zu tippen ist, bereitgestellt.

       2, 3, 4, 5
           Systemstart in den angegebenen veralteten SysV-Runlevel. Dies ist zu
           systemd.unit=runlevel2.target, systemd.unit=runlevel3.target,
           systemd.unit=runlevel4.target bzw. systemd.unit=runlevel5.target äquivalent und wird
           aus Kompatibilitätsgründen und da es leichter zu tippen ist, bereitgestellt.

       locale.LANG=, locale.LANGUAGE=, locale.LC_CTYPE=, locale.LC_NUMERIC=, locale.LC_TIME=,
       locale.LC_COLLATE=, locale.LC_MONETARY=, locale.LC_MESSAGES=, locale.LC_PAPER=,
       locale.LC_NAME=, locale.LC_ADDRESS=, locale.LC_TELEPHONE=, locale.LC_MEASUREMENT=,
       locale.LC_IDENTIFICATION=
           Setzt die zu verwendende System-Locale. Dies setzt die Einstellungen in
           /etc/locale.conf außer Kraft. Für weitere Informationen siehe locale.conf(5) und
           locale(7).

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

OPTIONEN

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

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

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

       --test
           Bestimmt die anfängliche Hochfahrtransaktion (d.h. die Liste der beim Hochfahren in
           die Warteschlange eingereihten Aufträge), gibt sie aus und beendet sich, ohne
           tatsächlich irgend einen der bestimmten Aufträge auszuführen. Diese Option ist nur zur
           Fehlersuche nützlich. Beachten Sie, dass während des regulären Hochfahrens des
           Diensteverwalters Units, die von dieser Aktion nicht angezeigt werden, gestartet
           werden könnten, da Hardware, Sockets, Busse oder andere Arten von Aktivierungen
           zusätzliche Aufträge während der Ausführung der Transaktion hinzufügen könnnten.
           Verwenden Sie --system, um die anfängliche Transaktion des Systemdiensteverwalters zu
           erbitten (was die implizite Vorgabe ist). Kombinieren Sie mit --user, um stattdessen
           die anfängliche Transaktion für den benutzerbezogenen Diensteverwalter zu erbitten.

       --system, --user
           Wählt aus, ob die anfängliche Transaktion für die Systeminstanz oder für die
           benutzerbezogene Instanz berechnet werden soll, wenn zusammen mit --test verwandt.
           Diese Option hat keine Wirkung ohne --test, da während des regulären (d.h. ohne
           --test) Aufrufs der Diensteverwalter automatisch erkennen wird, ob er im System- oder
           benutzerbezogenen Modus agieren soll, indem er prüft, ob die PID, unter der er laufen
           soll, 1 ist oder nicht. Beachten Sie, dass das Starten und Betreiben eines Systems,
           bei dem der Systemverwalter im Modus --system aber mit einer von 1 verschiedenen PID
           läuft, nicht unterstützt wird.

       -h, --help
           Zeigt einen kurzen Hilfetext an und beendet das Programm.

       --version
           Zeigt eine kurze Versionszeichenkette an und beendet das Programm.

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

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

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

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

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

       --crash-shell
           Führt beim Systemabsturz eine Shell aus. Dieser Schalter hat beim Betrieb als
           Benutzerinstanz keinen Effekt. Siehe systemd.crash_shell= weiter oben.

       --crash-reboot
           Beim Systemabsturz automatisch das System neustarten. Dieser Schalter hat beim Betrieb
           als Benutzerinstanz keinen Effekt. Siehe systemd.crash_reboot weiter oben.

       --confirm-spawn
           Beim Öffnen von Prozessen um Bestätigung bitten. Dieser Schalter hat beim Betrieb als
           Benutzerinstanz keinen Effekt. Siehe systemd.confirm_spawn weiter oben.

       --show-status
           Zeigt knappe Unit-Statusinformationen während des Hochfahrens und Herunterfahrens auf
           der Konsole. Siehe systemd.show_status oben.

       --log-color
           Hebt wichtige Protokollmeldungen hervor. Siehe systemd.log_color oben.

       --log-level=
           Setzt Protokollierstufe. Siehe systemd.log_level weiter oben.

       --log-location
           Schließt den Ort im Code in Protokollmeldungen ein. Siehe systemd.log_location oben.

       --log-target=
           Setzt Protokollierziel. Siehe systemd.log_target weiter oben.

       --log-time=
           Stellt Nachrichten der Konsole einen Zeitstempel voran. Siehe systemd.log_time weiter
           oben.

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

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

       --default-standard-output=, --default-standard-error=
           Setzt die Vorgabe-Standardausgabe und -Fehlerausgabe für alle Dienste bzw. Sockets.
           Siehe systemd.default_standard_output= und systemd.default_standard_error= oben.

SOCKETS UND FIFOS

       /run/systemd/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.

SIEHE AUCH

       Die Systemd-Homepage[11], 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. cgroups.txt
           https://www.kernel.org/doc/Documentation/cgroup-v1/cgroups.txt

        2. Ursprüngliches Designdokument
           http://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
           http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html

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

        8. Falls innerhalb eines Linux-Containers ausgeführt, können diese Argumente als
           Befehlszeilenargumente an Systemd selbst übergeben werden, neben allen anderen
           Befehlszeilenoptionen, die in dem obigen Abschnitt »Optionen« aufgeführt sind. Falls
           außerhalb von Linux-Containern ausgeführt, werden diese Argumente stattdessen aus
           /proc/cmdline ausgewertet.

        9. Vereinigte Cgroup-Hierarchie
           https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html

       10. Alte Cgroup-Hierarchie
           https://www.kernel.org/doc/Documentation/cgroup-v1/

       11. Systemd-Homepage
           https://www.freedesktop.org/wiki/Software/systemd/

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