[LINUX] Mann systemd japanische Übersetzung

Japanische Übersetzung des Handbuchs von man systemd.

Name

systemd, init --systemd Manager, der Systeme und Dienste verwaltet.

Überblick

/lib/systemd/systemd [OPTIONS...]
init [OPTIONS...] {COMMAND}

Erläuterung

systemd ist ein Manager, der Systeme und Dienste für das Linux-Betriebssystem verwaltet. Wenn es beim Start als erster Prozess ausgeführt wird (als PID 1), fungiert es als Init-System, das Userspace-Dienste startet und verwaltet.

Wenn aus Gründen der SysV-Kompatibilität systemd als init aufgerufen wird und die PID nicht 1 ist, wird telinit ausgeführt und alle Befehlszeilenargumente werden unverändert übergeben. Das heißt, init und telinit sind ungefähr gleich, wenn sie von einer normalen Anmeldesitzung aufgerufen werden. Weitere Informationen finden Sie unter telinit (8).

Wenn Sie systemd als Systeminstanz ausführen, interpretiert systemd die Dateien in den Verzeichnissen system.conf und system.conf.d. Bei der Ausführung als Benutzerinstanz interpretiert systemd die Dateien in den Verzeichnissen user.conf und user.conf.d der Konfigurationsdateien. Weitere Informationen finden Sie in systemd-system.conf (5).

Möglichkeit

Die folgenden Optionen werden verstanden.

--test

Bestimmen Sie die Startreihenfolge, den Speicherauszug und das Beenden. Dies ist eine Option, die nur zum Debuggen nützlich ist.

--dump-configuration-items

Entleeren Sie die verstandenen Gerätekonfigurationselemente. Dadurch wird eine präzise und vollständige Liste der Konfigurationselemente ausgegeben, die in der Einheitendefinitionsdatei erkannt werden.

--dump-bus-properties

Dump die exponierten Bus-Eigenschaften. Dadurch wird eine präzise und vollständige Liste der Eigenschaften ausgegeben, die dbus ausgesetzt sind.

--unit=

Legt die Standardeinheit fest, die beim Start aktiviert werden soll. Wenn nicht angegeben, ist der Standardwert default.target.

--system, --user

Normalerweise erkennt systemd automatisch den Modus, in dem es gestartet wurde, sodass Sie diese Optionen nicht übergeben müssen. Diese Optionen werden selten verwendet. Zum Debuggen. Es unterstützt nicht den vollständigen Systemstart und die vollständige Systemverwaltung, wenn systemd im --system -Modus ausgeführt wird, aber die PID ist nicht 1. Tatsächlich ist die explizite Übergabe von "--system" nur in Kombination mit "--test" sinnvoll.

--dump-core

Aktivieren Sie den Core Dump im Falle eines Absturzes. Dieser Schalter hat keine Auswirkung, wenn er als Benutzerinstanz ausgeführt wird. Diese Einstellung kann auch in der Kernel-Befehlszeile beim Booten über die Option systemd.dump_core aktiviert werden. Bitte beachten Sie Folgendes.

--crash-vt = VT

Wechseln Sie im Falle eines Absturzes zu einer bestimmten virtuellen Konsole (VT). Es wird eine positive Ganzzahl im Bereich von 1 bis 63 oder ein boolesches Argument verwendet. Wählen Sie aus, zu welcher VT gewechselt werden soll, wenn eine Ganzzahl übergeben wird. Wenn "Ja", wird der Ort ausgewählt, an dem die VT-Kernel-Nachricht geschrieben wird. Wenn nein, wird kein VT-Schalter versucht. Dieser Schalter hat keine Auswirkung, wenn er als Benutzerinstanz ausgeführt wird. Diese Einstellung kann auch in der Kernel-Befehlszeile beim Booten über die Option systemd.crash_chvt aktiviert werden. Bitte beachten Sie Folgendes.

--crash-shell

Führt die Shell beim Absturz aus. Dieser Schalter hat keine Auswirkung, wenn er als Benutzerinstanz ausgeführt wird. Diese Einstellung kann auch in der Kernel-Befehlszeile beim Booten über die Option systemd.crash_shell aktiviert werden. Bitte beachten Sie Folgendes.

--crash-reboot

Starten Sie das System im Falle eines Absturzes automatisch neu. Dieser Schalter hat keine Auswirkung, wenn er als Benutzerinstanz ausgeführt wird. Diese Einstellung kann auch in der Kernel-Befehlszeile beim Booten über die Option systemd.crash_reboot aktiviert werden. Bitte beachten Sie Folgendes.

--confirm-spawn

Bitten Sie um Bestätigung, wenn Sie einen Prozess erzeugen. Dieser Schalter hat keine Auswirkung, wenn er als Benutzerinstanz ausgeführt wird.

--show-status=

Nimmt ein boolesches Argument oder den speziellen Wert "auto".

--log-target=

Legen Sie das Protokollziel fest. Das Argument muss eines der folgenden sein:

--log-level=

Stellen Sie die Protokollstufe ein. Akzeptieren Sie als Argument eine numerische Protokollebene oder den bekannten symbolischen Namen syslog (3) (niedriger).

--log-color=

Markieren Sie wichtige Protokollnachrichten. Das Argument ist ein boolescher Wert. Wenn Sie das Argument weglassen, wird standardmäßig "true" verwendet.

--log-location=

Fügen Sie den Code-Speicherort in die Protokollnachricht ein. Dies hängt hauptsächlich mit dem Debuggen zusammen. Das Argument ist ein boolescher Wert. Wenn Sie das Argument weglassen, wird standardmäßig "true" verwendet.

--default-standard-output=, --default-standard-error=

