SYSTEMD(1) systemd SYSTEMD(1) BEZEICHNUNG systemd, init - Systemd-System und Diensteverwalter UBERSICHT /usr/lib/systemd/systemd [OPTIONEN] init [OPTIONEN] BESCHREIBUNG Systemd ist ein System- und Diensteverwalter fur das Linux-Betriebssystem. Wird es beim Systemstart als erster Prozess (als PID 1) ausgefuhrt, agiert es als Init-System, das das System hochfahrt und Dienste auf Anwendungsebene verwaltet. Fur 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 wahrend der fruhen Systemstartphase ausgefuhrt. Die Benutzerverwalterinstanzen werden automatisch durch den Dienst user@.service(5) gestartet. Systemd interpretiert die Konfigurationsdatei system.conf und die Dateien in Verzeichnissen system.conf.d, wenn es als Systeminstanz lauft. Wenn es als Benutzerinstanz lauft, interpretiert Systemd die Konfigurationsdatei user.conf und die Dateien in Verzeichnissen user.conf.d. Siehe systemd-system.conf(5) fur weitere Informationen. systemd enthalt native Implementierungen verschiedener Programme, die als Teil des Systemstartprozesses ausgefuhrt werden mussen. Beispielsweise setzt es den Rechnernamen und konfiguriert das Loopback-Netzwerkgerat. Es richtet auch die verschiedenen API-Dateisysteme, wie /sys/, /proc/ und /dev/, ein und hangt sie ein. systemd wird wahrend der fruhen Systemstartphase auch die Uhr zurucksetzen, falls sie anscheinend falls gesetzt ist. Siehe den nachfolgenden Abschnitt >>Systemuhr-Epoch<<. Beachten Sie, dass einige, aber nicht alle, durch Systemd bereitgestellte Schnittstellen von der Schnittstellenportierungs und -stabilitatszusage[1] abgedeckt sind. Das D-Bus-API von systemd wird in org.freedesktop.systemd1(5) und org.freedesktop.LogControl1(5) beschrieben. Systeme, die Systemd in einem Container oder in einer Initrd-Umgebung aufrufen, sollten die Spezifikation Container-Schnittstelle[2] bzw. initrd-Schnittstelle[3] implementieren. UNITS Systemd stellt ein Abhangigkeitssystem zwischen verschiedenen Einheiten namens >>Units<< in 11 verschiedenen Typen bereit. Units kapseln verschiedene Objekte, die fur den Systemstart und -betrieb relevant sind. Der Grossteil 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 Systemzustanden oder programmatisch zur Laufzeit erstellt. Units konnen in einer Reihe von Zustanden sein, die in der nachfolgenden Tabelle beschrieben sind. Beachten Sie, dass die verschiedenen Unit-Typen eine Reihe von zusatzlichen Unterzustanden haben konnen, die auf die hier beschriebenen generalisierten Unit-Zustande abgebildet werden. Tabelle 1. Unit-AKTIVITATS-Zustande +-------------+----------------------------+ |Zustand | Beschreibung | +-------------+----------------------------+ |active | Gestartet, gebunden, | | | eingesteckt abhangig | | | vom Unit-Typ. | +-------------+----------------------------+ |inactive | Gestoppt, losgelost, | | | ausgesteckt abhangig | | | vom Unit-Typ. | +-------------+----------------------------+ |failed | Ahnlich zu inactive, aber | | | die Unit schlug irgendwie | | | fehl (Prozess lieferte | | | beim Exit einen | | | Fehler-Code, sturzte ab, | | | eine Aktion ist in eine | | | Zeituberschreitung | | | gelaufen oder nach zu | | | vielen Neustarts). | +-------------+----------------------------+ |activating | Anderung von inactive auf | | | active. | +-------------+----------------------------+ |deactivating | Anderung von active auf | | | inactive. | +-------------+----------------------------+ |maintenance | Unit ist inactive und eine | | | Wartungsaktion lauft | | | derzeit. | +-------------+----------------------------+ |reloading | Unit ist active und sie | | | ladt ihre Konfiguration | | | neu. | +-------------+----------------------------+ |refreshing | Unit ist active und es | | | wird eine neue Einhangung | | | in ihrem Namensraum | | | aktiviert. | +-------------+----------------------------+ Die folgenden Unit-Typen sind verfugbar: 1. Dienste-Units, die Daemons und die Prozesse, aus denen sie bestehen, starten und steuern. Fur Details siehe systemd.service(5). 2. Socket-Units, die lokale IPC- oder Netzwerk-Sockets in dem System kapseln, nutzlich fur Socket-basierte Aktivierung. Fur Details uber Socket-Units siehe systemd.socket(5), fur Details uber Socket-basierte Aktivierung und andere Formen der Aktivierung siehe daemon(7). 3. Ziel-Units sind fur die Gruppierung von Units nutzlich. Sie stellen wahrend des Systemstarts auch gut bekannte Synchronisationspunkte zur Verfugung, siehe systemd.target(5). 4. Gerate-Units legen Kernel-Gerate in Systemd offen und konnen zur Implementierung Gerate-basierter Aktivierung verwandt werden. Fur Details siehe systemd.device(5). 5. Einhange-Units steuern Einhangepunkte in dem Dateisystem, fur Details siehe systemd.mount(5). 6. Automount-Units stellen Selbsteinhange-Fahigkeiten bereit, fur bedarfsgesteuertes Einhangen von Dateisystemen sowie parallelisiertem Systemstart. Siehe systemd.automount(5). 7. Timer-Units sind fur das Auslosen der Aktivierung von anderen Units basierend auf Timern nutzlich. Sie konnen Details in systemd.timer(5) finden. 8. Auslagerungs-Units sind ahnlich zu Einhange-Units und kapseln Speicherauslagerungspartitionen oder -dateien des Betriebssystems. Sie werden in systemd.swap(5) beschrieben. 9. Pfad-Units konnen zur Aktivierung andere Dienste, wenn sich Dateisystemobjekte andern oder verandert werden, verwandt werden. Siehe systemd.path(5). 10. Scheiben-Units konnen zur Gruppierung von Units, die Systemprozesse (wie Dienste- und Bereichs-Units) in einem hierarchischen Baum aus Ressourcenverwaltungsgrunden verwalten, verwandt werden. Siehe systemd.slice(5). 11. Bereichs-Units sind ahnlich 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) verfugbar. Systemd kennt verschiedene Arten von Abhangigkeiten, einschliesslich positiven und negativen Bedingungsabhangigkeiten (d.h. Requires= und Conflicts=) sowie Ordnungsabhangigkeiten (After= und Before=). Wohlgemerkt: Ordnungs- und Bedingungsabhangigkeiten sind orthogonal. Falls zwischen zwei Units nur eine Bedingungsabhangigkeit (z.B. foo.service bedingt bar.service) aber keine Ordnungsabhangigkeit (z.B. foo.service nach bar.service) existiert und beide zum Start angefragt werden, werden sie parallel gestartet. Es ist ein haufiges Muster, dass sowohl Bedingungs- als auch Ordnungsabhangigkeiten zwischen zwei Units angelegt werden. Beachten Sie auch, dass die Mehrzahl der Abhangigkeiten von Systemd implizit erstellt und verwaltet werden. In den meisten Fallen sollte es unnotig sein, zusatzliche Abhangigkeiten manuell zu deklarieren, allerdings ist dies moglich. Anwendungsprogramme und Units (uber Abhangigkeiten) konnen Statusanderungen von Units erbitten. In Systemd werden diese Anfragen als >>Auftrage<< gekapselt und in einer Auftragewarteschlange verwaltet. Auftrage konnen erfolgreich sein und fehlschlagen, ihre Ausfuhrungsreihenfolge basiert auf den Ordnungsabhangigkeiten der Units, fur 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 Abhangigkeiten hereinzieht. Normalerweise ist der Unit-Name nur ein Alias (Symlink) fur entweder graphical.target (fur vollfunktionale Systemstarts in die UI) oder multi-user.target (fur begrenzte, rein konsolenbasierte Systemstarts zur Verwendung in eingebetteten oder Server-Umgebungen oder ahnlichen, eine Untermenge von graphical.target). Es obliegt aber dem Administrator, sie als Alias zu jeder anderen Ziel-Unit zu konfigurieren. Siehe systemd.special(7) fur Details uber diese Ziel-Units. Beim ersten Systemstart wird systemd Units gemass der Voreinstellungs-Richtlinie aktivieren oder deaktivieren. Siehe systemd.preset(5) und >>Semantik beim ersten Systemstart<< in machine-id(5). Systemd behalt nur eine minimale Gruppe an Units im Speicher geladen. Konkret werden nur die Units im Speicher geladen gehalten, fur die mindestens eine der nachfolgenden Bedingungen zutrifft: 1. Sie ist in einem aktiven, aktivierenden, deaktivierenden oder fehlgeschlagenen Zustand (d.h. in jedem Zustand ausser >>inactive<<) 2. Fur sie ist ein Auftrag in der Warteschlange 3. Sie ist eine Abhangigkeit von mindestens einer anderen im Speicher geladenen Unit 4. Ihr ist noch irgendeine Form von Ressourcen zugewiesen (z.B. eine inaktive Dienste-Unit, fur 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 fur sie angefordert wird. Daher ist in vielerlei Hinsicht die Tatsache, ob eine Unit geladen ist oder nicht, fur Clients unsichtbar. Verwenden Sie systemctl list-units --all, um eine vollumfangliche Liste aller derzeit geladenen Units zu erhalten. Jede Unit, fur die eine der oben aufgefuhrten Bedingungen zutrifft, wird sofort entladen. Beachten Sie, dass beim Entladen einer Unit aus dem Speicher die Buchfuhrungsdaten 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 herunterfahrt. Prozesse, die Systemd startet, werden in einer privaten Systemd-Hierarchie in individuellen Control-Gruppen von Linux, die nach der Unit, zu der sie gehoren, benannt sind, gelegt (siehe Control Groups v2[4] fur weitere Informationen uber Control-Gruppen oder kurz >>cgroups<<). Systemd verwendend dies, um Prozesse effektiv nachzuverfolgen. Control-Gruppen-Informationen werden im Kernel verwaltet und sind uber die Dateisystemhierarchie (unterhalb von /sys/fs/cgroup/) oder uber Werkzeuge wie systemd-cgls(1) oder ps(1) verfugbar. (ps xawf -eo pid,user,cgroup,args ist besonders nutzlich, um alle Prozesse und die Systemd-Units, zu denen sie gehoren, aufzulisten.) Systemd ist zu verschiedenen etablierten Unix-Funktionalitaten, wie /etc/fstab oder den Utmp-Datenbanken, kompatibel. Systemd hat ein minimales Transaktionssystem: Falls eine Unit zum Start oder Herunterfahren aufgefordert wird, wird sie sich und alle Abhangigkeiten zu einer temporaren Transaktion hinzufugen. 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 Auftrage aus der Transaktion, die die Schleife entfernen konnten. Auch versucht Systemd, nicht wesentliche Auftrage in der Transaktion zu unterdrucken, die einen laufenden Dienst stoppen wurden. Schliesslich wird uberpruft, ob die Auftrage der Transaktion Auftragen 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 Auftragen zusammengefuhrt und zu der Ausfuhrungswarteschlange hinzugefugt. Effektiv bedeutet dies, dass Systemd vor der Ausfuhrung einer angefragten Aktion uberpruft, dass sie Sinn ergibt, sie falls moglich korrigiert und nur fehlschlagt, falls es wirklich nicht funktionieren kann. Beachten Sie, dass Transaktionen unabhangig vom Zustand einer Unit zur Laufzeit erstellt werden. Wird daher beispielsweise ein Startauftrag fur eine bereits gestartete Unit angefordert, wird er dennoch eine Transaktion erstellen und alle inaktiven Abhangigkeiten aufwecken (und gemass der definierten Abhangigkeiten eine Weiterleitung zu anderen Auftragen verursachen). Dies erfolgt, da der in die Warteschlange eingereihte Auftrag zum Zeitpunkt der Ausfuhrung mit dem Zustand der Ziel-Unit verglichen und als erfolgreich und abgeschlossen markiert wird, wenn beide zutreffen. Allerdings zieht dieser Auftrag auch andere Abhangigkeiten aufgrund der definierten Beziehungen herein und fuhrt daher in unserem Beispiel dazu, dass Start-Auftrage fur jede dieser inaktiven Units auch in die Warteschlange eingereiht werden. Units konnen dynamisch zum Systemstartzeitpunkt und zum Systemverwalter-Neuladezeitpunkt erstellt werden, beispielsweise basierend auf anderen Konfigurationsdateien oder auf von der Kernelbefehlszeile ubergebenen Parametern. Fur Details siehe systemd.generator(7). VERZEICHNISSE System-Unit-Verzeichnisse Der Systemd-Systemverwalter liest Unit-Konfigurationen aus verschiedenen Verzeichnissen. Pakete, die Unit-Dateien installieren mochten, sollten sie in dem durch pkg-config systemd --variable=systemdsystemunitdir zuruckgelieferten Verzeichnis ablegen. Weitere geprufte 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) verandern. Eine vollstandige Auflistung von Verzeichnissen wird in systemd.unit(5) bereitgestellt. Benutzer-Unit-Verzeichnisse Ahnliche Regeln gelten fur die Benutzer-Unit-Verzeichnisse. Allerdings wird hier der XDG-Basisverzeichnisspezifikation[5] zum Finden von Units gefolgt. Anwendungen sollten ihre Unit-Dateien in dem durch pkg-config systemd --variable=systemduserunitdir zuruckgelieferten Verzeichnis ablegen. Globale Konfiguration erfolgt in dem durch pkg-config systemd --variable=systemduserconfdir gemeldeten Verzeichnis. Die Befehle enable und disable des Werkzeugs systemctl(1) konnen sowohl mit globaler (d.h. fur alle Benutzer) als auch privater (fur einen Benutzer) Freigabe/Ausschaltung von Units umgehen. Eine vollstandige Auflistung von Verzeichnissen wird in systemd.unit(5) bereitgestellt. SIGNALE Der Dienste wartet auf die Signale verschiedener UNIX-Prozesse, die dazu verwandt werden konnen, verschiedene Aktionen asynchron zu erbitten. Die Signal-Handhabung wird sehr fruh im Systemstart aktiviert, bevor irgendwelche Prozesse aufgerufen werden. Allerdings muss ein uberwachender Container-Verwalter oder ahnliches, der plant, diese Aktionen mittels dieses Mechanismus zu erbitten, berucksichtigen, dass diese Funktionalitat nicht wahrend der allerfruhsten Initialisierungsphase verfugbar ist. Wie nachfolgend beschrieben wird wird eine sd_notify(3)-Nachricht ausgesandt, die das Feld X_SYSTEMD_SIGNALS_LEVEL=2 enthalt, sobald die Signalhandhaber aktiviert sind. Dies kann dazu verwandt werden, die Einreichung dieser Signale korrekt einzuplanen. SIGTERM Nach Empfang dieses Signals serialisiert der Systemd-Systemverwalter seinen Zustand, fuhrt sich selbst erneut aus und deseriealisiert den gespeicherten Zustand wieder. Dies ist grosstenteils aquivalent zu systemctl daemon-reexec. Systemd-Benutzerverwalter werden die Unit exit.target starten, wenn dieses Signal empfangen wird. Dies ist grosstenteils aquivalent 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 grosstenteils aquivalent 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 ausgelost. Beachten Sie, dass Drucken von Strg+Alt+Entf auf der Konsole dieses Signal auslosen wird. Hangt daher ein Neustart, ist das siebenmalige Drucken von Strg+Alt+Entf in zwei Sekunden eine relativ sichere Art, einen sofortigen Neustart auszulosen. 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 grosstenteils aquivalent 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 grosstenteils aquivalent 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 Ladt die komplette Daemon-Konfiguration neu. Dies ist grosstenteils aquivalent zu systemctl daemon-reload. SIGRTMIN+0 Betritt den Standardmodus, startet die Unit default.target. Dies ist grosstenteils aquivalent zu systemctl isolate default.target. SIGRTMIN+1 Betritt den Rettungsmodus, startet die Unit rescue.target. Dies ist grosstenteils aquivalent zu systemctl isolate rescue.target. SIGRTMIN+2 Betritt den Notfallmodus, startet die Unit emergency.service. Dies ist grosstenteils aquivalent zu systemctl isolate emergency.service. SIGRTMIN+3 Halt die Maschine an, startet die Unit halt.target. Dies ist grosstenteils aquivalent zu systemctl start halt.target --job-mode=replace-irreversibly. SIGRTMIN+4 Schaltet die Maschine aus, startet die Unit poweroff.target. Dies ist grosstenteils aquivalent zu systemctl start poweroff.target --job-mode=replace-irreversibly. SIGRTMIN+5 Startet die Maschine neu, startet die Unit reboot.target. Dies ist grosstenteils aquivalent zu systemctl start reboot.target --job-mode=replace-irreversibly. SIGRTMIN+6 Startet die Maschine mittels kexec neu, startet die Unit kexec.target. Dies ist grosstenteils aquivalent zu systemctl start kexec.target --job-mode=replace-irreversibly. SIGRTMIN+7 Startet den Benutzerraum neu, startet die Unit soft-reboot.target. Dies ist grosstenteils aquivalent zu systemctl start soft-reboot.target --job-mode=replace-irreversibly. Hinzugefugt in Version 254. SIGRTMIN+13 Halt 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. Hinzugefugt in Version 254. SIGRTMIN+20 Aktiviert die Anzeige von Statusmeldungen auf der Konsole, wie dies mit systemd.show_status=1 auf der Kernelbefehlszeile gesteuert wird. Um Ressourcenwettlauf-Bedingungen zu vermeiden, sollten Sie SetShowStatus() anstelle von SIGRTMIN+20 verwenden. Siehe org.freedesktop.systemd1(5). SIGRTMIN+21 Deaktiviert die Anzeige von Statusmeldungen auf der Konsole, wie dies mit systemd.show_status=0 auf der Kernelbefehlszeile gesteuert wird. Um Ressourcenwettlauf-Bedingungen zu vermeiden, sollten Sie SetShowStatus() anstelle von SIGRTMIN+21 verwenden. Siehe org.freedesktop.systemd1(5). SIGRTMIN+22 Setzt die Protokollierstufe des Diensteverwalters auf >>debug<<, in einer Art, die aquivalent 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 Prioritatsreihenfolge, 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. Hinzugefugt in Version 239. SIGRTMIN+24 Verlasst den Verwalter sofort (nur fur --user-Instanzen verfugbar). Hinzugefugt in Version 195. SIGRTMIN+25 Nach Empfang dieses Signals fuhrt der Systemd-Systemverwalter sich selbst erneut aus. Dies ist grosstenteils aquivalent zu systemctl daemon-reexec, ausser dass es asynchron erfolgt. Der Systemd Systemverwalter behandelt dieses Signal auf die gleiche Art wie SIGTERM. Hinzugefugt in Version 250. SIGRTMIN+26 Stellt das Protokollierziel wieder auf seinen konfigurierten Wert her. Der konfigurierte Wert wird, in dieser Prioritatsreihenfolge, 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. Hinzugefugt in Version 239. SIGRTMIN+27, SIGRTMIN+28 Setzt das Protokollierziel auf >>console<< bei SIGRTMIN+27 (oder >>kmsg<< bei SIGRTMIN+28), in einer Art aquivalent zu systemd.log_target=console (oder systemd.log_target=kmsg bei SIGRTMIN+28) auf der Kernelbefehlszeile. Hinzugefugt in Version 239. UMGEBUNGSVARIABLEN Der Umgebungsblock fur den Systemverwalter wird anfanglich vom Kernel gesetzt. (Insbesondere werden >>Schlussel=Wert<<-Zuweisungen auf der Kernelbefehlszeile in Umgebungsvariablen fur PID 1 umgewandelt). Fur 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 fur alle Dienste, einschliesslich user@.service. Mittels der Einstellungen Environment= und EnvironmentFile= fur user@.service konnen zusatzliche Eintrage (wie bei jedem anderen Dienst auch) konfiguriert werden (siehe systemd.exec(5)). Es konnen auch zusatzliche 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 fur ausgegebene Meldungen (Meldungen mit einer hoheren Protokollierstufe, d.h. weniger wichtige, werden unterdruckt). 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 07. Siehe syslog(3) fur weitere Informationen. Jedem Wert kann optional eine Zeichenkette aus console, syslog, kmsg oder journal gefolgt von einem Doppelpunkt vorangestellt werden, um die maximale Protokollierstufe fur dieses spezielle Protokollierziel zu setzen (d.h. SYSTEMD_LOG_LEVEL=debug,console:info legt fest, dass auf der Stufe >>debug<< protokolliert werden soll, ausser beim Protokollieren auf die Konsole, die auf Stufe >>info<< erfolgen soll). Beachten Sie, dass die globale maximale Protokollierstufe Prioritat gegenuber jeder zielbezogenen maximalen Protokollierstufe hat. Dies kann mit --log-level= ausser Kraft gesetzt werden. $SYSTEMD_LOG_COLOR Ein logischer Wert. Falls true, werden auf das TTY geschriebene Nachrichten gemass ihrer Prioritat eingefarbt. Dies kann mit --log-color= ausser Kraft gesetzt werden. $SYSTEMD_LOG_TIME Ein logischer Wert. Falls true, wird den Protokollnachrichten der Konsole ein Zeitstempel vorangestellt. Dies kann mit --log-time= ausser Kraft gesetzt werden. Hinzugefugt in Version 246. $SYSTEMD_LOG_LOCATION Ein logischer Wert. Falls true, wird den Protokollnachrichten ein Dateiname und eine Zeilenummer in dem Quellcode, aus dem die Nachrichten stammen, vorangestellt. Dies kann mit --log-location= ausser Kraft gesetzt werden. $SYSTEMD_LOG_TID Ein logischer Wert. Falls true, wird den Nachrichten die aktuelle numerische Thread-Kennung (TID) vorangestellt. Hinzugefugt in Version 247. $SYSTEMD_LOG_TARGET Das Ziel fur Protokolliernachrichten. Entweder console (auf das angehangte TTY protokollieren), console-prefixed (auf das angehangte TTY protokollieren, aber die Protokollierstufe und >>Einrichtung<< voranstellen, siehe syslog(3)), kmsg (in den zirkularen Kernel-Protokollpuffer protokollieren), journal (in das Journal protokollieren), journal-or-kmsg (in das Journal protokollieren, falls verfugbar, und andernfalls nach Kmsg), auto (das geeignete Protokollierziel automatisch ermitteln, die Vorgabe) oder null (die Protokollierung deaktivieren). Dies kann mit --log-target= ausser Kraft gesetzt werden. $SYSTEMD_LOG_RATELIMIT_KMSG Ob Kmsg ratenlimitiert werden soll oder nicht. Akzeptiert einen logischen Wert. Standardmassig >>true<<. Falls deaktiviert, wird Systemd die nach Kmsg geschriebenen Meldungen nicht ratenlimitieren. Hinzugefugt in Version 254. $XDG_CONFIG_HOME, $XDG_CONFIG_DIRS, $XDG_DATA_HOME, $XDG_DATA_DIRS Der Systemd-Benutzerverwalter verwendet diese Variablen in Ubereinstimmung mit der XDG-Basisverzeichnisspezifikation[5], um seine Konfiguration zu finden. $SYSTEMD_UNIT_PATH, $SYSTEMD_GENERATOR_PATH, $SYSTEMD_ENVIRONMENT_GENERATOR_PATH Steuert, wo Systemd nach Unit-Dateien und Generatoren schaut. Diese Variablen konnen eine Liste von Pfaden, getrennt durch Doppelpunkte (>>:<<), enthalten. Ist dies gesetzt und endet mit der leeren Komponente (>>:<<), wird diese Liste der normalen Gruppe an Pfaden vorangestellt. Andernfalls ersetzt die angegebene Liste die normale Gruppe an Pfaden. $SYSTEMD_PAGER, $PAGER Zu verwendendes Textanzeigeprogramm, wenn --no-pager nicht angegeben ist. Falls gesetzt, wird $SYSTEMD_PAGER verwandt, andernfalls $PAGER. setzt $PAGER ausser Kraft. Falls weder $SYSTEMD_PAGER noch $PAGER gesetzt sind, wird eine Reihe wohlbekannter Implementierungen von Textanzeigeprogrammen der Reihe nach ausprobiert, einschliesslich less(1) und more(1), bis eines gefunden wird. Falls keine Implementierung eines Textanzeigeprogramms gefunden wird, wird keines aufgerufen. Setzen dieser Umgebungsvariablen auf die leere Zeichenkette oder den Wert >>cat<< ist aquivalent zur Ubergabe von --no-pager. Beachten Sie: Falls $SYSTEMD_PAGERSECURE nicht gesetzt ist, konnen $SYSTEMD_PAGER und $PAGER nur zum Deaktivieren des Seitenanzeigeprogramms (mit >>cat<< oder >><<) verwandt werden und werden ansonsten ignoriert. $SYSTEMD_LESS Setzt die an less ubergebenen Optionen (standardmassig >>FRSXMK<<) ausser Kraft. Benutzer konnten insbesondere zwei Optionen andern 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 zuruck. Falls der Wert von $SYSTEMD_LESS kein >>K<< enthalt 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 standardmassig gesetzt, damit die Darstellung von Befehlen selbst nach dem Beenden des Textanzeigeprogramms sichtbar bleibt. Allerdings stehen dadurch einige Funktionen des Textanzeigeprogramms nicht zur Verfugung; insbesondere ist das Scrollen in der Ausgabe mit der Maus nicht moglich. Beachten Sie, dass das Setzen der regularen Umgebungsvariablen $LESS keine Auswirkungen auf die Ausfuhrung von less(1) durch systemd(1)-Werkzeuge hat. Siehe less(1) fur weitere Ausfuhrungen. $SYSTEMD_LESSCHARSET Setzt den an less zu ubergebenden Zeichensatz (standardmassig >>utf-8<<, falls das aufrufende Terminal als UTF-8-kompatibel erkannt wurde) ausser Kraft. Beachten Sie, dass das Setzen der regularen Umgebungsvariablen $LESSCHARSET keine Auswirkungen auf die Ausfuhrungen von less(1) durch systemd(1)-Werkzeuge hat. $SYSTEMD_PAGERSECURE Typische Seitenanzeigeprogramme wie less(1) unterstutzen nebem dem seitenweisen Anzeigen (d.h. dem Durchlaufen der Ausgabe) das Offnen von oder Schreiben in andere Dateien und die Ausfuhrung von beliebigen Shell-Befehlen. Werden Befehle mit erhohten Berechtigungen, beispielsweise unter sudo(8) oder pkexec(1), aufgerufen, wird das Seitenanzeigeprogramm zur Sicherheitsgrenze. Es muss darauf geachtet werden, dass nur Programme mit streng begrenzter Funktionalitat als Seitenanzeigeprogramm verwandt werden und unerwunschte interaktive Funktionalitaten wie das Offnen oder Erstellen von neuen Dateien oder das Starten von Subprozessen nicht erlaubt sind. Der >>Sichere Modus<< fur das Seitenanzeigeprogramm kann wie nachfolgend beschrieben aktiviert werden, falls das Seitenanzeigeprogramm dies unterstutzt (die meisten Seitenanzeigeprogramme sind nicht so geschrieben, dass sie dies berucksichtigen). Es wird empfohlen, den >>Sicheren Modus<< explizit zu aktivieren oder das Seitenanzeigeprogramm komplett mittels --no-pager oder PAGER=cat zu deaktivieren, wenn nicht vertrauenswurdigen Benutzern die Ausfuhrung von Programmen mit erhohten Privilegien erlaubt wird. Diese Option akzeptiert ein logisches Argument. Ist es auf >>true<< gesetzt, wird der >>Sichere Modus<< des Seitenanzeigeprogramms aktiviert. Im >>Sicheren Modus<< wird LESSSECURE=1 beim Aufruf des Seitenanzeigeprogramms gesetzt. Dies weist das Seiteanzeigeprogramm an, Befehle zum Offnen oder Erstellen von neuen Dateien sowie das Starten von Subprozessen zu deaktivieren. Derzeit ist nur von less(1) bekannt, dass es diese Variable versteht und den >>Sicheren Modus<< implementiert. Ist diese Variable auf >>false<< gesetzt, unterliegt das Seitenanzeigeprogramm keinen Beschrankungen. Setzen auf SYSTEMD_PAGERSECURE=0 oder das Beibehalten der Variable von der geerbten Umgebung konnte den Benutzern die Ausfuhrung beliebiger Befehle erlauben. Ist $SYSTEMD_PAGERSECURE nicht gesetzt, versuchen die Systemd-Werkzeuge automatisch herauszufinden, ob der >>Sicheren Modus<< aktiviert werden soll und ob das Seitenanzeigeprogramm dies unterstutzt. Der >>Sichere Modus<< wird aktiviert, falls die effektive UID nicht mit der UID des Eigentumers der Anmeldesitzung ubereinstimmt, siehe geteuid(2) und sd_pid_get_owner_uid(3), oder wenn die Ausfuhrung unter Werkzeugen wie sudo(8) oder ahnlichem erfolgt ($SUDO_UID ist gesetzt [6]). In diesen Fallen wird SYSTEMD_PAGERSECURE=1 gesetzt und Seitenanzeigeprogramme, von denen nicht bekannt ist, dass sie den >>Sicheren Modus<< unterstutzen, werden uberhaupt nicht verwandt. Beachten Sie, dass diese automatische Erkennung nur die typischsten Mechanismen zur Erlangung von Privilegien abdeckt und dem Komfort dient. Es wird empfohlen, explizit $SYSTEMD_PAGERSECURE zu setzen oder das Seitenanzeigeprogramm zu deaktivieren. Beachten Sie, dass auch $SYSTEMD_PAGERSECURE gesetzt sein muss, damit die Variablen $SYSTEMD_PAGER oder $PAGER (ausser zum Deaktivieren des Seitenanzeigeprogramms) berucksichtigt werden. $SYSTEMD_COLORS Akzeptiert ein logisches Argument oder einen besonderen Wert. Standardmassig (nicht gesetzt) werden systemd und zugehorige Hilfswerkzeuge in ihrer Ausgabe Farben verwenden, falls dies moglich ist. Falls $COLORTERM auf >>truecolor<< oder >>24bit<< gesetzt ist, werden 24-bit-Farben aktiviert, ansonsten 256 Farben, ausser wenn $NO_COLOR gesetzt ist oder $TERM anzeigt, dass Farben deaktiviert sind. true Identisch zu nicht gesetzt, ausser dass $NO_COLOR ignoriert wird. false Die Ausgabe erfolgt monochrom. >>16<<, >>256<<, >>24bit<< Verwendet immer die 16, 256 bzw. 24-bit-ANSI-Basisfarben. >>auto-16<<, >>auto-256<<, >>auto-24bit<< Verwendet die angegebene Menge an Farben, abhangig von $TERM und womit die Konsole verbunden ist. $SYSTEMD_URLIFY Dies muss ein logischer Wert sein. Er steuert, ob anklickbare Links fur Terminal-Emulatoren, die dies unterstutzen, erstellt werden sollen. Dies kann angegeben werden, um die Entscheidung, die systemd basierend auf $TERM und anderen Bedingungen trifft, ausser Kraft zu setzen. $LISTEN_PID, $LISTEN_PIDFDID, $LISTEN_FDS, $LISTEN_FDNAMES Wird durch Systemd fur uberwachte Prozesse wahrend Socket-basierter Aktivierung gesetzt. Siehe sd_listen_fds(3) fur weitere Informationen. $NOTIFY_SOCKET Wird durch den Diensteverwalter fur seine Dienste fur die Status- und Bereitschaftsbenachrichtigungen gesetzt. Wird auch vom Diensteverwalter zur Benachrichtigungen von uberwachenden Container-Verwaltern oder ubergeordneten Dienstervewaltern uber seine eigenen Fortschritt konsumiert. Siehe sd_notify(3) und den relevanten nachfolgenden Abschnitt fur weitere Informationen. Fur weitere Umgebungsvariablen, die von Systemd und seinen verschiedenen Komponenten verstanden werden, siehe Bekannte Umgebungsvariablen[7]. KERNEL-BEFEHLSZEILE Bei der Ausfuhrung als Systeminstanz wertet Systemd eine Reihe von nachfolgend aufgefuhrten Optionen aus. Diese konnen als Kernelbefehlszeilenargumente angegeben werden, die von einer Reihe von Quellen ausgewertet werden, abhangig von der Umgebung, in der Systemd ausgefuhrt wird. Beim Betrieb innerhalb eines Linux-Containers werden diese Optionen, die von der Befehlszeile ubergeben werden, von Systemd selbst ausgewertet, neben allen Befehlzeilenoptionen, die in obigem Abschnitt Options aufgefuhrt sind. Beim Betrieb von ausserhalb von Linux-Containern werden diese Argumente stattdessen aus /proc/cmdline ausgewertet. Die folgenden Variablen werden verstanden: systemd.unit=, rd.systemd.unit= Setzt die beim Systemstart zu aktivierende Unit ausser Kraft. Standardmassig default.target. Dies kann temporar zum Starten in eine andere Systemstart-Unit verwandt werden, beispielsweise rescue.target oder emergency.service. Siehe systemd.special(7) fur Details uber diese Units. Wird der Option >>rd.<< vorangestellt, dann wird sie nur in der Initrd berucksichtigt, wahrend die Option ohne diese Zeichenkette am Anfang nur im Hauptsystem berucksichtigt 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 absturzt. Andernfalls wird kein Speicherauszug erstellt. Standardmassig aktiviert. Hinzugefugt 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 163) angegeben ist, wird der Systemverwalter (PID 1) die angegebene Anzahl an virtuellen Terminals erstellen, wenn er absturzt. Standardmassig deaktiviert, was bedeutet, dass dies nicht versucht wird. Falls auf aktiviert gesetzt, wird stattdessen das virtuelle Terminal, auf den die Kernelnachrichten geschrieben werden, verwandt. Hinzugefugt in Version 233. systemd.crash_shell Akzeptiert ein logisches Argument oder aktiviert die Option, falls ohne Argument angegeben. Falls aktiviert, wird der Systemverwalter (PID 1) eine Shell starten, wenn er absturzt. Andernfalls wird keine Shell gestartet. Aus Sicherheitsgrunden standardmassig deaktiviert, da die Shell nicht durch Passwortauthentifizierung geschutzt ist. Hinzugefugt in Version 233. systemd.crash_action= Akzeptiert entweder >>freeze<<, >>reboot<< oder >>poweroff<<. Standardmassig >>freeze<<. Falls auf >>freeze<< gesetzt, wird das System auf unbestimmte Zeit hangen, wenn der Systemverwalter (PID 1) absturzt. Falls auf >>reboot<< gesetzt, wird der Systemverwalter (PID 1) die Maschine automatisch nach einer Verzogerung von 10 Sekunden neu starten, wenn er absturzt. Falls auf >>poweroff<< gesetzt, wird der Systemverwalter (PID 1) die Maschine ausschalten, wenn er absturzt. Falls mit systemd.crash_shell kombiniert, wird die konfigurierte Absturzaktion ausgefuhrt, nachdem die Shell sich beendet. Hinzugefugt in Version 256. systemd.confirm_spawn Akzeptiert ein logisches Argument oder einen Pfad zu einer virtuellen Konsole, auf der Bestatigungsmeldungen 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 Bestatigung 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 ubergebenen Namen beschriebene stattdessen verwandt. Standardmassig deaktiviert. Hinzugefugt in Version 233. systemd.service_watchdogs= Akzeptiert ein logisches Argument. Falls deaktiviert, werden alle Laufzeit-Watchdogs fur Dienste (WatchdogSec=) und Notfallaktionen (z.B. OnFailure= oder StartLimitAction=) durch den Systemverwalter (PID 1) ignoriert, siehe systemd.service(5). Standardmassig deaktiviert, d.h. Watchdogs und Fehlschlagaktionen werden normal verarbeitet. Der Hardware-Watchdog ist durch diese Option nicht betroffen. Hinzugefugt 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 uber Fehler angezeigt, der Systemstart erfolgt ansonsten still. auto verhalt sich wie false, bis es beim Systemstart zu signifikanten Verzogerungen kommt. Standardmassig aktiviert, ausser quiet wird als Kernelbefehlszeilenoption angegeben. In letzterem Fall ist die Vorgabe error. Ist dies angegeben, setzt es die Konfigurationsdateioption ShowStatus= des Systemverwalters ausser Kraft, siehe systemd-system.conf(5). Hinzugefugt 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 ausser Kraft, siehe systemd-system.conf(5). Hinzugefugt 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 konnen 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 fur alle Dienste und Sockets. D.h. steuert die Vorgabe fur StandardOutput= und StandardError= (siehe systemd.exec(5) fur Details). Akzeptiert einen aus inherit, null, tty, journal, journal+console, kmsg, kmsg+console. Falls kein Argument angegeben wird, ist die Vorgabe fur systemd.default-standard-output= journal und fur 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 hinzugefugt 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. Hauptsachlich fur den Systemstart uber das Netzwerk gedacht, bei dem die gleiche Maschinenkennung fur jeden Systemstart erwunscht ist. Hinzugefugt 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) fur Details. Akzeptiert ein Paar bestehend aus Zugangsberechtigung und -namen, getrennt durch Doppelpunkt. Der Parameter systemd.set_credential= erwartet den Zugangsberechtigungswert in wortlicher Textform, der Parameter systemd.set_credential_binary= akzeptiert als Base64 kodierte Binardaten. Beachten Sie, dass von nicht privilegierten Programmen in /proc/cmdline typischerweise auf die Kernel-Befehlszeile zugegriffen werden kann. Daher ist dieser Mechanismus nicht fur die Ubertragung vertraulicher Daten geeignet. Verwenden Sie ihn nur fur Daten, die nicht vertraulich sind (z.B. offentliche Schlussel/Zertifikate statt privater Schlussel) oder in Test-/Fehlersuchumgebungen. Siehe die Dokumentation der System- und Dienste-Zugangsberechtigungen[8] fur weitere Details. Hinzugefugt in Version 251. systemd.import_credentials= Akzeptiert ein logisches Argument. Falls false, deaktiviert den Import von Zugangsberechtigungen aus der Kernel-Befehlszeile, der DMI/SMBIOS-OEM-Zeichenketten-Tabelle, dem qemu_fw_cfg-Sybsystem oder dem EFI-Kernel-Rumpf. Hinzugefugt in Version 251. quiet Schaltet Statusausgaben beim Systemstart aus, ahnlich wie dies systemd.show_status=no tate. Beachten Sie, dass diese Option auch vom Kernel selbst gelesen wird und Kernelprotokollierungsausgaben deaktiviert. Die Ubergabe dieser Option schaltet daher die normale Ausgabe sowohl vom Systemverwalter als auch dem Kernel aus. Hinzugefugt in Version 186. debug Schaltet den Fehlersuchmodus ein. Dies ist aquivalent zu systemd.log_level=debug. Beachten Sie, dass diese Option auch vom Kernel selbst gelesen wird und die Kernel-Fehlersuchausgabe aktiviert. Die Ubergabe dieser Option schaltet daher die Fehlersuchausgabe sowohl vom Systemverwalter als auch des Kernels ein. Hinzugefugt in Version 205. emergency, rd.emergency, -b Systemstart in den Notfallmodus. Dies ist zu systemd.unit=emergency.target bzw. rd.systemd.unit=emergency.target aquivalent und wird aus Kompatibilitatsgrunden und da es leichter zu tippen ist, bereitgestellt. Hinzugefugt 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 aquivalent und wird aus Kompatibilitatsgrunden und da es leichter zu tippen ist, bereitgestellt. Hinzugefugt in Version 186. 2, 3, 4, 5 Systemstart in den angegebenen veralteten SysV-Runlevel. 2, 3 und 4 sind zu systemd.unit=multi-user.target aquivalent und 5 ist zu systemd.unit=graphical.target aquivalent und sie werden aus Kompatibilitatsgrunden und da es leichter zu tippen ist, bereitgestellt. Hinzugefugt 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 ausser Kraft. Fur weitere Informationen siehe locale.conf(5) und locale(7). Hinzugefugt in Version 186. Fur weitere von Komponenten des Kernbetriebssystems verstandene Kernelbefehlszeilenparameter siehe kernel-command-line(7). SYSTEMZUGANGSBERECHTIGUNGEN Wahrend 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: o 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. o 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.) o Zugangsberechtigungen konnen wie oben beschrieben uber die Kernelbefehlszeile mittels des Parameters systemd.set-credential= ubergeben werden. o Zugangsberechtigungen konnen von der UEFI-Umgebung mittels systemd-stub(7) ubergeben werden. o Wenn der Diensteverwalter wahrend des Ubergangs 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 ubergebenen Zugangsberechtigungen zu sehen: # systemd-creds --system list Siehe die Dokumentation der System- und Dienste-Zugangsberechtigungen[8] fur weitere Details. Wenn der Diensteverwalter als PID 1 ausgefuhrt wird, verwendet er die folgenden Systemzugangsberechtigungen: vmm.notify_socket Enthalt eine AF_VSOCK- oder AF_UNIX-Adresse, an die eine Benachrichtigungsmeldung READY=1 gesandt werden soll, wenn das System den Start abgeschlossen hat. Siehe sd_notify(3) und den nachsten Abschnitt fur weitere Informationen. Beachten Sie, dass im Falle von Hypervisoren, die SOCK_DGRAM uber AF_VSOCK nicht unterstutzen stattdessen SOCK_SEQPACKET versucht wird. Der Inhalt der Zugangsberechtigung fur AF_VSOCK sollte eine Zeichenkette in der Form >>vsock:CID:PORT<< sein. >>vsock-stream<<, >>vsock-dgram<< und >>vsock-seqpacket<< konnen anstelle von >>vsock<< verwandt werden, um den entsprechenden Socket-Typ zu erzwingen. Diese Funktionalitat ist fur Maschinenverwalter oder andere Prozesse auf dem Rechner nutzlich, um eine Benachrichtigung uber VSOCK zu erhalten, wenn eine virtuelle Maschine mit dem Starten fertig ist. Hinzugefugt 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. Hinzugefugt in Version 254. Eine Liste von Systemzugangsberechtigungen, die verschiedene andere Komponenten von Systemd konsumieren, finden Sie in systemd.system-credentials(7). BEREITSCHAFTSPROTOKOLL Der Diensteverwalter implementiert ein Bereitschafts-Benachrichtigungsprotokoll, sowohl zwischen dem Verwalter und seinen Diensten (d. zu den nachgeordneten Teilen) als auch zwischen dem Verwalter und einem moglichen ubergeordneten Uberwacher (letzerer konnte ein Maschinen- oder Container-Verwalter sein, oder im Falle eines benutzerbezogenen Diensteverwalters die Instanz des System-Diensteverwalters). Das grundlegende Protokoll (und die dafur vorgeschlagene API) sind in sd_notify(3) beschrieben. Das vom Diensteverwalter (einschliesslich PID 1) fur die Meldung der Bereitschaft an seinen eigenen Supervisor verwandte Benachrichtigungs-Socket wird mittels der Umgebungsvariablen $NOTIFY_SOCKET gesetzt (siehe oben). Da diese nur fur Container-Verwalter und fur die benutzerbezogene Instanz des Diensteverwalters setzbar ist, ist ein zusatzlicher Mechanismus zur Konfiguration davon verfugbar, der insbesondere fur VM-Umgebungen gedacht ist: Die Systemzugangsberechtigung vmm.notify_socket (siehe oben) kann mittels SMBIOS-Type-11-Lieferantenzeichenketten auf ein geeignetes Socket (typischerweise der Art AF_VSOCK) gesetzt werden. Details hierzu finden Sie weiter oben. Das Benachrichtigungsprotokoll vom Diensteverwalter zu ubergeordneten Supervisoren unterstutzt eine Reihe von Erweiterungsfeldern, die es einem Supervisor ermoglichen, Informationen uber bestimmte Eigenschaften des Systems zu erlangen und dessen Systemstartvorgang nachzuverfolgen. Konkret werden die folgenden Felder gesandt: o Eine Meldung X_SYSTEMD_HOSTNAME=\[u2026] wird ausgesandt, sobald der anfangliche Rechnername fur das System bestimmt wurde. Beachten Sie, dass wahrend der weiteren Laufzeit der Rechnername programatisch geandert werden kann und (derzeit) in diesem Fall keine weiteren Benachrichtigungen ausgesandt werden. Hinzugefugt in Version 256. o Eine Meldung X_SYSTEMD_MACHINE_ID= wird ausgesandt, sobald die Maschinenkennung des Systems bestimmt wurde. Siehe machine-id(5) zu Details. Hinzugefugt in Version 256. o Eine Meldung X_SYSTEMD_SIGNALS_LEVEL= wird ausgesandt, sobald der Diensteverwalter die oben beschriebenen verschiedenen UNIX-Prozesssignalhandhaber installiert hat. Der Wert des Feldes ist eine vorzeichenlose Ganzzahl, formatiert als dezimale Zeichenkette. Er zeigt die unterstutzte UNIX-Prozesssignal-Funktionalitatsstufe des Diensteverwalters an. Derzeit ist nur eine einzelne Funktionalitatsstufe definiert: o X_SYSTEMD_SIGNALS_LEVEL=2 deckt die oben beschriebenen verschiedenen UNIX-Prozesssignale ab. Diese sind eine Obermenge der durch das historische SysV-Init-System unterstutzten Signale Signale, die an PID 1 vor dieser Meldung gesandt werden, konnten nicht korrekt behandelt werden. Ein Konsument dieser Meldungen sollte die Werte als eine vorzeichenfrei Ganzzahl auswerten, die die Unterstutzungsstufe anzeigt. Aktuell ist nur die erwahnte Stufe 2 definiert, aber spater konnten zusatzliche Stufen mit grosseren Ganzzahlen definiert werden, die eine Obermenge des aktuell definierten Verhaltens implementieren. Hinzugefugt in Version 256. o Meldungen X_SYSTEMD_UNIT_ACTIVE= und X_SYSTEMD_UNIT_INACTIVE= werden fur jede Ziel-Unit ausgesandt, wenn sie aktiv werden oder aufhoren, aktiv zu sein. Dies ist zur Nachverfolgung des Systemstartvorgangs und deren Funktionalitat nutzlich. Beispielsweise ist SSH-Zugriff typischerweise verfugbar, sobald die Meldung erfolgt ist, dass die Unit ssh-access.target gestartet wurde, siehe systemd.special(7) zu Details. Hinzugefugt in Version 256. o Eine Meldung X_SYSTEMD_SHUTDOWN= wird sehr kurz vor dem Herunterfahren des Systems ausgesandt. Der Wert ist einer der Zeichenketten >>reboot<<, >>halt<<, >>poweroff<<, >>kexec<< und zeigt an, welche Art von Herunterfahren ausgefuhrt wird. Hinzugefugt in Version 256. o Eine Meldung X_SYSTEMD_REBOOT_PARAMETER= wird auch sehr kurz bevor das System herunterfahrt ausgesandt. Ihr Wert ist das Neustartargument, wie es mit systemctl --reboot-argument= konfiguriert ist. Hinzugefugt in Version 256. Beachten Sie, dass diese Erweiterungsfelder zusatzlich zu den regularen Benachrichtigungen >>READY=1<< und >>RELOADING=1<< gesandt werden. OPTIONEN Systemd wird nur sehr selten direkt aufgerufen, da es fruh gestartet wird und bereits lauft, 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 aufgefuhrten Optionen hauptsachlich zur Fehlersuche und fur besondere Zwecke nutzlich. Optionen zur Selbstprufung und Fehlersuche Diese Optionen werden zum Testen und zur Selbstprufung 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. Hinzugefugt in Version 239. --test Bestimmt die anfangliche Hochfahrtransaktion (d.h. die Liste der beim Hochfahren in die Warteschlange eingereihten Auftrage), gibt sie aus und beendet sich, ohne tatsachlich irgend einen der bestimmten Auftrage auszufuhren. Diese Option ist nur zur Fehlersuche nutzlich. Beachten Sie, dass wahrend des regularen Hochfahrens des Diensteverwalters Units, die von dieser Aktion nicht angezeigt werden, gestartet werden konnten, da Hardware, Sockets, Busse oder andere Arten von Aktivierungen zusatzliche Auftrage wahrend der Ausfuhrung der Transaktion hinzufugen konnnten. Verwenden Sie --system, um die anfangliche Transaktion des Systemdiensteverwalters zu erbitten (was die implizite Vorgabe ist). Kombinieren Sie mit --user, um stattdessen die anfangliche Transaktion fur den benutzerbezogenen Diensteverwalter zu erbitten. --system, --user Wahlt aus, ob die anfangliche Transaktion fur die Systeminstanz oder fur die benutzerbezogene Instanz berechnet werden soll, wenn zusammen mit --test verwandt. Diese Option hat keine Wirkung ohne --test, da wahrend des regularen (d.h. ohne --test) Aufrufs der Diensteverwalter automatisch erkennen wird, ob er im System- oder benutzerbezogenen Modus agieren soll, indem er pruft, 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 lauft, nicht unterstutzt 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<< aufgefuhrten Optionen. Beide Formen konnen gleichwertig fur den Systemverwalter verwandt werden, aber es wird empfohlen, in diesem Zusammenhang die oben aufgefuhrten 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 hoheren 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 verandern (siehe systemd-user.conf(5)). Siehe den obigen Abschnitt >>Umgebungsvariablen<< fur 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 Kernspeicherabzuge 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). Hinzugefugt in Version 227. --crash-shell Fuhrt beim Systemabsturz eine Shell aus. Dieser Schalter hat beim Betrieb als Benutzerinstanz keinen Effekt. Siehe systemd.crash_shell= weiter oben. --crash-action= Legt fest, was beim Absturz des Systemverwalters (PID 1) getan werden soll. Dieser Schalter hat beim Betrieb von systemd als Benutzerinstanz keinen Effekt. Siehe systemd.crash_action weiter oben. Hinzugefugt in Version 256. --confirm-spawn Beim Offnen von Prozessen um Bestatigung bitten. Dieser Schalter hat beim Betrieb als Benutzerinstanz keinen Effekt. Siehe systemd.confirm_spawn weiter oben. --show-status Zeigt knappe Unit-Statusinformationen wahrend des Hochfahrens und Herunterfahrens auf der Konsole. Siehe systemd.show_status oben. Hinzugefugt in Version 244. --log-color Hebt wichtige Protokollmeldungen hervor. Siehe systemd.log_color oben. Hinzugefugt in Version 244. --log-level= Setzt Protokollierstufe. Siehe systemd.log_level weiter oben. --log-location Schliesst den Ort im Code in Protokollmeldungen ein. Siehe systemd.log_location oben. Hinzugefugt 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. Hinzugefugt in Version 246. --machine-id= Setzt die auf der Festplatte gesetzte Maschinenkennung ausser Kraft. Siehe systemd.machine_id= oben. Hinzugefugt in Version 229. --service-watchdogs Global alle Dienste-Watchdog-Zeituberschreitungen und Notfallaktionen aktivieren/deaktivieren. Siehe systemd.service_watchdogs weiter oben. Hinzugefugt in Version 237. --default-standard-output=, --default-standard-error= Setzt die Vorgabe-Standardausgabe und -Fehlerausgabe fur alle Dienste bzw. Sockets. Siehe systemd.default_standard_output= und systemd.default_standard_error= oben. SYSTEMUHR-EPOCH Wenn systemd gestartet oder neugestartet wird, konnte es die Systemuhr auf die >>Epoch<< stellen. Dieser Mechanismus wird verwandt, um sicherzustellen, dass die Uhr einigermassen vernunftig initialisiert bleibt und uber Neustarts hinweg grob monoton verlauft, falls keine lokale, Batterie-gestutzte RTC vorhanden ist oder diese nicht korrekt funktioniert. Der Epoch ist das kleinste Datum, uber dem die Systemuhrzeit als korrekt gesetzt angenommen werden kann. Bei der Initialisierung wird die lokale Uhr auf die Epoch vorgestellt, falls sie auf einen niederigeren Wert gestellt war. Als Spezialfall wird die Systemuhr auf die Epoch zuruckgestellt, falls die lokale Uhr hinreichend weit in der Zukunft ist (standardmassig 15 Jahre, aber dies kann zum Compile-Zeitpunkt konfiguriert werden). Die Epoch wird auf das hochste der folgenden gesetzt: Dem Bauzeitpunkt von Systemd, der Veranderungszeit (>>mtime<<) von /usr/lib/clock-epoch und der Veranderungszeit von /var/lib/systemd/timesync/clock. DATEIEN /run/systemd/notify Daemon-Statusbenachrichtigungs-Socket. Dies ist ein AF_UNIX-Datagramm-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 fur Systemd privat und sollte in externen Projekten nicht verwandt werden. /usr/lib/clock-epoch Die Veranderungszeit (>>mtime<<) dieser Datei wird fur die Zeit-Epoch genutzt, siehe den vorherigen Abschnitt. Hinzugefugt in Version 247. /var/lib/systemd/timesync/clock Die Veranderungszeit (>>mtime<<) dieser Datei wird von systemd-timesyncd.service(8) aktualisiert. Falls vorhanden, wird die Veranderungszeit dieser Datei fur die Epoch verwandt, siehe den vorherigen Abschnitt. Hinzugefugt in Version 257. 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. SIEHE AUCH Die Systemd-Homepage[9], systemd-system.conf(5), locale.conf(5), systemctl(1), journalctl(1), systemd-notify(1), daemon(7), sd-daemon(3), org.freedesktop.systemd1(5), systemd.unit(5), systemd.special(7), pkg-config(1), kernel-command-line(7), bootup(7), systemd.directives(7), org.freedesktop.systemd1(5) Fur weitere Informationen uber die Konzepte und Ideen hinter Systemd wird auf das Ursprungliches Designdokument[10] verwiesen. ANMERKUNGEN 1. Schnittstellenportabilitats- und -stabilitatszusage https://systemd.io/PORTABILITY_AND_STABILITY/ 2. Container-Schnittstelle https://systemd.io/CONTAINER_INTERFACE 3. Initrd-Schnittstelle https://systemd.io/INITRD_INTERFACE/ 4. Control-Gruppen v2 https://docs.kernel.org/admin-guide/cgroup-v2.html 5. XDG-Basisverzeichnisspezifikation https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html 6. Es wird fur andere Werkzeuge empfohlen, $SUDO_UID geeignet zu setzen und zu uberprufen und es als allgemeine Schnittstelle zu behandeln. 7. Bekannte Umgebungsvariablen https://systemd.io/ENVIRONMENT 8. System- und Dienste-Zugangsberechtigungen https://systemd.io/CREDENTIALS 9. Systemd-Homepage https://systemd.io/ 10. Ursprungliches Designdokument https://0pointer.de/blog/projects/systemd.html UBERSETZUNG Die deutsche Ubersetzung dieser Handbuchseite wurde von Helge Kreutzmann erstellt. Diese Ubersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 3 oder neuer bezuglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG ubernommen. Wenn Sie Fehler in der Ubersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an die Mailingliste der Ubersetzer . systemd 260.2 SYSTEMD(1)