Legen Sie die Standard- oder Fehlerausgabe für alle Dienste bzw. Sockets fest. Das heißt, es steuert die Standardeinstellungen für StandardOutput spezifisch und StandardError entsprechend (weitere Informationen finden Sie unter systemd.exec (5)). Nehmen Sie eines der folgenden Argumente.

Wenn Sie das Argument weglassen, wird für "--default-standard-output" standardmäßig "journal" und für "--default-standard-error" standardmäßig "erben" verwendet.

--machine-id=

Überschreibt die auf der Festplatte festgelegte Maschinen-ID. Nützlich für Netzwerkstarts und Container. Es kann nicht auf alle Nullen gesetzt werden.

--service-watchdogs=

Aktiviert / deaktiviert global alle Service-Watchdog-Timeouts und Notfallaktionen. Diese Einstellung kann auch beim Booten in der Kernel-Befehlszeile über die Option systemd.service_watchdogs (#systemdservice_watchdogs) festgelegt werden. Bitte beachten Sie Folgendes. Der Standardwert ist enable.

-h, --help

Zeigen Sie einen kurzen Hilfetext an und beenden Sie das Programm.

--version

Gibt eine kurze Versionszeichenfolge aus und wird beendet.

Überblick

systemd bietet ein Abhängigkeitssystem zwischen verschiedenen Entitäten, die als 11 Arten von "Einheiten" bezeichnet werden. Das Gerät kapselt verschiedene Objekte, die sich auf den Systemstart und die Systemverwaltung beziehen. Die meisten Einheiten bestehen aus Einheitenkonfigurationsdateien. Die Syntax und die grundlegenden Optionen sind in systemd.unit (5) beschrieben, einige stammen jedoch automatisch aus dem Systemstatus oder aus anderen Konfigurationen. Programmgesteuert zur Laufzeit erstellt. Einheiten sind entweder "aktiv" (dh gestartet, gebunden, eingesteckt usw., je nach Einheitentyp; siehe unten) oder "inaktiv" (dh gestoppt, ungebunden, nicht angeschlossen usw.). Und der Prozess der Aktivierung oder Deaktivierung, dh zwischen zwei Zuständen (diese Zustände werden "Aktivieren", "Deaktivieren" genannt). Ein spezieller Status "Fehlgeschlagen" ist ebenfalls verfügbar. Dies ist sehr ähnlich zu "inaktiv", das beendet wird, wenn der Dienst in irgendeiner Weise ausfällt (der Prozess gibt Fehlercode zurück oder stürzt ab, der Betrieb läuft ab oder wird beim Beenden häufig neu gestartet). Wenn zu viel). In diesem Fall wird die Ursache zur späteren Bezugnahme protokolliert. Beachten Sie, dass die verschiedenen Einheitentypen einige zusätzliche Unterzustände aufweisen, die in die hier beschriebenen fünf verallgemeinerten Einheitszustände fallen.

Folgende Gerätetypen stehen zur Verfügung:

  1. Eine Serviceeinheit, die den Dämon und die Prozesse, aus denen der Dämon besteht, startet und steuert. Weitere Informationen finden Sie unter systemd.service (5).

  2. Eine Socket-Einheit, die den lokalen IPC- oder Netzwerk-Socket des Systems kapselt. Nützlich für die Socket-basierte Aktivierung. Weitere Informationen zu Socket-Einheiten finden Sie unter systemd.socket (5). Weitere Informationen zur Socket-basierten Aktivierung und anderen Aktivierungsformen finden Sie unter Daemon (7).

  3. Zieleinheiten helfen Gruppeneinheiten und stellen beim Start bekannte Synchronisierungspunkte bereit. Siehe systemd.target (5).

  4. Die Geräteeinheit macht systemd-Kernelgeräte verfügbar und kann zur Implementierung der gerätebasierten Aktivierung verwendet werden. Weitere Informationen finden Sie unter systemd.device (5).

  5. Die Mount-Einheit steuert den Mount-Punkt des Dateisystems. Weitere Informationen finden Sie unter systemd.mount (5).

  6. Die Automount-Einheit bietet On-Demand-Montage des Dateisystems und Automounting-Funktionen für das parallele Booten. Siehe systemd.automount (5).

  7. Die Timer-Einheit hilft dabei, die Aktivierung anderer Einheiten basierend auf dem Timer auszulösen. Details finden Sie in systemd.timer (5).

  8. Die Swap-Einheit ist der Mount-Einheit sehr ähnlich und kapselt die Speicher-Swap-Partition oder -Datei des Betriebssystems. Sie sind in systemd.swap (5) beschrieben.

  9. Pfadeinheiten können verwendet werden, um andere Dienste zu aktivieren, wenn Dateisystemobjekte geändert oder geändert werden. Siehe systemd.path (5).

  10. Slice-Einheiten können verwendet werden, um Einheiten, die Systemprozesse verwalten (z. B. Serviceeinheiten und Bereichseinheiten), in einem hierarchischen Baum für die Ressourcenverwaltung zu gruppieren. Siehe systemd.slice (5).

  11. Scope-Einheiten ähneln Service-Einheiten, verwalten jedoch externe Prozesse, anstatt sie zu starten. Siehe systemd.scope (5). Das Gerät wird als Konfigurationsdatei benannt. Einige Einheiten haben eine spezielle Semantik. Eine detaillierte Liste finden Sie in systemd.special (7).

systemd kann eine Vielzahl von positiven und negativen Anforderungsabhängigkeiten (dh "Erforderlich" und "Konflikte nacheinander") und sequentiellen Abhängigkeiten ("Nach möglicherweise" und "Vorher") sein. Wir kennen verschiedene Arten von Abhängigkeiten.

Hinweis: Die Ordnungs- und Anforderungsabhängigkeiten sind orthogonal. Es gibt nur eine Anforderungsabhängigkeit zwischen den beiden Einheiten (z. B. foo.service erfordert bar.service), keine Auftragsabhängigkeit (z. B. foo.service gefolgt von bar.service) und beide starten Auf Wunsch werden sie parallel gestartet. Es ist ein gemeinsames Muster, dass sowohl Anforderungen als auch Auftragsabhängigkeiten zwischen zwei Einheiten platziert werden. Beachten Sie auch, dass die meisten Abhängigkeiten implizit von systemd erstellt und verwaltet werden. In den meisten Fällen müssen Sie keine zusätzlichen Abhängigkeiten manuell deklarieren, dies ist jedoch möglich.

Anwendungsprogramme und Einheiten (über Abhängigkeiten) können Änderungen des Einheitenstatus anfordern. In systemd werden diese Anforderungen als "Job" gekapselt und in der Jobwarteschlange gehalten. Der Job kann erfolgreich sein oder fehlschlagen. Die Jobausführung basiert auf geplanten Einheitenabhängigkeiten.

Beim Start startet systemd die Zieleinheit default.target. Dies ist ein Job, der durch Aufrufen von Startdiensten und anderen Starteinheiten über Abhängigkeiten gestartet wird. Der Gerätename lautet in der Regel graphical.target (für einen vollständigen Start der Benutzeroberfläche) oder multi-user.target (für einen eingeschränkten Konsolenstart zur Verwendung in einer eingebetteten oder Serverumgebung) oder ähnlich. Alias (symbolischer Link); eine Teilmenge von graphic.target). Es ist jedoch Sache des Administrators, es als Alias für eine andere Zieleinheit zu konfigurieren. Weitere Informationen zu diesen Zieleinheiten finden Sie unter systemd.special (7).

systemd enthält nur die kleinste in den Speicher eingelesene Einheit. Insbesondere sind die einzigen Einheiten, die im Speicher geladen bleiben, diejenigen, die mindestens eine der folgenden Bedingungen erfüllen:

  1. Aktiver, aktivierter, deaktivierter oder fehlgeschlagener Zustand (dh alle Einheitenzustände außer "inaktiv")

  2. Es befindet sich ein Job in der Warteschlange.

  3. Es ist die Abhängigkeit von mindestens einer anderen Einheit, die in den Speicher geladen wird.

  4. Eine Serviceeinheit, der noch eine Form zugeordneter Ressource zugewiesen ist (z. B. eine Serviceeinheit, die inaktiv ist, aber noch Prozesse hat, bei denen Beendigungsanforderungen ignoriert wurden).

  5. Programmgesteuert per D-Bus-Aufruf an den Speicher angeheftet.

systemd lädt das Gerät automatisch und implizit von der Festplatte, sobald eine Operation angefordert wird, falls das Gerät noch nicht geladen wurde. Daher weiß der Client in vielerlei Hinsicht nicht, ob das Gerät geladen ist. Verwenden Sie systemctl list-units --all, um alle aktuell geladenen Einheiten aufzulisten. Geräte, die keine der oben genannten Bedingungen erfüllen, werden sofort entladen. Beachten Sie, dass beim Entladen einer Einheit aus dem Speicher auch die Abrechnungsdaten gelöscht werden. Diese Daten gehen jedoch normalerweise nicht verloren, da bei jedem Herunterfahren des Geräts ein Journalprotokolldatensatz generiert wird, der die verbrauchten Ressourcen deklariert.

Die von systemd erzeugten Prozesse werden in einzelne Linux-Kontrollgruppen eingeordnet, die nach den Einheiten benannt sind, zu denen sie in einer privaten systemd-Hierarchie gehören. (Weitere Informationen zu Kontrollgruppen finden Sie unter cgroups.txt oder cgroups. systemd verwendet dies, um den Prozess effektiv zu verfolgen. Kontrollgruppeninformationen werden im Kernel gespeichert und in der Dateisystemhierarchie (unter / sys / fs / cgroup / systemd /) oder systemd-cgls (1) oder ps (1) gespeichert. (ps xawf -eo pid, user, cgroup, args sind besonders nützlich, um alle Prozesse und die systemd-Einheiten aufzulisten, zu denen sie gehören.)

systemd ist sehr kompatibel mit SysV-Init-Systemen. SysVinit-Skripte werden als alternatives (wenn auch eingeschränktes) Konfigurationsdateiformat unterstützt und gelesen. Eine SysV / dev / initctl Schnittstelle wird bereitgestellt und kompatible Implementierungen verschiedener SysV Client-Tools sind verfügbar. Darüber hinaus werden verschiedene Unix-Funktionen unterstützt, z. B. "/ etc / fstab" und die utmp-Datenbank.

systemd hat ein minimales Transaktionssystem. Wenn eine Einheit zum Starten oder Herunterfahren aufgefordert wird, werden die Einheit und alle ihre Abhängigkeiten zur temporären Transaktion hinzugefügt. Überprüfen Sie dann, ob die Transaktion konsistent ist (dh ob es einen Zyklus in der Reihenfolge aller Einheiten gibt). Wenn es einen Zyklus in der Reihenfolge der Einheiten gibt, versucht systemd, diesen zu beheben und die nicht wesentlichen Jobs aus der Transaktion zu entfernen, die möglicherweise die Schleife entfernen können. Systemd versucht auch, unkritische Jobs in Transaktionen zu unterdrücken, bei denen keine Dienste mehr ausgeführt werden. Schließlich wird geprüft, ob der Job in der Transaktion nicht mit einem Job übereinstimmt, der bereits in die Warteschlange gestellt wurde, und die Transaktion wird optional abgebrochen. Wenn alles gut geht und die Transaktion konsistent ist und nur minimale Auswirkungen hat, wird sie mit allen ausstehenden Jobs zusammengeführt und der Ausführungswarteschlange hinzugefügt. Dies bedeutet effektiv, dass systemd die Gültigkeit überprüft, wenn möglich behebt und nur dann fehlschlägt, wenn es nicht funktioniert, bevor der angeforderte Vorgang ausgeführt wird.

Beachten Sie, dass Transaktionen zur Laufzeit unabhängig vom Status der Einheit generiert werden. Wenn beispielsweise ein Startjob für eine bereits gestartete Einheit angefordert wird, wird eine Transaktion erzeugt und eine inaktive Abhängigkeit aufgerufen (die Weitergabe anderer Jobs erfolgt auch für jede definierte Beziehung). .. Dies liegt daran, dass sich der Job in der Warteschlange im Vergleich zum Status der Zieleinheit im laufenden Zustand befindet und als erfolgreich markiert und abgeschlossen ist, wenn beide erfüllt sind. Dieser Job erfasst jedoch aufgrund der definierten Beziehungen auch andere Abhängigkeiten. In diesem Beispiel wird also auch jeder Job in der inaktiven Einheit in die Warteschlange gestellt.

systemd enthält native Implementierungen verschiedener Aufgaben, die im Rahmen des Startvorgangs ausgeführt werden müssen. Legen Sie beispielsweise einen Hostnamen fest oder konfigurieren Sie ein Loopback-Netzwerkgerät. Außerdem werden verschiedene API-Dateisysteme wie / sys und / proc eingerichtet und bereitgestellt.

Weitere Informationen zu den Konzepten und Ideen hinter systemd finden Sie im Original Design Document (http://0pointer.de/blog/projects/systemd.html).

Bitte beachten Sie, dass einige von systemd bereitgestellte Schnittstellen unter das Versprechen zur Schnittstellenstabilität fallen (https://www.freedesktop.org/wiki/Software/systemd/InterfaceStabilityPromise).

Einheiten können beim Booten und beim Neuladen des Systemmanagers dynamisch generiert werden. Beispielsweise basiert es auf anderen Konfigurationsdateien oder Parametern, die über die Kernel-Befehlszeile übergeben werden. Weitere Informationen finden Sie unter systemd.generator (7).

Das System, das systemd in einer Container- oder initrd-Umgebung aufruft, ist die Container-Schnittstelle (https://www.freedesktop.org/wiki/Software/systemd/ContainerInterface) bzw. die initrd-Schnittstelle (https://www.freedesktop.org). Sie müssen die Spezifikation implementieren (/ wiki / Software / systemd / InitrdInterface).

Verzeichnis

Systemeinheitsverzeichnis

systemd System Manager liest die Gerätekonfiguration aus verschiedenen Verzeichnissen. Die Pakete, die die Einheitendateien installieren, legen sie in dem von pkg-config systemd --variable = systemdsystemunitdir zurückgegebenen Verzeichnis ab. Die anderen überprüften Verzeichnisse sind "/ usr / local / lib / systemd / system" und "/ lib / systemd / system". Benutzereinstellungen haben immer Vorrang. pkg-config systemd --variable = systemdsystemconfdir gibt den Pfad zum Systemkonfigurationsverzeichnis zurück. Das Paket muss nur den Inhalt dieser Verzeichnisse mit den Befehlen enable und disable des systemctl (1) -Tools ändern. Eine vollständige Liste der Verzeichnisse finden Sie in systemd.unit (5).

Benutzereinheitsverzeichnis

Ähnliche Regeln gelten für Benutzereinheitenverzeichnisse. Hier suchen wir jedoch nach Einheiten gemäß der XDG Base Directory-Spezifikation. Die Anwendung muss die Einheitendateien in dem von pkg-config systemd --variable = systemduserunitdir zurückgegebenen Verzeichnis ablegen. Globale Einstellungen werden in dem Verzeichnis vorgenommen, das von pkg-config systemd --variable = systemduserconfdir gemeldet wird. Die Befehle enable und disable des systemctl (1) -Tools können sowohl die globale (dh alle Benutzer) als auch die private (ein Benutzer) Aktivierung / Deaktivierung des Geräts verarbeiten. Ich werde. Eine vollständige Liste der Verzeichnisse finden Sie in systemd.unit (5).

SysV-Init-Skriptverzeichnis

Der Speicherort des SysV-Init-Skriptverzeichnisses hängt von der Verteilung ab. Wenn die native Einheitendatei für den angeforderten Dienst nicht gefunden wird, sucht systemd nach einem SysV-Init-Skript mit demselben Namen, wobei jedoch das Suffix ".service" entfernt wurde.

Linkfarmverzeichnis auf SysV-Run-Ebene

Der Speicherort des Linkfarmverzeichnisses auf SysV-Run-Ebene hängt von der Verteilung ab. systemd berücksichtigt die verknüpfte Farm bei der Entscheidung, ob der Dienst aktiviert werden soll. Serviceeinheiten mit nativen Einheitenkonfigurationsdateien können nicht in einer verknüpften SysV-Farm auf Run-Ebene aktiviert und gestartet werden.

Signal

SIGTERM

Nach Empfang dieses Signals serialisiert systemd System Manager den Status, führt sich selbst erneut aus und deserialisiert den gespeicherten Status erneut. Dies entspricht in erster Linie "systemctl daemon-reexec".

Wenn der Systemd User Manager dieses Signal empfängt, startet er die exit.target-Einheit. Dies ist fast gleichbedeutend mit "systemctl --user start exit.target --job-mode = replace-irreversible".

SIGINT

Nach Empfang dieses Signals startet der Systemd-Systemmanager die Einheit ctrl-alt-del.target. Dies entspricht in etwa "systemctl start ctrl-alt-del.target --job-mode = replace-irreversible". Wenn dieses Signal innerhalb von 2 Sekunden mehr als 7 Mal empfangen wird, wird ein sofortiger Neustart ausgelöst. Beachten Sie, dass das Drücken von Strg + Alt + Entf auf der Konsole dieses Signal auslöst. Wenn der Neustart angehalten wird, ist es daher relativ sicher, innerhalb von 2 Sekunden mehr als sieben Mal Strg + Alt + Entf zu drücken, um sofort neu zu starten.

Der Systemd-Benutzermanager behandelt dieses Signal genauso wie SIGTERM.

SIGWINCH

Nach dem Empfang dieses Signals startet der systemd-Systemmanager die Einheit kbrequest.target. Dies entspricht fast "systemctl start kbrequest.target".

Dieses Signal wird vom Systemd-Benutzermanager ignoriert.

SIGPWR

Nach Empfang dieses Signals startet der Systemd-Manager die sigpwr.target-Einheit. Dies ist fast gleichbedeutend mit "systemctl start sigpwr.target".

SIGUSR1

Nach dem Empfang dieses Signals versucht der System-Manager, die Verbindung zum D-Bus-Bus wiederherzustellen.

SIGUSR2

Nach dem Empfang dieses Signals zeichnet der systemd-Manager seinen vollständigen Status in einem für Menschen lesbaren Format auf. Die protokollierten Daten sind die gleichen wie die von systemd-analyse dump ausgegebenen.

SIGHUP

Laden Sie die vollständige Daemon-Konfiguration neu. Dies entspricht in etwa "systemctl daemon-reload".

SIGRTMIN+0

Rufen Sie den Standardmodus auf und starten Sie die default.target-Einheit. Dies ist fast gleichbedeutend mit systemctl isolate default.target.

SIGRTMIN+1

Rufen Sie den Rettungsmodus auf und starten Sie die Rettungseinheit. Dies entspricht in etwa "systemctl isolate recovery.target".

SIGRTMIN+2

Rufen Sie den Notfallmodus auf und starten Sie die Notdiensteinheit. Dies ist meistens gleichbedeutend mit "systemctl isolate instant.service".

SIGRTMIN+3

Fahren Sie die Maschine herunter und starten Sie die Zieleinheit halt.target. Dies ist fast gleichbedeutend mit "systemctl start halt.target --job-mode = replace-irreversible".

SIGRTMIN+4

Schalten Sie die Maschine aus und starten Sie die Zieleinheit poweroff.target. Dies ist fast gleichbedeutend mit "systemctl start poweroff.target --job-mode = replace-irreversible".

SIGRTMIN+5

Starten Sie den Computer neu und starten Sie die Einheit reboot.target. Dies ist fast gleichbedeutend mit "systemctl start reboot.target --job-mode = replace-irreversible".

SIGRTMIN+6

Starten Sie den Computer über kexec neu und starten Sie die kexec.target-Einheit. Dies ist fast gleichbedeutend mit "systemctl start kexec.target --job-mode = replace-irreversible".

SIGRTMIN+13

Stoppen Sie die Maschine sofort.

SIGRTMIN+14

Schalten Sie die Maschine sofort aus.

SIGRTMIN+15

Starten Sie die Maschine sofort neu.

SIGRTMIN+16

Starten Sie die Maschine sofort mit kexec neu.

SIGRTMIN+20

Aktiviert die Anzeige von Statusmeldungen auf der Konsole, so dass diese von systemd.show_status = 1 in der Kernel-Befehlszeile gesteuert werden.

SIGRTMIN+21

Deaktiviert die Anzeige von Statusmeldungen auf der Konsole, sodass diese von systemd.show_status = 0 in der Kernel-Befehlszeile gesteuert werden.

SIGRTMIN+22

Setzen Sie die Service Manager-Protokollebene auf die gleiche Weise wie "systemd.log_level = debug" in der Kernel-Befehlszeile auf "debug".

SIGRTMIN+23

Stellt die Protokollstufe auf den festgelegten Wert wieder her. Die konfigurierten Werte sind je nach Priorität der Wert, der von systemd.log-level insbesondere in der Kernel-Befehlszeile angegeben wird, oder der Wert, der von LogLevel insbesondere in der Konfigurationsdatei angegeben wird, oder der eingebauten `. Abgeleitet von der Standardeinstellung "info".

SIGRTMIN+24

Beenden Sie den Manager sofort (nur für --user-Instanzen verfügbar).

SIGRTMIN+26

Stellt das Protokollziel auf den festgelegten Wert wieder her. Die konfigurierten Werte sind je nach Priorität der von [systemd.log-target](# -log-target) in der Kernel-Befehlszeile angegebene Wert oder der von `` LogTarget speziell in der Konfigurationsdatei angegebene Wert. Oder aus der eingebauten Standardeinstellung.

SIGRTMIN+27, SIGRTMIN+28

Setzen Sie das Protokollziel auf SIGRTMIN + 27 console (oder SIGRTMIN) auf die gleiche Weise wie systemd.log_target = console (oder SIGRTMIN + 28 systemd.log_target = kmsg) in der Kernel-Befehlszeile. Auf +28 kmsg) einstellen.

Umgebung

$SYSTEMD_LOG_LEVEL

systemd liest die Protokollebene aus dieser Umgebungsvariablen. Dies kann mit [--log-level](# --log-level) überschrieben werden.

$SYSTEMD_LOG_TARGET

systemd liest das Protokollziel aus dieser Umgebungsvariablen. Dies kann mit [--log-target](# --log-target) überschrieben werden.

$SYSTEMD_LOG_COLOR

Steuert, ob systemd wichtige Protokollmeldungen hervorhebt. Dies kann mit [--log-color](# -log-color) überschrieben werden.

$SYSTEMD_LOG_LOCATION

Steuert, ob systemd die Codeposition zusammen mit der Protokollnachricht druckt. Dies kann mit [--log-location](# --log-location) überschrieben werden.

$XDG_CONFIG_HOME, $XDG_CONFIG_DIRS, $XDG_DATA_HOME, $XDG_DATA_DIRS

Der Systemd-Benutzermanager verwendet diese Variablen, um seine Konfiguration gemäß der XDG-Basisverzeichnisspezifikation (http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html) zu finden.

$SYSTEMD_UNIT_PATH

Steuert, wo systemd nach Einheitendateien sucht.

$SYSTEMD_SYSVINIT_PATH

Steuert, wo systemd nach SysV-Init-Skripten sucht.

$SYSTEMD_SYSVRCND_PATH

Steuert, wo systemd nach Linkfarmen auf SysV-Init-Skript-Run-Ebene sucht.

$SYSTEMD_COLORS

Der Wert muss ein boolescher Wert sein. Steuert, ob eine kolorierte Ausgabe erzeugt werden soll. Sie können dies angeben, um die Entscheidung zu überschreiben, die systemd basierend auf $ TERM und dem Ziel der Konsole trifft.

$SYSTEMD_URLIFY

Der Wert muss ein boolescher Wert sein. Steuert, ob in der Ausgabe von Terminalemulatoren, die dies unterstützen, ein anklickbarer Link generiert wird. Sie können dies angeben, um die Entscheidungen zu überschreiben, die systemd basierend auf $ TERM und anderen Bedingungen trifft.

$LISTEN_PID, $LISTEN_FDS, $LISTEN_FDNAMES

Von systemd für überwachte Prozesse während der Socket-basierten Aktivierung konfiguriert. Weitere Informationen finden Sie unter sd_listen_fds (3).

$NOTIFY_SOCKET

Wird von systemd für überwachte Prozesse für Status- und Startabschlussbenachrichtigungen festgelegt. Weitere Informationen finden Sie unter sd_notify (3).

Informationen zu systemd und anderen Umgebungsvariablen, die von den verschiedenen Komponenten verstanden werden, finden Sie unter Bekannte Umgebungsvariablen.

Kernel-Befehlszeile

Bei der Ausführung als Systeminstanz analysiert systemd einige Kernel-Befehlszeilenargumente.

systemd.unit=, rd.systemd.unit=

Überschreibt das Gerät und aktiviert es beim Booten. Der Standardwert ist default.target. Dies kann verwendet werden, um vorübergehend mit einer anderen Starteinheit zu starten, z. B. Rescue.Target oder Emergency.Service. Weitere Informationen zu diesen Einheiten finden Sie unter systemd.special (7). Optionen, die mit rd. beginnen, sind nur auf der anfänglichen RAM-Disk (initrd) gültig, im Gegensatz zu der nicht fixierten RAM-Disk nur auf dem Hauptsystem.

systemd.dump_core

Nimmt ein boolesches Argument oder aktiviert die Option, wenn sie ohne Argument angegeben wird. Wenn diese Option aktiviert ist, gibt der Systemd-Manager (PID 1) im Falle eines Absturzes Kerne aus. Andernfalls wird kein Core-Dump erstellt. Der Standardwert ist gültig.

systemd.crash_chvt

Nimmt ein positives ganzzahliges oder boolesches Argument. Es kann ohne Argumente angegeben werden und hat den gleichen Effekt wie ein positiver Boolescher Wert. Wenn eine positive Ganzzahl (im Bereich von 1 bis 63) angegeben ist, aktiviert der System Manager (PID 1) im Falle eines Absturzes das angegebene virtuelle Terminal (VT). Der Standardwert ist ungültig. Das heißt, es wird kein solcher Wechsel vorgenommen. Wenn aktiviert, wird die VT ausgewählt, in die Kernel-Nachrichten geschrieben werden.

systemd.crash_shell

Nimmt ein boolesches Argument oder aktiviert die Option, wenn sie ohne Argument angegeben wird. Wenn aktiviert, erzeugt der System Manager (PID 1) eine Shell nach einer Verzögerung von 10 Sekunden, wenn sie abstürzt. Andernfalls wird keine Shell generiert. Die Shell ist nicht durch die Kennwortauthentifizierung geschützt und aus Sicherheitsgründen standardmäßig deaktiviert.

systemd.crash_reboot

Nimmt ein boolesches Argument oder aktiviert die Option, wenn sie ohne Argument angegeben wird. Wenn diese Option aktiviert ist, startet der System Manager (PID 1) den Computer nach 10 Sekunden automatisch neu, wenn er abstürzt. Andernfalls bleibt das System auf unbestimmte Zeit hängen. Es ist standardmäßig deaktiviert, um eine Neustartschleife zu vermeiden. In Kombination mit systemd.crash_shell wird das System nach dem Beenden der Shell neu gestartet.

systemd.confirm_spawn

Ruft das Boolesche Argument oder den Pfad zur virtuellen Konsole ab, an die die Bestätigungsnachricht gesendet wird. Es kann ohne Argumente angegeben werden und hat den gleichen Effekt wie ein positiver Boolescher Wert. Wenn aktiviert, verwendet der System Manager (PID 1) "/ dev / console", um beim Start des Prozesses eine Bestätigung anzufordern. Wenn ein Pfad oder Konsolenname (z. B. "ttyS0") angegeben wird, wird stattdessen die in diesem Pfad angegebene oder durch den angegebenen Namen beschriebene virtuelle Konsole verwendet. Es ist standardmäßig deaktiviert.

systemd.service_watchdogs=

Nimmt ein boolesches Argument. Wenn diese Option deaktiviert ist, werden alle Service-Laufzeit-Watchdogs (WatchdogSec nacheinander) und dringenden Aktionen (z. B. OnFailure entsprechend und `` StartLimitAction entsprechend) vom System Manager (PID 1) ignoriert. Siehe systemd.service (5). Es ist standardmäßig aktiviert. Das heißt, Watchdogs und Fehleraktionen werden erfolgreich behandelt. Hardware-Wachhunde sind von dieser Option nicht betroffen.

systemd.show_status

Nimmt ein boolesches Argument oder die Konstante "auto". Es kann ohne Argumente angegeben werden und hat den gleichen Effekt wie ein positiver Boolescher Wert. Wenn aktiviert, zeigt der Systemd-Manager (PID 1) beim Start eine kurze Aktualisierung des Dienststatus auf der Konsole an. auto verhält sich wie false, bis das Gerät ausfällt oder das Booten erheblich verzögert wird. Es ist standardmäßig aktiviert, es sei denn, quiet wird als Kernel-Befehlszeilenoption übergeben. In diesem Fall wird standardmäßig "auto" verwendet. Wenn angegeben, wird die Option "ShowStatus-Ursachen" der Systemmanager-Konfigurationsdatei überschrieben. Siehe systemd-system.conf (5). Die Prozessbefehlszeilenoption [--show-status](# --show-status) hat jedoch Vorrang vor dieser Kernel-Befehlszeilenoption und der Konfigurationsdateioption.

systemd.log_target=, systemd.log_level=, systemd.log_location=, systemd.log_color

Steuert die Protokollausgabe mit dem gleichen Effekt wie oben beschrieben: $ SYSTEMD_LOG_TARGET, $ SYSTEMD_LOG_LEVEL, $ SYSTEMD_LOG_LOCATION, [$ SYSTEMD_Log_Log) .. systemd.log_color kann ohne Argumente angegeben werden und hat den gleichen Effekt wie ein positiver Boolescher Wert.

systemd.default_standard_output=, systemd.default_standard_error=

Gleicher Effekt wie die obigen Befehlszeilenargumente [--default-standard-output, --default-standard-error](# --default-standard-output --- default-standard-error), jedoch der Dienststandard Steuert die Standardausgabe und die Fehlerausgabe.

systemd.setenv=

Nimmt ein String-Argument der Form VARIABLE = VALUE an. Es kann verwendet werden, um Standardumgebungsvariablen festzulegen, die gegabelten untergeordneten Prozessen hinzugefügt werden sollen. Kann mehrfach verwendet werden, um mehrere Variablen festzulegen.

systemd.machine_id=

Nimmt einen 32-stelligen Hexadezimalwert an, der zum Festlegen der Maschinen-ID verwendet wird. Das Hauptziel sind Netzwerkstarts, für die für alle Starts dieselbe Computer-ID erforderlich ist.

systemd.unified_cgroup_hierarchy

Ohne Argumente oder mit dem Argument true können Sie die integrierte cgroup-Hierarchie (https://www.kernel.org/doc/Documentation/cgroup-v2.txt) verwenden. (Auch als cgroups-v2 bekannt). Wenn Sie das Argument "false" angeben, wird die hybride oder vollständige Legacy-cgroup-Hierarchie (https://www.kernel.org/doc/Documentation/cgroup-v1/) aufgerufen. Wenn diese Option nicht angegeben wird, wird das Standardverhalten zur Kompilierungszeit festgelegt ( -Ddefault-hierarchy = meson Option). Wenn der Kernel die integrierte cgroup-Hierarchie nicht unterstützt, wird die Legacy-Hierarchie verwendet, auch wenn diese Option angegeben ist.

systemd.legacy_systemd_cgroup_controller

Aktiviert, wenn die vollständig integrierte cgroup-Hierarchie nicht verwendet wird (siehe vorherige Option). Ohne Argument oder mit dem Argument "true" die "hybride" cgroup-Hierarchie (der für systemd verwendete cgroups-v2-Baum und für andere Controller die Legacy-cgroup-Hierarchie) (https: // www) Deaktivieren Sie die Verwendung von .kernel.org / doc / Documentation / cgroup-v1 /), auch bekannt als cgroups-v1). Erzwingt den vollständigen "Legacy" -Modus. Das Argument "false" ermöglicht die Verwendung der "hybriden" Hierarchie. Wenn diese Option nicht angegeben wird, wird das Standardverhalten zur Kompilierungszeit festgelegt ( -Ddefault-hierarchy = meson Option). Wenn der Kernel die integrierte cgroup-Hierarchie nicht unterstützt, wird die Legacy-Hierarchie verwendet, auch wenn diese Option angegeben ist.

quiet

Schaltet die Statusausgabe beim Start aus, ähnlich wie systemd.show_status = no. Beachten Sie, dass diese Option auch in den Kernel selbst geladen wird, wodurch die Kernelprotokollausgabe deaktiviert wird. Wenn Sie diese Option übergeben, wird die normale Ausgabe sowohl vom Systemmanager als auch vom Kernel deaktiviert.

debug

Aktivieren Sie die Debug-Ausgabe. Dies entspricht "systemd.log_level = debug". Beachten Sie, dass diese Option auch in den Kernel selbst geladen wird, wodurch die Debug-Ausgabe für den Kernel aktiviert wird. Wenn Sie diese Option übergeben, wird die Debug-Ausgabe sowohl vom Systemmanager als auch vom Kernel aktiviert.

emergency, rd.emergency, -b

Starten Sie im Notfallmodus. Dies entspricht "systemd.unit = Emergency.target" bzw. "rd.systemd.unit = Emergency.target" und wird aus Kompatibilitätsgründen und zur Vereinfachung der Eingabe bereitgestellt.

rescue, rd.rescue, single, s, S, 1

Starten Sie im Rettungsmodus. Dies entspricht "systemd.unit = rettung.Ziel" bzw. "rd.systemd.unit = rettung.Ziel" und wird aus Kompatibilitätsgründen und zur Vereinfachung der Eingabe bereitgestellt. ..

2, 3, 4, 5

Startet auf der angegebenen älteren SysV-Laufstufe. Dies sind "systemd.unit = runlevel2.target", "systemd.unit = runlevel3.target", "systemd.unit = runlevel4.target" bzw. "systemd.unit = runlevel5.target". Entspricht `und ist aus Kompatibilitätsgründen und zur Vereinfachung der Eingabe vorgesehen.

locale.LANG=, locale.LANGUAGE=, locale.LC_CTYPE=, locale.LC_NUMERIC=, locale.LC_TIME=, locale.LC_COLLATE=, locale.LC_MONETARY=, locale.LC_MESSAGES=, locale.LC_PAPER=, locale.LC_NAME=, locale.LC_ADDRESS=, locale.LC_TELEPHONE=, locale.LC_MEASUREMENT=, locale.LC_IDENTIFICATION=

Legt das zu verwendende Systemgebietsschema fest. Dies überschreibt die Einstellungen in / etc / locale.conf. Weitere Informationen finden Sie unter locale.conf (5) und locale (7). Weitere Informationen zur Kernel-Befehlszeilenparameter, die die Kernkomponenten des Betriebssystems verstehen können, finden Sie in der Kernel-Befehlszeile (7).

Steckdosen und FIFOs

/run/systemd/notify

Dämonenstatus-Benachrichtigungsbuchse. Dies ist ein AF_UNIX-Datagramm-Socket und wird zum Implementieren der von sd_notify (3) implementierten Daemon-Benachrichtigungslogik verwendet.

/run/systemd/private

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

/dev/initctl

Eingeschränkte Kompatibilitätsunterstützung für die in der systemd-initctl.service-Einheit implementierte SysV-Client-Schnittstelle. Dies ist eine Named Pipe im Dateisystem. Diese Schnittstelle ist veraltet und sollte nicht in neuen Anwendungen verwendet werden.

SEE ALSO

NOTES

  1. cgroups.txt

  2. Original Design Document

  3. Interface Stability Promise

  4. Container Interface

  5. initrd Interface

  6. XDG Base Directory specification

  7. Known Environment Variables

  8. Wenn diese Argumente in einem Linux-Container ausgeführt werden, können sie als Befehlszeilenargumente an systemd selbst neben den im Abschnitt Optionen oben aufgeführten Befehlszeilenoptionen übergeben werden. Wenn Sie außerhalb des Linux-Containers ausgeführt werden, werden diese Argumente stattdessen aus / proc / cmdline analysiert.

  9. unified cgroup hierarchy

  10. legacy cgroup hierarchy

  11. systemd Homepage

Recommended Posts

Mann systemd japanische Übersetzung
man systemd.service Japanische Übersetzung
man nftables Japanische Übersetzung
sosreport Japanische Übersetzung
stromlinienförmige Erklärung japanische Übersetzung
Streamlit Tutorial Japanische Übersetzung
Dockerfile Reference Japanische Übersetzung
docker-compose --help japanische Übersetzung
Docker helfen japanische Übersetzung
Docker Build - Hilfe japanische Übersetzung
Japanische Übersetzung des sysstat-Handbuchs
Japanische Übersetzung des Linux-Handbuchs
Docker run --help japanische Übersetzung
Biopython Tutorial und Kochbuch Japanische Übersetzung (4.3)
Docker mysql Quick Reference Japanische Übersetzung
Japanische Übersetzung des e2fsprogs-Handbuchs
Biopython Tutorial und Kochbuch Japanische Übersetzung (4.1)
Biopython Tutorial und Kochbuch Japanische Übersetzung (4.5)
Biopython Tutorial und Kochbuch Japanische Übersetzung (4.8)
Biopython Tutorial und Kochbuch Japanische Übersetzung (4.7)
Japanische Übersetzung des man-db Handbuchs
Angemessene japanische Übersetzung von pytorch tensor_tutorial
Biopython Tutorial und Kochbuch Japanische Übersetzung (4.9)
Biopython Tutorial und Kochbuch Japanische Übersetzung (4.6)
Japanische Übersetzung des Util-Linux-Handbuchs
Biopython Tutorial und Kochbuch Japanische Übersetzung (4.2)
Biopython Tutorial und Kochbuch Japanische Übersetzung (4.4)
Japanische Übersetzung des iproute2-Handbuchs
Japanische Übersetzung des Apache Spark-Dokuments - Einreichen von Anträgen
Japanische Übersetzung des Apache Spark-Dokuments - Schnellstart
[Google App Engine] Benutzerobjekte (japanische Übersetzung)
Erste Schritte: 30 Sekunden für die japanische Übersetzung von Keras
Biopython Tutorial und Kochbuch Japanische Übersetzung (Kapitel 1, 2)
Japanische Übersetzung: PEP 20 - Das Zen von Python