BEZEICHNUNG
systemctl - Steuerung des Systemd-Systems und des DiensteverwaltersÜBERSICHT
systemctl
[OPTIONEN…] BEFEHL [UNIT…]
BESCHREIBUNG
systemctl kann zum Prüfen und Steuern des Zustandes des »Systemd«-Systems und -Diensteverwalters verwandt werden. Bitte lesen Sie systemd(1) für eine Einführung in die grundlegenden Konzepte und Funktionalitäten, die dieses Werkezeug verwaltet.BEFEHLE
Die folgenden Befehle werden verstanden:Unit-Befehle (Untersuchung und Veränderung)
list-units [MUSTER…]Listet Units auf, die systemd derzeit
im Speicher hat. Dies schließt Units ein, die entweder direkt oder
über eine Abhängigkeit referenziert sind, Units, die durch
Anwendungen programmatisch festgelegt sind und Units, die in der Vergangenheit
aktiv waren und fehlschlugen. Standardmäßig werden nur Units,
die aktiv sind, wartende Aufträge haben oder die fehlschlugen,
angezeigt; dies kann mit der Option --all geändert werden. Falls
eines oder mehrere MUSTER angegeben sind, werden nur Units, die auf
diese passen, angezeigt. Die angezeigten Units werden zusätzlich durch
--type= und --state= gefiltert, falls diese Optionen angegeben
sind.
Beachten Sie, dass dieser Befehl keine Unit-Vorlagen zeigt, sondern nur
Instanzen von Unit-Vorlagen. Unit-Vorlagen, die nicht instanziiert sind,
können nicht ausgeführt werden und werden daher niemals in der
Ausgabe dieses Befehls auftauchen. Konkret bedeutet dies, dass [email protected]
niemals in dieser Liste angezeigt wird – außer instanziiert,
d.h. als [email protected]. Verwenden Sie list-unit-files (siehe unten),
um installierte Unit-Vorlagendateien aufzulisten.
Produziert eine Ausgabe ähnlich zu
Die Kopfzeilen und die letzte Unit des angegebenen Typs werden unterstrichen,
falls das Terminal dies unterstützt. Ein farbiger Punkt wird neben den
Diensten, die maskiert, nicht gefunden oder sonstwie fehlgeschlagen sind,
angezeigt.
Die Spalte LOAD zeigt den Ladezustand, einen aus loaded,
not-found, bad-setting, error, masked. Die Spalte
ACTIVE zeigt den allgemeinen Unit-Zustand, einen aus active,
reloading, inactive, failed, activating,
deactivating. Die Spalte SUB zeigt den Unit-Typ-spezifischen
detaillierten Zustand der Unit, mögliche Werte hängen vom
Unit-Typ ab. Die Liste der möglichen LOAD-, ACTIVE- und
SUB-Zustände ist nicht konstant und neue
Systemd-Veröffentlichungen können sowohl Werte hinzufügen
als auch welche entfernen.
Der Befehl kann zur Anzeige der aktuell möglichen Menge von Werten
verwandt werden.
Dies ist der Standardbefehl.
list-automounts [MUSTER…]
UNIT LOAD ACTIVE SUB DESCRIPTION sys-module-fuse.device loaded active plugged /sys/module/fuse -.mount loaded active mounted Root Mount boot-efi.mount loaded active mounted /boot/efi systemd-journald.service loaded active running Journal Service systemd-logind.service loaded active running Login Service ● [email protected] loaded failed failed User Manager for UID 1000 … systemd-tmpfiles-clean.timer loaded active waiting Daily Cleanup of Temporary Directories LOAD = Reflects whether the unit definition was properly loaded. ACTIVE = The high-level unit activation state, i.e. generalization of SUB. SUB = The low-level unit activation state, values depend on unit type. 123 loaded units listed. Pass --all to see loaded but inactive units, too. To show all installed unit files use 'systemctl list-unit-files'.
systemctl --state=help
Listet aktuell im Speicher befindliche
Automount-Units, sortiert nach dem Einhängepfad, auf. Falls eines oder
mehrere MUSTER angegeben sind, werden nur Automount-Units, die darauf
passen, angezeigt. Produziert Ausgabe ähnlich zu
Siehe auch --show-types, --all und --state=.
list-sockets [MUSTER…]
WHAT WHERE MOUNTED IDLE TIMEOUT UNIT /dev/sdb1 /mnt/test no 120s mnt-test.automount binfmt_misc /proc/sys/fs/binfmt_misc yes 0 proc-sys-fs-binfmt_misc.automount 2 automounts listed.
Listet aktuell im Speicher befindliche
Socket-Units, sortiert nach der Adresse, auf der sie auf Anfragen warten, auf.
Falls eines oder mehrere MUSTER angegeben sind, werden nur
Socket-Units, die darauf passen, angezeigt. Produziert Ausgabe ähnlich
zu
Beachten Sie: Da die Adressen Leerzeichen enthalten können, ist diese
Ausgabe nicht für die programmatische Verarbeitung geeignet.
Siehe auch --show-types, --all und --state=.
list-timers [MUSTER…]
LISTEN UNIT ACTIVATES /dev/initctl systemd-initctl.socket systemd-initctl.service ... [::]:22 sshd.socket sshd.service kobject-uevent 1 systemd-udevd-kernel.socket systemd-udevd.service 5 sockets listed.
Listet aktuell im Speicher befindliche
Timer-Units, sortiert nach der Zeit, zu der sie ablaufen, auf. Falls eines
oder mehrere MUSTER angegeben sind, werden nur Units, die darauf
passen, angezeigt. Produziert Ausgabe ähnlich zu
NEXT zeigt die nächste Zeit, zu der der Timer läuft.
LEFT zeigt die Zeitdauer, bis der Timer das nächste Mal
läuft.
LAST zeigt die Zeit, zu der der Timer das letzte Mal lief.
PASSED zeigt, welche Zeit vergangen ist, seitdem der Timer letztmalig
lief.
UNIT zeigt den Namen des Timers
ACTIVATES zeigt den Namen des Dienstes, den der Timer beim Laufen
aktiviert.
Siehe auch --all und --state=.
is-active MUSTER…
NEXT LEFT LAST PASSED UNIT ACTIVATES
- - Thu 2017-02-23 13:40:29 EST 3 days ago ureadahead-stop.timer ureadahead-stop.service
Sun 2017-02-26 18:55:42 EST 1min 14s left Thu 2017-02-23 13:54:44 EST 3 days ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
Sun 2017-02-26 20:37:16 EST 1h 42min left Sun 2017-02-26 11:56:36 EST 6h ago apt-daily.timer apt-daily.service
Sun 2017-02-26 20:57:49 EST 2h 3min left Sun 2017-02-26 11:56:36 EST 6h ago snapd.refresh.timer snapd.refresh.service
Prüft, ob eine der angegebenen Units
aktiv ist (d.h. läuft). Liefert einen Exit-Code von 0, falls
mindestens eine aktiv ist oder einen von Null verschiedenen Wert andernfalls.
Außer wenn --quiet angegeben ist, wird dies auch den aktuellen
Zustand der Unit auf der Standardausgabe ausgeben.
is-failed MUSTER…
Prüft, ob eine der angegebenen Units im
»fehlgeschlagenen« Zustand ist. Liefert einen Exit-Code von
0, falls mindestens eine fehlgeschlagen ist oder einen von Null
verschiedenen Wert andernfalls. Außer wenn --quiet angegeben
ist, wird dies auch den aktuellen Zustand der Unit auf der Standardausgabe
ausgeben.
status [MUSTER…|PID…]]
Zeigt Laufzeitstatusinformationen über
das gesamte System oder über eine oder mehrere Units, gefolgt von den
den jüngsten Protokolldaten aus dem Journal. Falls keine
positionsabhängigen Argumente angegeben sind und kein Unit-Filter mit
--type=, --state= oder --failed übergeben wurden,
wird der Status des gesamten Systems angezeigt. Falls mit --all
kombiniert, folgt diesem der Status aller Units. Falls
positionsabhängige Argumente angegeben wurden, wird jedes
positionsabhängige Argument als entweder ein anzuzeigender Unit-Name
oder als ein Glob-Muster, um Units anzuzeigen, deren Namen auf das Muster
passen oder als PID, um Units, die diese PID enthalten, anzuzeigen,
betrachtet. Wird --type=, --state= oder --failed
verwandt, werden Units zusätzlich durch den Zustand TYPE und ACTIVE
gefiltert.
Diese Funktion ist zur Erstellung menschenlesbarer Ausgabe gedacht. Falls Sie
nach Computer-auswertbarer Ausgabe suchen, verwenden Sie stattdessen
show. Standardmäßig zeigt diese Funktion nur die letzten
10 Ausgabezeilen und verkürzte Zeilen, um in das Terminal-Fenster zu
passen. Dies kann mit --lines und --full geändert werden,
siehe oben. Zusätzlich verwenden journalctl --unit=NAME
oder journalctl --user-unit=NAME einen ähnlichen Filter
für Nachrichten und könnten praktischer sein.
Beachten Sie, dass diese Aktion nur den Laufzeit-Status anzeigt, d.h.
Informationen über den aktuellen Aufruf der Unit (falls sie
läuft) oder den letzten Aufruf (falls sie nicht mehr läuft und
noch nicht vom Speicher freigegeben wurde). Informationen über
frühere Aufrufe, Aufrufe von vorhergehenden Systemstarts oder
frühere Aufrufe, bei denen bereits der Speicher freigegeben wurde,
könnten mittels journalctl --unit= abgerufen werden.
Systemd lädt Units implizit nach Notwendigkeit, daher wird die reine
Ausführung von status versuchen, eine Datei zu laden. Der Befehl
ist daher nicht nützlich, um zu bestimmen, ob etwas bereits geladen war
oder nicht. Die Units könnten sich auch schnell entladen, nachdem die
Aktion abgeschlossen ist, falls es keinen Grund gibt, sie danach im Speicher
zu halten.
Beispiel 1. Beispielausgabe von systemctl status
Der Punkt (»●«) verwendet auf unterstützten
Terminals Farbe, um den Unit-Zustand auf einen Blick zusammenzufassen.
Zusammen mit seiner Farbe ändert sich die Form entsprechend seines
Zustandes: »inaktiv« oder »Wartung« ist ein
weißer Kreis (»○«), »aktiv« ist ein
grüner Punkt (»●«), »Deaktivierend«
ist ein weißer Punkt, »Fehlgeschlagen« oder
»Fehler« ist ein rotes Kreuz (»×«) und
»Neuladend« ist ein grüner Kreispfeil im Uhrzeigersinn
(»↻«).
Die Zeile »Loaded:« in der Ausgabe wird »loaded«
anzeigen, falls die Unit in den Speicher geladen wurde. Andere mögliche
Werte für »Loaded:« sind u.A.: »error«,
falls es ein Problem beim Laden gab, »not-found«, falls
für diese Unit keine Unit-Datei gefunden wurde,
»bad-setting«, falls eine essenzielle Unit-Datei-Einstellung
nicht ausgewertet werden konnte und »masked«, falls die
Unit-Datei maskiert wurde. Zusammen mit dem Pfad zu der Unit-Datei wird diese
Zeile auch den Freigabezustand anzeigen. Freigegebene Units werden in das
Abhängigkeitsnetzwerk zwischen Units aufgenommen und daher beim
Systemstart oder über andere Art der Aktivierung gestartet. Lesen Sie
die vollständige Tabelle der möglichen Freigabezustände
— einschließlich der Definition von »masked« in
der Dokumentation für den Befehl »is-enabled«.
Die Zeile »Active:« zeigt den aktiven Zustand. Der Wert ist
normalerweise »active« oder »inactive«. Aktiv kann
gestartet, gebunden, eingesteckt usw., abhängig vom Unit-Typ, sein. Die
Unit könnte auch gerade dabei sein, ihre Zustände zu
ändern und einen Zustand »activating« oder
»deactivating« melden. Ein besonderer Zustand
»failed« wird erreicht, wenn der Zustand auf irgendeine Art,
z.B. durch einen Absturz, der Beendigung mit einem Fehler-Code oder einer
Zeitüberschreitung, fehlgeschlagen ist. Falls ein Fehlerzustand
erreicht wurde, wird der Grund protokolliert.
show [MUSTER…|AUFTRAG…]
$ systemctl status bluetooth
● bluetooth.service - Bluetooth service
Loaded: loaded (/lib/systemd/system/bluetooth.service; enabled; preset: enabled)
Active: active (running) since Wed 2017-01-04 13:54:04 EST; 1 weeks 0 days ago
Docs: man:bluetoothd(8)
Main PID: 930 (bluetoothd)
Status: "Running"
Tasks: 1
Memory: 648.0K
CPU: 435ms
CGroup: /system.slice/bluetooth.service
└─930 /usr/lib/bluetooth/bluetoothd
Jan 12 10:46:45 example.com bluetoothd[8900]: Not enough free handles to register service
Jan 12 10:46:45 example.com bluetoothd[8900]: Current Time Service could not be registered
Jan 12 10:46:45 example.com bluetoothd[8900]: gatt-time-server: Input/output error (5)
Zeigt die Eigenschaften einer oder mehrerer
Units, von Aufträgen oder dem Verwalter selbst. Falls kein Argument
angegeben ist, werden die Eigenschaften des Verwalters angezeigt. Falls ein
Unit-Name angegeben ist, werden die Eigenschaften der Unit angezeigt und falls
eine Auftragskennung angegeben ist, werden die Eigenschaften des Auftrags
angezeigt. Standardmäßig werden leere Eigenschaften
unterdrückt. Verwenden Sie --all, um diese auch anzuzeigen. Um
bestimmte anzuzeigende Eigenschaften auszuwählen, verwenden Sie
--property=. Dieser Befehl ist dazu gedacht, wannimmer
Computer-auswertbare Ausgabe benötigt wird. Verwenden Sie
status, falls Sie formatierte, menschenlesbare Ausgabe wünschen.
Viele durch systemctl show gezeigte Eigenschaften können direkt
auf Konfigurationseigenschaften des System- und Diensteverwalters und seiner
Unit-Dateien abgebildet werden. Beachten Sie, dass die durch den Befehl
angezeigten Eigenschaften im Allgemeinen systemnahe, normalisierte Versionen
der ursprünglichen Konfigurationseinstellungen sind und
zusätzlich zur Konfiguration Laufzeitzustand offenlegen. Eigenschaften
für Dienste-Units enthalten beispielsweise die Kennzeichnung des
aktuellen Hauptprozesses des Dienstes als »MainPID« (was
Laufzeitzustand ist) und die Zeiteinstellungen werden immer als Eigenschaften,
die in »…Sec« enden, offengelegt, da Mikrosekunden die
vom System- und Diensteverwalter intern verwandte normierte Zeiteinheit sind.
Für Details zu vielen dieser Eigenschaften lesen Sie die Dokumentation
der diesen Eigenschaften zugrundeliegenden D-Bus-Schnittstellen, siehe
org.freedesktop.systemd1(5).
cat MUSTER…
Zeigt zugrundeliegende Dateien von einer oder
mehr Units. Gibt die »Fragmente« und
»Ergänzungsdateien« (Quelldateien) von Units aus. Jeder
Datei wird ein Kommentar vorangestellt, der den Dateinamen enthält.
Beachten Sie, dass dieses die Inhalte der auf Platte zugrundeliegenden Dateien
anzeigt, was sich von dem unterscheiden kann, was der Systemverwalter von
diesen Units denkt, falls die Units seitdem aktualisiert wurden und nicht der
Befehl daemon-reload aufgerufen worden war.
help MUSTER…|PID…
Zeigt die Handbuchseiten für eine oder
mehrere Units, falls verfügbar. Falls eine PID übergeben wird,
wird die Handbuchseite für die Unit, zu der der Prozess gehört,
gezeigt.
list-dependencies [UNIT…]
Zeigt Units, die von den angegebenen Units
benötigt und gewünscht werden. Diese rekursive Liste folgt den
Abhängigkeiten Requires=, Requisite=, ConsistsOf=,
Wants=, BindsTo=. Falls keine Units angegeben sind, wird
default.target impliziert.
Standardmäßig werden nur Ziel-Units rekursiv expandiert. Wenn
--all übergeben wird, werden auch alle anderen Units rekursiv
expandiert.
Die Optionen --reverse, --after, --before können zur
Änderung, welche Abhängigkeitsarten gezeigt werden, verwandt
werden.
Beachten Sie, dass dieser Befehl nur die derzeit durch den Diensteverwalter im
Speicher geladenen Units aufführt. Insbesondere ist dieser Befehl nicht
dazu geeignet, eine vollständige Liste aller inversen
Abhängigkeiten einer bestimmten Unit zu erhalten, da es nicht die von
Units erklärten Abhängigkeiten aufführt, die derzeit
nicht geladen sind.
start MUSTER…
Startet (aktiviert) eine oder mehrere auf der
Befehlszeile angegebene Units.
Beachten Sie, dass Unit-Glob-Muster auf die Namen der Units, die momentan im
Arbeitsspeicher sind, expandieren. Units, die nicht aktiv und nicht in einem
fehlgeschlagenen Zustand sind, sind normalerweise nicht im Speicher und es
wird kein Muster auf sie passen. Bei instanziierten Units ist Systemd
zusätzlich oft in Unkenntnis über den Instanzennamen, bis die
Instanz gestartet wurde. Daher hat die Verwendung von Glob-Mustern mit
start nur begrenzten Nutzen. Auch werden sekundäre Alias-Namen
von Units nicht berücksichtigt.
Die Option --all kann auch zum Einsatz auf inaktive Units, die von
anderen geladenen Units referenziert werden, verwandt werden. Beachten Sie,
dass dies nicht identisch zum Einsatz auf »alle«
möglichen Units ist, da diese Liste nicht korrekt definiert ist, wie im
vorherigen Absatz beschrieben. Dennoch mag systemctl start --all
GLOB nützlich sein, falls alle Units, die auf das Muster
passen, durch ein Ziel hereingezogen werden, welches bekanntermaßen
geladen wird.
stop MUSTER…
Stoppt (deaktiviert) eine oder mehrere auf der
Befehlszeile angegebene Units.
Dieser Befehl wird fehlschlagen, falls die Unit nicht existiert oder falls das
Stoppen der Unit verboten ist (siehe RefuseManualStop= in
systemd.unit(5)). Er wird nicht fehlschlagen, falls einer der
für das Stoppen der Unit konfigurierten Befehle (( ExecStop=
usw.) fehlschlägt, da der Verwalter dennoch die Unit zwangsweise
beenden wird.
reload MUSTER…
Bittet alle auf der Befehlszeile
aufgeführten Units, ihre Konfiguration neu zu laden. Beachten Sie, dass
dies die Dienste-spezifische Konfiguration neu lädt, nicht die
Unit-Konfiguration von Systemd. Falls Sie möchten, dass Systemd die
Konfiguration einer Unit neu lädt, verwenden Sie den Befehl
daemon-reload. Mit anderen Worten: Im Falle von Apache wird dies die
httpd.conf neu in den Webserver laden, nicht die Systemd-Unit-Datei
apache.service.
Dieser Befehl sollte nicht mit dem Befehl daemon-reload verwechselt
werden.
restart MUSTER…
Stoppt und startet eine oder mehrere auf der
Befehlszeile übergebene Units. Falls die Units noch nicht laufen,
werden sie gestartet.
Beachten Sie, dass das Neustarten einer Unit mit diesem Befehl nicht
notwendigerweise alle Ressourcen der Unit herrausschreibt, bevor sie neu
gestartet wird. Beispielsweise wird die Dienste-bezogene
Dateideskriptorspeichereinrichtung (siehe FileDescriptorStoreMax= in
systemd.service(5)) intakt bleiben, solange ein Auftrag in der Unit
wartet und wird nur bereinigt, wenn die Unit komplett gestoppt wird und keine
Aufträge mehr warten. Falls gewünscht ist, dass der
Dateideskriptorspeicher auch rausgeschrieben wird, dann sollte während
der Neustartaktion ein expliziter Befehl systemctl stop gefolgt von
systemctl start eingegeben werden.
try-restart MUSTER…
Stoppt und startet eine oder mehrere auf der
Befehlszeile angegebene Units, falls die Units laufen. Dies ist wirkungslos,
falls die Units nicht laufen.
reload-or-restart MUSTER…
Lädt eine oder mehrere Units neu, falls
sie das unterstützen. Falls nicht, werden sie stattdessen gestoppt und
dann gestartet. Falls die Units noch nicht laufen, werden sie gestartet.
try-reload-or-restart MUSTER…
Lädt eine oder mehrere Units neu, falls
sie das unterstützen. Falls nicht, werden sie stattdessen gestoppt und
neugestartet. Dies ist wirkungslos, falls die Units nicht laufen.
isolate UNIT
Startet die auf der Befehlszeile angegebene
Unit und ihre Abhängigkeiten und stoppt alle anderen, außer sie
haben IgnoreOnIsolate=yes (siehe systemd.unit(5)). Falls ein
Unit-Name ohne Erweiterung angegeben wird, wird eine Erweiterung
».target« angenommen.
Dieser Befehl ist gefährlich, da er sofort Prozesse stoppen wird, die in
dem neuen Ziel nicht freigegeben sind, möglicherweise
einschließlich der graphischen Umgebung oder des Terminals, das Sie
gerade benutzen.
Beachten Sie, dass diese Aktion nur auf Units erlaubt ist, bei denen
AllowIsolate= aktiviert ist. Siehe systemd.unit(5) für
Details.
kill MUSTER…
Sendet ein Signal an einen oder mehrere
Prozesse der Unit. Verwenden Sie --kill-whom=, um den zu
tötenden Prozess auszuwählen. Verwenden Sie --signal=, um
das zu sendende Signal auszuwählen.
clean MUSTER…
Entfernt die Konfiguration, den Zustand, den
Zwischenspeicher, die Protokolle oder die Laufzeitdaten der angegebenen Units.
Verwenden Sie --what=, um auszuwählen, welche Ressourcenarten
Sie entfernen möchten.Für Dienste-Units kann dies zur Entfernung
von mit ConfigurationDirectory=, StateDirectory=,
CacheDirectory=, LogsDirectory= und RuntimeDirectory=
konfigurierten Verzeichnissen verwandt werden, siehe systemd.exec(5)
für Details. Für Timer-Units kann dies zur Bereinigung der
dauerhaften Zeitstempeldaten verwandt werden, falls Persistent=
eingesetzt und --what=state ausgewählt ist, siehe
systemd.timer(5). Dieser Befehl wird nur auf Unit angewandt, die eine
dieser Einstellungen verwenden. Falls --what= nicht angegeben ist,
werden sowohl die Zwischenspeicher- als auch die Laufzeitdaten entfernt (da
diese zwei Datenarten im Allgemeinen redundant und beim nächsten Aufruf
der Unit reproduzierbar sind).
freeze MUSTER…
Friert eine oder mehrere auf der Befehlszeile
angegebene Units mittels des Cgroup-Freezers ein.
Einfrieren einer Unit führt dazu, dass alle Prozesse in der der Unit
entsprechenden Cgroup suspendiert werden. Suspendiert sein bedeutet, dass die
Prozesse der Unit nicht zur Ausführung auf einer CPU eingeplant werden,
bis die Unit aufgetaut wird. Beachten Sie, dass dieser Befehl nur auf Systemen
unterstützt wird, die die vereinigte Cgroup-Hierarchie verwenden. Die
Unit wird automatisch aufgetaut, genau bevor ein Auftrag gegen die Unit
ausgeführt wird, z.B. bevor die Unit gestoppt wird.
thaw MUSTER…
Taut eine oder mehrere auf der Befehlszeile
angegebenen Units auf.
Dies ist die inverse Aktion zum Befehl freeze und nimmt die
Ausführung von Prozessen in der Cgroup der Unit wieder auf.
set-property UNIT
EIGENSCHAFT=WERT…
Setzt die angegebenen Unit-Eigenschaften zur
Laufzeit, wo dies unterstützt wird. Dies erlaubt die Änderung
von Konfigurationsparametereigenschaften wie Ressourcensteuereinstellungen zur
Laufzeit. Es können nicht alle Eigenschaften zur Laufzeit
geändert werden, aber viele Ressourcensteuereinstellungen
(primär die in systemd.resource-control(5)). Die
Änderungen werden sofort angewandt und auf Platte für
zukünftige Systemstarts gespeichert, außer --runtime wird
übergeben, wodurch die Einstellungen nur bis zum nächsten
Systemneustart angewandt werden. Die Syntax der Eigenschaftszuweisung folgt
eng der Syntax der Zuweisungen in Unit-Dateien.
Beispiel: systemctl set-property foobar.service CPUWeight=200
Falls die angegebene Unit-Datei inaktiv zu sein scheint, werden die
Änderungen nur wie früher beschrieben auf Platte gespeichert,
daher werden sie erst beim Starten der Unit zur Geltung kommen.
Beachten Sie, dass dieser Befehl das Ändern mehrerer Eigenschaften auf
einmal erlaubt, was gegenüber der individuellen Einstellung bevorzugt
werden sollte.
Beispiel: systemctl set-property foobar.service CPUWeight=200 MemoryMax=2G
IPAccounting=yes
Wie bei Unit-Konfigurationseinstellungen führt die Zuweisung der leeren
Einstellung normalerweise zum Zurücksetzen einer Eigenschaft auf ihre
Vorgaben.
Beispiel: systemctl set-property avahi-daemon.service
IPAddressDeny=
bind UNIT PFAD [PFAD]
Hängt eine Datei oder ein Verzeichnis
von dem Rechner in den angegebenen Einhänge-Namensraum der Unit mit
bind ein. Das erste Pfadargument ist die Quelldatei oder das Quellverzeichnis
auf dem Rechner, das zweite Pfadargument ist die Zieldatei oder das
Zielverzeichnis in dem Einhänge-Namensraum der Unit. Falls letzteres
fehlt, ist der Zielpfad in dem Einhänge-Namensraum der Unit identisch
zum Quellpfad im Rechner. Wird dies mit dem Schalter --read-only
kombiniert, dann wird eine nur-lesbare Bind-Einhängung erstellt. Wird
dies mit dem Schalter --mkdir kombiniert, dann wird der Zielpfad zuerst
erstellt, bevor die Einhängung angewandt wird.
Beachten Sie, dass diese Option zur Zeit nur für Units unterstützt
wird, die innerhalb eines Einhängenamensraums ausgeführt werden
(z.B.: mit RootImage=, PrivateMounts= usw.). Dieser Befehl
unterstützt die Bind-Einhängung von Verzeichnissen,
regulären Dateien, Geräteknoten, AF_UNIX-Socket-Knoten
sowie FIFOs. Die Bind-Einhängung ist flüchtig und wird sofort
zurückgenommen, sobald sich die Prozesse der aktuellen Unit beenden.
Beachten Sie, dass der hier erwähnte Namensraum, zu dem die
Bind-Einhängung hinzugefügt wird, derjenige ist, in dem der
Hauptdiensteprozess ausgeführt wird. Andere Prozesse (die von
ExecReload=, ExecStartPre= usw. ausgeführt werden) laufen
in einem dedizierten Namensraum.
mount-image UNIT ABBILD [PFAD [
PARTITIONSNAME: EINHÄNGEOPTIONEN]]
Hängt eine Abbild von dem Rechner in
den angegebene Einhänge-Namensraum der Unit ein. Das erste Pfadargument
ist das Quellabbild auf dem Rechner, das zweite Pfadargument ist das
Zielverzeichnis in dem Einhänge-Namensraum der Unit (d.h. innerhalb von
RootImage=/RootDirectory=). Die folgenden Argumente, falls
vorhanden, werden als Doppelpunkt-getrenntes Tupel von Partitionsnamen und
Kommata-getrennten Listen von Einhängeoptionen für diese
Partition interpretiert. Das Format ist identisch zu der Diensteeinstellung
MountImages=. Wird dies mit dem Schalter --read-only kombiniert,
dann wird eine nur-lesbare Einhängung erstellt. Wird dies mit dem
Schalter --mkdir kombiniert, dann wird der Zielpfad zuerst erstellt,
bevor die Einhängung angewandt wird.
Beachten Sie, dass diese Option zur Zeit nur für Units unterstützt
wird, die innerhalb eines Einhängenamensraums ausgeführt werden
(d.h. mit RootImage=, PrivateMounts= usw.). Beachten Sie, dass
der hier erwähnte Namensraum, zu dem die Abbild-Einhängung
hinzugefügt wird, derjenige ist, in dem der Hauptdiensteprozess
ausgeführt wird. Beachten Sie, dass der hier erwähnte
Namensraum, zu dem die Bind-Einhängung hinzugefügt wird, der
ist, in dem der Hauptdiensteprozess läuft. Andere Prozesse (die von
ExecReload=, ExecStartPre=, usw. ausgeführt werden),
laufen in einem dedizierten Namensraum.
Beispiel:
service-log-level DIENST [STUFE]
systemctl mount-image foo.service /tmp/img.raw /var/lib/image root:ro,nosuid
systemctl mount-image --mkdir bar.service /tmp/img.raw /var/lib/baz/img
Gibt die aktuelle Protokollierstufe, wie sie
von DIENST gemeldet wird, aus, falls das Argument STUFE nicht
angegeben ist.
Falls das optionale Argument STUFE bereitgestellt wird, dann wird die
aktuelle Protokollierstufe des Dienstes auf STUFE geändert. Die
Protokollierstufe sollte eine typische Syslog-Protokollierstufe sein, d.h. ein
Wert im Bereich 0…7 oder eine der Zeichenketten emerg,
alert, crit, err, warning, notice,
info, debug; siehe syslog(3) für Details.
Der Dienst muss über die geeignete Eigenschaft BusName=Ziel
verfügen und auch die generische Schnittstelle
org.freedesktop.LogControl1(5) implementieren. (Systemctl wird das
generische D-Bus-Protokoll zum Zugriff auf die Schnittstelle
org.freedesktop.LogControl1.LogLevel für den D-Bus-Namen Ziel
verwenden.)
service-log-target DIENST [ZIEL]
Gibt das aktuelle Protokollierziel, wie es von
DIENST gemeldet wird, aus, falls das Argument ZIEL nicht
angegeben ist.
Falls das optionale Argument ZIEL bereitgestellt wird, dann wird das
aktuelle Protokollierziel des Dienstes auf ZIEL geändert. Das
Protokollierziel sollte eine der Zeichenketten console (für das
Protokollieren in den Standardfehlerausgabestroms des Dienstes), kmsg
(für das Protokollieren in den Kernelprotokollpufer), journal
(für das Protokollieren nach systemd-journald.service(8) mittels
des nativen Journal-Protokolls), syslog (für das Protokollieren
in das klassische Syslog-Socket /dev/log), null (für keine
Protokollierung) oder auto (für eine automatisch bestimmte
Auswahl, typischerweise äquivalent zu console, falls der Dienst
interaktiv aufgerufen wurde und andernfalls journal oder syslog)
sein.
Für die meisten Dienste ergeben nur eine kleine Teilmenge der
Protokollierziele Sinn. Insbesondere sollten »normale« Dienste
nur console, journal und null implementieren. Alles
andere ist nur für systemnahe Dienste angemessen, die in der sehr
frühen Systemstartphase aktiv sind, bevor korrekte Protokollierung
etabliert ist.
Der Dienst muss über die geeignete Eigenschaft BusName=Ziel
verfügen und auch die generische Schnittstelle
org.freedesktop.LogControl1(5) implementieren. (Systemctl wird das
generische D-Bus-Protokoll zum Zugriff auf die Schnittstelle
org.freedesktop.LogControl1.LogLevel für den D-Bus-Namen Ziel
verwenden.)
reset-failed [MUSTER…]
Setzt den Zustand »failed« der
angegebenen Unit zurück oder, falls kein Unit-Name übergeben
wird, setzt den Zustand aller Units zurück. Wenn eine Unit auf
irgendeine Art fehlschlägt (d.h. sich der Prozess mit einem von Null
verschiedenen Fehler-Code beendet, sich abnormal beendet oder in eine
Zeitüberschreitung läuft), tritt sie automatisch in den Zustand
»failed« und ihr Exit-Code und ihr Status wird zur
Prüfung durch den Administrator aufgezeichnet, bis der Dienst
gestoppt/neugestartet oder mit diesem Befehl zurückgesetzt ist.
Zusätzlich zum Zurücksetzen des Status »failed«
einer Unit setzt dies auch verschiedene andere Unit-bezogene Eigenschaften
zurück: der Startratenbegrenzungszähler aller Unit-Typen wird
auf Null zurückgesetzt, wie auch der Neustartzähler von
Dienste-Units. Falls daher die Startbegrenzung (wie mit
StartLimitIntervalSec=/ StartLimitBurst= konfiguriert) einer
Unit erreicht wird und die Unit es ablehnt, erneut gestartet zu werden,
verwenden Sie diesen Befehl, um sie wieder startbar zu bekommen.
Unit-Dateibefehle
list-unit-files [MUSTER…]Listet auf dem System installierte Units
zusammen mit ihrem Freigabezustand (wie von is-enabled) gemeldet) auf.
Falls ein oder mehrere Muster angegeben sind, werden nur Units, deren Name auf
sie passen, gezeigt (Muster, die auf Unit-Dateisystempfade passen, werden
nicht unterstützt).
Anders als list-units wird dieser Befehl zusätzlich zu den
explizit instanziierten Units Vorlagenunits auflisten.
enable UNIT…, enable
PFAD…
Gibt eine oder mehrere Units oder
Unit-Instanzen frei. Dies wird eine Gruppe von Symlinks erzeugen, wie dies in
dem Abschnitt »[Install]« der angezeigten Unit-Dateien kodiert
ist. Nachdem die Symlinks erstellt wurden, wird die
Systemverwalterkonfiguration neu geladen (auf einer zu daemon-reload
äquivalenten Art), um sicherzustellen, dass die Änderungen
sofort berücksichtigt werden. Beachten Sie, dass dies nicht den
Effekt hat, dass die freigegebenen Units auch gestartet werden. Falls dies
gewünscht ist, kombinieren Sie den Befehl mit dem Schalter --now
oder rufen Sie später start mit geeigneten Argumenten auf.
Beachten Sie, dass bei der Freigabe von Unit-Instanzen (d.h. Freigabe von
Units der Form [email protected]) Symlinks mit dem gleichen Namen wie die
erstellten Instanzen im Unit-Konfigurationsverzeichnis erstellt werden,
allerdings zeigen sie auf die einzelne Vorlagen-Unit-Datei, aus der sie
instanziiiert wurden.
Dieser Befehl erwartet entweder gültige Unit-Namen (in diesem Fall werden
verschiedene Unit-Datei-Verzeichnisse automatisch nach Unit-Dateien mit
geeigneten Namen durchsucht) oder absolute Pfade zu Unit-Dateien (in diesem
Fall werden die Dateien direkt eingelesen). Falls eine angegebene Unit-Datei
sich außerhalb der gewöhnlichen Unit-Dateiverzeichnisse
befindet, wird ein zusätzlicher Symlink erstellt, der sie in den
Unit-Konfigurationspfad verlinkt, und daher sicherstellt, dass sie durch
Befehle wie start gefunden wird. Das Dateisystem, in dem sich die
verlinkten Unit-Dateien befinden, muss verfügbar sein, wenn Systemd
gestartet wird (z.B. ist alles unterhalb von /home/ oder /var/ nicht erlaubt,
außer diese Verzeichnisse befinden sich auf dem Wurzeldateisystem).
Dieser Befehl wird die ausgeführten Dateisystemaktionen ausgeben. Diese
Ausgabe kann durch Übergabe von --quiet unterdrückt
werden.
Beachten Sie, dass diese Aktion nur die in dem Abschnitt
»[Install]« der Unit-Dateien vorgeschlagenen Symlinks erstellt.
Obwohl dieser Befehl die empfohlene Art ist, das
Unit-Konfigurationsverzeichnis zu bearbeiten, steht es dem Administrator frei,
manuell zusätzliche Änderungen vorzunehmen, indem er in diesem
Verzeichnis Symlinks anlegt oder entfernt. Dies ist besonders nützlich,
um Konfigurationen zu erstellen, die von den vorgeschlagenen
Standardinstallationen abweichen. In diesem Falle muss der Administrator
sicherstellen, daemon-reload wo notwendig aufzurufen, um
sicherzustellen, dass die Änderungen berücksichtigt werden.
Freigeben von Units sollte nicht mit dem Starten (Aktivieren) verwechselt
werden, wie dies durch den Befehl start erfolgt. Freigeben und starten
von Units ist orthogonal: Units können freigegeben sein, ohne gestartet
zu sein und gestartet, ohne freigegeben zu sein. Die Freigabe hängt die
Unit an verschiedenen vorgeschlagenen Stellen ein (beispielsweise so, dass die
Unit automatisch beim Systemstart gestartet wird oder wenn ein bestimmte Art
von Hardware eingesteckt wird). Starten führt den Daemon-Prozess
tatsächlich aus (im Falle von Dienste-Units) oder bindet das Socket (im
Falle von Socket-Units) und so weiter.
Abhängig davon ob --system, --user, --runtime oder
--global angegeben wurde, gibt dies die Unit für das System, nur
den aufrufenden Benutzer, nur für diesen Systemstart oder für
alle zukünftigen Anmeldungen aller Benutzer frei. Beachten Sie, dass in
letzterem Fall keine Systemd-Daemonkonfiguration neu geladen wird.
Die Verwendung von enable auf maskierten Units wird nicht
unterstützt und führt zu einem Fehler.
disable UNIT…
Schaltet eine oder mehrere Units aus. Dies
entfernt alle Symlinks auf die Unit-Dateien, die den angegebenen Units aus dem
Unit-Konfigurationsverzeichnis hinterlegt sind und nimmt daher alle durch
enable oder link vorgenommenen Änderungen zurück.
Beachten Sie, dass dies alle Symlinks auf passende Unit-Dateien
entfernt, einschließlich manuell erstellter Symlinks, und nicht nur die
tatsächlich von enable oder link erstellten. Beachten
Sie, dass zwar disable den Effekt von enable
rückgängig macht, die zwei Befehle aber ansonsten nicht
symmetrisch sind, da disable mehr Symlinks entfernen könnte, als
ein vorheriger Aufruf von enable für die gleiche Unit erstellte.
Dieser Befehl erwartet nur gültige Unit-Namen, er akzeptiert keine Pfade
zu Unit-Dateien.
Zusätzlich zu den als Argument angegebenen Unit-Dateien werden alle Units
ausgeschaltet, die in der in Abschnitt »[Install]«
aufgeführten Einstellung Also= in jeder der Unit-Dateien, auf
die agiert wird, enthalten sind.
Dieser Befehl lädt implizit die Systemverwalterkonfiguration nach
Abschluss der Aktion neu. Beachten Sie, dass dieser Befehl die ausgeschalteten
Units nicht implizit stoppt. Falls dies gewünscht ist, kombinieren Sie
diesen Befehl entweder mit dem Schalter --now oder rufen Sie den Befehl
stop mit geeigneten Argumenten später auf.
Dieser Befehl wird Informationen über die ausgeführten
Dateisystemaktionen (Entfernung der Symlinks) ausgeben. Durch Übergabe
von --quiet kann diese Ausgabe unterdrückt werden.
Dieser Befehl berücksichtigt --system, --user,
--runtime und --global auf eine ähnliche Art wie
enable.
reenable UNIT…
Gibt eine oder mehrere Units erneut frei, wie
dies auf der Befehlszeile angegeben ist. Dies ist eine Kombination von
disable und enable und ist nützlich, um die Symlinks, mit
der eine Unit-Datei freigegeben wird, auf die in seinem Abschnitt
»[Install]« konfigurierten Vorgaben zurückzusetzen.
Dieser Befehl erwartet nur einen Unit-Namen und akzeptiert keine Pfade zu
Unit-Dateien.
preset UNIT…
Setzt den Status Freigegeben/Ausgeschaltet
einer oder mehrerer Unit-Dateien, wie auf der Befehlszeile angegeben, auf die
in den Voreinstellungsrichtliniendateien konfigurierten Standardwerte
zurück. Dies hat den gleichen Effekt wie disable oder
enable, abhängig davon, wie die Unit in den
Voreinstellungsdateien aufgeführt ist.
Verwenden Sie --preset-mode=, um zu steuern, ob Units freigegeben und
ausgeschaltet oder nur freigegeben oder nur ausgeschaltet sein sollen.
Falls die Unit keine Installationsinformationen überträgt, wird
sie durch diesen Befehl ohne Rückmeldung ignoriert. UNIT muss
ein echter Unit-Name sein, jeder Aliasname wird ohne Rückmeldung
ignoriert.
Weitere Informationen über das Format der Voreinstellungsrichtlinien
finden Sie unter systemd.preset(5).
preset-all
Setzt alle installierten Unit-Dateien auf die
in der Voreinstellungsrichtliniendatei konfigurierten Vorgaben zurück
(siehe oben).
Verwenden Sie --preset-mode=, um zu steuern, ob Units freigegeben und
ausgeschaltet oder nur freigegeben oder nur ausgeschaltet sein sollen.
is-enabled UNIT…
Prüft, ob eine der angegebenen
Unit-Dateien eingeschaltet ist (wie mit enable). Liefert einen
Exit-Code 0 zurück, falls mindestens eine freigegeben ist, andernfalls
eine von Null verschiedene Zahl. Gibt den derzeitigen Freigabestatus (siehe
Tabelle) aus. Um diese Ausgabe zu unterdrücken, verwenden Sie
--quiet. Um Installationsziele anzuzeigen, verwenden Sie --full.
Tabelle 1. Ausgabe von is-enabled
mask UNIT…
| Name | Beschreibung | Exit-Code |
| "enabled" | Über .wants/, .requires/ oder Alias=-Symlinks freigegeben (dauerhaft in /etc/systemd/system/ oder flüchtig in /run/systemd/system/). | 0 |
| "enabled-runtime" | ||
| "linked" | Über einen oder mehrere Symlinks auf die Unit-Datei verfügbar gemacht (dauerhaft in /etc/systemd/system/ oder flüchtig in /run/systemd/system/), obwohl die Unit-Datei selbst außerhalb des Unit-Dateisuchpfades liegen kann. | > 0 |
| "linked-runtime" | ||
| "alias" | Der Name ist ein Alias (Symlink auf eine andere Unit-Datei). | 0 |
| "masked" | Komplett ausgeschaltet, so dass jede Startaktion darauf fehlschlägt (dauerhaft in /etc/systemd/system/ oder flüchtig in /run/systemd/systemd/). | > 0 |
| "masked-runtime" | ||
| "static" | Die Unit-Datei ist nicht freigegeben und hat keine Vorkehrungen für die Freigabe in dem Unit-Dateiabschnitt »[Install]«. | 0 |
| "indirect" | Die Unit-Datei selbst ist nicht freigegeben, hat aber etwas in der Einstellung Also= im Abschnitt »[Install]« der Unit-Datei, wo andere Unit-Dateien aufgeführt sind, die freigegeben werden können, oder sie hat einen Alias unter einem anderen Namen durch einen Symlink, der nicht auch in Also= angegeben ist. Für Vorlagen-Unit-Dateien ist eine Instanz, die sich von der in DefaultInstance= angegebenen unterscheidet, freigegeben. | 0 |
| "disabled" | Die Unit-Datei ist nicht freigegeben, enthält aber einen Abschnitt »[Install]« mit Installationsanweisungen. | > 0 |
| "generated" | Die Unit wurde dynamisch mit einem Generatorwerkzeug erstellt. Siehe systemd.generator(7). Erstellte Unit-Dateien können nicht freigegeben werden, sie werden implizit durch ihren Generator freigegeben. | 0 |
| "transient" | Die Unit-Datei wurde dynamisch mit der Laufzeit-API erstellt. Flüchtige Units können nicht freigegeben werden. | 0 |
| "bad" | Die Unit-Datei ist ungültig oder ein anderer Fehler ist aufgetreten. Beachten Sie, dass is-enabled diesen Zustand nicht tatsächlich zurückliefern wird, sondern stattdessen eine Fehlermeldung ausgeben wird. Die durch list-unit-files dargestellte Unit-Datei-Auflistung könnte sie allerdings enthalten. | > 0 |
Blendet eine oder mehrere Units, wie auf der
Befehlszeile angegeben, aus. Dies wird die Unit-Dateien nach /dev/null linken,
wodurch sie nicht gestartet werden können. Dies ist eine
stärkere Version von disable, da sie alle Arten von Aktivierung
der Unit verbietet, einschließlich der Freigabe und manueller
Aktivierung. Verwenden Sie diese Option mit Vorsicht. Die Option
--runtime wird berücksichtigt, um nur bis zum nächsten
Systemneustart auszublenden. Die Option --now kann verwandt werden, um
sicherzustellen, dass die Units auch gestoppt werden. Dieser Befehl erwartet
nur gültige Unit-Namen, er akzeptiert keine Unit-Dateipfade.
unmask UNIT…
Blendet eine oder mehrere Unit-Dateien, wie
auf der Befehlszeile angegeben, ein. Dies macht die Wirkung von mask
rückgängig. Dieser Befehl erwartet nur gültige
Unit-Namen, er akzeptiert keine Unit-Dateipfade.
link PFAD…
Linkt eine Unit-Datei, die nicht im
Unit-Dateisuchpfad ist, in den Dateisuchpfad. Dieser Befehl erwartet einen
absoluten Pfad zu einer Unit-Datei. Die Wirkung kann mit disable
zurückgenommen werden. Die Wirkung des Befehls besteht darin, dass die
Unit-Datei für Befehle wie start verfügbar gemacht wird,
obwohl sie nicht direkt im Unit-Dateisuchpfad installiert ist. Das
Dateisystem, in dem sich die verlinkte Unit-Datei befindet, muss beim Start
von Systemd zugreifbar sein (d.h. alles unterhalb von /home/ oder /var/ ist
nicht erlaubt, außer diese Verzeichnisse befinden sich im
Wurzeldateisystem).
revert UNIT…
Bringt eine oder mehrere Unit-Dateien auf die
Version des Lieferanten zurück. Dieser Befehl entfernt
Ergänzungskonfigurationsdateien, die die angegebene Unit
verändern, sowie alle benutzerkonfigurierten Unit-Dateien, die eine
passende, vom Lieferanten bereitgestellte Unit-Datei außer Kraft
setzen. Konkret wird für eine Unit »foo.service« das
passende Verzeichnis »foo.service.d/« mit allen darin
enthaltenen Dateien entfernt, sowohl unterhalb der dauerhaften als auch der
Laufzeitkonfigurationsverzeichnisse (d.h. unterhalb von /etc/systemd/system
und /run/systemd/system). Falls es von der Unit-Datei eine durch den
Lieferanten bereitgestellte Version gibt (d.h. eine Unit-Datei unterhalb von
/usr/), werden alle passenden dauerhaften und Laufzeit-Unit-Dateien, die diese
außer Kraft setzen, auch entfernt. Beachten Sie, dass eine Unit-Datei,
für die es keine vom Lieferanten bereitgestellte Version gibt (d.h. sie
wurde nur unterhalb von /etc/systemd/system oder /run/systemd/system
definiert, aber nicht in einer Unit-Datei unterhalb von /usr/), nicht entfernt
wird. Falls eine Unit ausgeblendet ist, wird sie eingeblendet.
Dieser Befehl kann effektiv dazu verwandt werden, alle mit systemctl
edit, systemctl set-property und systemctl mask
vorgenommenen Änderungen zurückzusetzen und alle
ursprünglichen Unit-Dateien mit ihren Einstellungen wieder zur Wirkung
zu bringen.
add-wants ZIEL UNIT…, add-requires
ZIELUNIT…
Fügt zu dem ZIEL für eine
oder mehrere Units Abhängigkeiten »Wants=« bzw.
»Requires=« hinzu.
Dieser Befehl berücksichtigt --system, --user,
--runtime und --global auf eine ähnliche Art wie
enable.
edit UNIT…
Bearbeitet ein Ergänzungsschnippsel
oder eine gesamte Ersetzungsdatei, falls --full angegeben ist, oder
erweitert die angegebene Unit oder setzt sie außer Kraft.
Abhängig davon, ob --system (die Vorgabe), --user, oder
--global angegeben ist, erstellt dieser Befehl für jede Unit
eine Ergänzungsdatei, entweder für das System, für den
aufrufenden Benutzer oder für alle zukünftigen Anmeldungen aller
Benutzer. Dann wird der Editor (siehe den Abschnitt »Umgebung«
unten) mit temporären Dateien aufgerufen, die an den wirklichen Ort
geschrieben werden, falls der Editor erfolgreich beendet wird.
Falls --full angegeben ist, wird diese die ursprüngliche Unit
kopieren, statt Ergänzungsdateien zu erstellen.
Falls --force angegeben ist und eine der Units nicht existiert, werden
neue Unit-Dateien für die Bearbeitung geöffnet.
Falls --runtime angegeben ist, wird die Änderung temporär
in /run/ vorgenommen und geht beim nächsten Neustart verloren.
Falls die temporäre Datei beim Beenden leer ist, wird die Änderung
der zugehörigen Unit abgebrochen.
Nachdem die Units bearbeitet wurden, wird die Systemd-Konfiguration neu geladen
(auf eine Art, die äquivalent zu daemon-reload ist).
Beachten Sie, dass dieser Befehl nicht zur Bearbeitung ferner Units verwandt
werden kann und dass Sie keine Units, die in /etc/ liegen, temporär
bearbeiten können, da diese vor /run/ Vorrang haben.
get-default
Liefert das Standardziel, in welches der
Systemstart erfolgt, zurück. Dies liefert den Ziel-Unit-Namen, auf das
der Alias (Symlink) von default.target zeigt.
set-default ZIEL
Setzt das Vorgabeziel, in das der Systemstart
erfolgen soll. Dies setzt (als Symlink) den default.target-Alias auf die
angegebene Ziel-Unit.
Maschinenbefehle
list-machines [MUSTER…]Listet den Rechner und alle laufenden
Container mit ihren Zuständen auf. Falls eines oder mehrere
MUSTER angegeben sind, werden nur auf die Muster passende Container
angezeigt.
Auftragsbefehle
list-jobs [MUSTER…]Listet laufende Aufträge auf. Falls
eines oder mehrere MUSTER angegeben sind, werden nur Aufträge
von Units, die auf die Muster passen, angezeigt.
Wird dies mit --after oder --before kombiniert, wird die Liste mit
Informationen darüber angereichert, auf welchen anderen Auftrag jeder
Auftrag wartet und welche anderen Aufträge auf ihn warten, siehe
oben.
cancel AUFTRAG…
Bricht einen oder mehrere auf der Befehlszeile
durch ihre numerische Auftragskennung angegebene Aufträge ab. Falls
keine Auftragskennung angegeben ist, werden alle wartenden Aufträge
abgebrochen.
Umgebungsbefehle
systemd unterstützt einen Umgebungsblock, der an vom Systemverwalter erzeugte Prozesse übergeben wird. Die Namen der Variablen können ASCII-Buchstaben, Ziffern und das Unterstrichzeichen enthalten. Variablennamen dürfen nicht leer sein oder mit einer Ziffer starten. In den Variablenwerten sind die meisten Zeichen erlaubt, aber die gesamte Sequenz muss gültiges UTF-8 sein. (Beachten Sie, dass Steuerzeichen wie der Zeilenumbruch ( NL), der Tabulator (TAB) oder das Maskierzeichen ( ESC) gültiges ASCII und damit gültiges UTF-8 sind). Die Gesamtlänge des Umgebungsblocks ist auf den Wert _SC_ARG_MAX, der in sysconf(3) definiert ist, begrenzt. show-environmentZeigt den Umgebungsblock des
Systemd-Verwalters an. Dies ist der Umgebungsblock, der an alle vom Verwalter
erzeugten Prozesse übergeben wird. Der Umgebungsblock wird in einer
direkten Form, geeignet für die Einbindung in die meisten Shells,
ausgegeben. Falls in den Variablenwerten keine besonderen Zeichen oder
Leerraumzeichen enthalten sind, erfolgt keine Maskierung und die Zuweisungen
haben die Form »VARIABLE=Wert«. Falls Leerraumzeichen oder
Zeichen, die für die Shell eine besondere Bedeutung haben, vorhanden
sind, wird Dollar-Einzelanführungszeichen-Maskierung verwandt und die
Zuweisungen haben die Form »VARIABLE=$'Wert'«. Diese Syntax wird
bekanntermaßen von bash(1), zsh(1), ksh(1) und der
busybox(1)-ash(1), aber nicht von dash(1) und
fish(1) unterstützt.
set-environment VARIABLE=WERT…
Setzt eine oder mehrere
Systemd-Verwalter-Umgebungsvariablen, wie auf der Befehlszeile angegeben.
Dieser Befehl wird fehlschlagen, falls die Variablennamen und -werte nicht den
vorher beschriebenen Regeln folgen.
unset-environment VARIABLE…
Setzt eine oder mehrere Umgebungsvariablen des
Systemd-Verwalters zurück. Falls nur ein Variablenname angegeben ist,
wird er unabhängig von seinem Wert entfernt. Falls eine Variable und
ein Wert angegeben werden, wird die Variable nur entfernt, falls sie den
angegebenen Wert hat.
import-environment VARIABLE…
Importiert alle, eine oder mehrere
Umgebungsvariablen, die auf dem Client gesetzt sind, in den Umgebungsblock des
Systemd-Verwalters. Falls eine Liste mit einer oder mehrerer
Umgebungsvariablennamen übergeben wird, werden deren Wert auf der
Client-Seite dann in den Umgebungsblock des Verwalters importiert. Falls Namen
davon keine gültigen Umgebungsvariablen sind oder gemäß
der oben beschriebenen Regeln ungültige Werte haben, wird ein Fehler
ausgelöst. Falls keine Argumente übergeben werden, wird der
gesamte, vom Prozess systemctl geerbte Umgebungsblock importiert. In
diesem Modus werden alle geerbten und ungültigen Variablen
stillschweigend ignoriert.
Der Import des vollständigen ererbten Umgebungsblocks (der Aufruf dieses
Befehls ohne Argumente) ist als veraltet markiert. Eine Shell setzt Dutzende
von Variablen, die nur lokal Sinn ergeben und nur für Prozesse gedacht
sind, die Abkömmlinge der Shell sind. Solche Variablen sind im globalen
Umgebungsblock für andere Prozesse verwirrend.
Zustandsbefehle für den Verwalter
daemon-reloadLädt die Systemverwalterkonfiguration
neu. Dies wird alle Generatoren neu ausführen (siehe
systemd.generator(7)), alle Unit-Dateien neu laden und den gesamten
Abhängigkeitsbaum neu erstellen. Während der Daemon neu geladen
wird, bleiben sämtliche Sockets, an denen Systemd aufgrund von
Benutzerkonfiguration auf Anfragen wartet, erreichbar.
Dieser Befehl sollte nicht mit dem Befehl reload durcheinandergebracht
werden.
daemon-reexec
Führt den Systemd-Verwalter neu aus.
Dies wird den Verwalterzustand serialisieren, die Prozesse neu
ausführen und den Zustand wieder deserialisieren. Dieser Befehl ist
eigentlich nur für die Fehlersuche und Paket-Upgrades geeignet.
Manchmal mag er für schwergewichtige daemon-reload hilfreich
sein. Während der Daemon neu ausgeführt wird, bleiben
sämtliche Sockets, an denen Systemd aufgrund von Benutzerkonfiguration
auf Anfragen wartet, erreichbar.
log-level [STUFE]
Zeigt die aktuelle Protokollierstufe des
Verwalters an, falls kein Argument angegeben ist. Falls das optionale Argument
STUFE bereitgestellt wird, dann ändert der Befehl die aktuelle
Protokollierstufe des Verwalters auf STUFE (akzeptiert die gleichen
Werte wie für das in systemd(1) beschriebene
--log-level=).
log-target [ZIEL]
Zeigt das aktuelle Protokollierziel des
Verwalters an, falls kein Argument angegeben ist. Falls das optionale Argument
ZIEL bereitgestellt wird, dann ändert der Befehl das aktuelle
Protokollierziel des Verwalters auf ZIEL (akzeptiert die gleichen Werte
wie für das in systemd(1) beschriebene
--log-target=).
service-watchdogs [yes|no]
Zeigt den aktuellen Zustand des
Laufzeitdienste-Watchdogs an, falls kein Argument angegeben ist. Falls ein
optionales logisches Argument bereitgestellt wird, werden die globalen
Laufzeitdienste-Watchdogs ( WatchdogSec=) und Notfallaktionen (z.B.
OnFailure= oder StartLimitAction=) aktiviert oder deaktiviert;
siehe systemd.service(5). Der Hardware-Watchdog ist von dieser
Einstellung nicht betroffen.
Systembefehle
is-system-runningPrüft, ob das System
einsatzfähig ist. Dies liefert Erfolg (Exit-Code 0) zurück, wenn
das System komplett hochgefahren und im Betrieb und insbesondere nicht beim
Hochfahren, beim Herunterfahren oder im Wartungsmodus ist und wenn keine
Dienste fehlgeschlagen sind. Ansonsten wird ein Fehlschlag
zurückgeliefert (Exit-Code ist nicht null). Zusätzlich wird der
aktuelle Zustand in einer kurzen Zeichenkette auf der Standardausgabe
ausgegeben, siehe nachfolgende Tabelle. Verwenden Sie --quiet zum
Unterdrücken dieser Ausgabe.
Verwenden Sie --wait, um darauf zu warten, dass der Systemstartprozess
abgeschlossen ist, bevor der aktuelle Zustand angezeigt und der angemessene
Fehlerstatus zurückgeliefert wird. Falls --wait in Verwendung
ist, werden die Zustände initializing oder starting nicht
gemeldet, stattdessen wird der Befehl blockieren, bis ein späterer
Zustand (wie running oder degraded) erreicht ist.
Tabelle 2. Ausgabe von is-system-running
default
| Name | Beschreibung | Exit-Code |
| initializing | Früher Systemstart, vor basic.target erreicht oder der Wartungs- Zustand betreten wurde. | > 0 |
| starting | Späte Startphase, bevor die Auftragswarteschlange erstmalig in den Leerlauf geht oder eines der Rettungsziele erreicht wird. | > 0 |
| running | Das System ist komplett betriebsbereit. | 0 |
| degraded | Das System ist betriebsbereit, aber eine oder mehrere Units sind fehlgeschlagen. | > 0 |
| maintenance | Das Rettungs- oder Notfallziel ist aktiv. | > 0 |
| stopping | Der Verwalter fährt sich herunter. | > 0 |
| offline | Der Verwalter läuft nicht. Insbesondere ist dies der Betriebszustand, falls ein inkompatibles Programm als Systemverwalter (PID 1) läuft. | > 0 |
| unknown | Der Betriebszustand konnte aufgrund von fehlenden Ressourcen oder einer anderen Fehlerursache nicht bestimmt werden. | > 0 |
Betritt den Standardmodus. Dies ist zu
systemctl isolate default.target äquivalent. Diese Aktion
blockiert standardmäßig, verwenden Sie --no-block
für asynchrones Verhalten.
rescue
Betritt den Rettungsmodus. Dies ist zu
systemctl isolate rescue.target äquivalent. Diese Aktion
blockiert standardmäßig, verwenden Sie --no-block
für asynchrones Verhalten.
emergency
Betritt den Notfallmodus. Dies ist zu
systemctl isolate emergency.target äquivalent. Diese Aktion
blockiert standardmäßig, verwenden Sie --no-block
für asynchrones Verhalten.
halt
Fährt das System herunter und
hält es an. Dies ist größtenteils äquivalent zu
systemctl start halt.target --job-mode=replace-irreversibly --no-block,
gibt aber auch eine Wall-Nachricht an alle Benutzer aus. Dieser Befehl ist
asynchron; er wird zurückkehren, nachdem die Halt-Aktion in die
Warteschlange eingereiht ist, ohne darauf zu warten, dass er abgeschlossen
ist. Beachten Sie, dass diese Aktion einfach den Betriebssystemkernel nach dem
Herunterfahren anhalten wird, die Hardware verbleibt eingeschaltet. Verwenden
Sie systemctl poweroff, um das System auszuschalten (siehe unten).
Falls mit --force kombiniert, wird das Herunterfahren aller laufenden
Dienste übersprungen, alle Prozesse werden aber getötet und alle
Dateisysteme ausgehängt oder nur lesbar eingehängt, sofort
danach erfolgt das Anhalten des Systems. Falls --force zweimal
angegeben ist, wird die Aktion sofort ausgeführt, ohne irgendeinen
Prozess zu beenden oder ein Dateisystem auszuhängen. Dies kann zu
Datenverlust führen. Beachten Sie, dass die Halt-Aktion von
systemctl selbst ausgeführt wird, wenn --force zweimal
angegeben wird und der Systemverwalter dann nicht kontaktiert wird. Dies
bedeutet, dass der Befehl selbst dann erfolgreich sein sollte, wenn der
Systemverwalter abgestürzt ist.
poweroff
Fährt das System herunter und schaltet
es aus. Dies ist größtenteils zu systemctl start
poweroff.target --job-mode=replace-irreversibly --no-block
äquivalent, gibt aber auch eine Wall-Nachricht an alle Benutzer aus.
Dieser Befehl ist asynchron; er wird zurückkehren, nachdem die
Ausschalt-Aktion in die Warteschlange eingereiht ist, ohne darauf zu warten,
dass er abgeschlossen ist.
Falls mit --force kombiniert, wird das Herunterfahren aller laufenden
Dienste übersprungen, alle Prozesse werden aber getötet und alle
Dateisysteme ausgehängt oder nur lesbar eingehängt, sofort
danach erfolgt das Ausschalten des Systems. Falls --force zweimal
angegeben ist, wird die Aktion sofort ausgeführt, ohne irgendeinen
Prozess zu beenden oder ein Dateisystem auszuhängen. Dies kann zu
Datenverlust führen. Beachten Sie, dass die Ausschalt-Aktion von
systemctl selbst ausgeführt wird, wenn --force zweimal
angegeben wird und der Systemverwalter dann nicht kontaktiert wird. Dies
bedeutet, dass der Befehl selbst dann erfolgreich sein sollte, wenn der
Systemverwalter abgestürzt ist.
reboot
Fährt das System herunter und startet
es neu.
Dieser Befehl ist größtenteils zu systemctl start reboot.target
--job-mode=replace-irreversibly --no-block äquivalent, gibt aber
auch eine Wall-Nachricht an alle Benutzer aus. Dieser Befehl ist asynchron; er
wird zurückkehren, nachdem die Neustart-Aktion in die Warteschlange
eingereiht ist, ohne darauf zu warten, dass er abgeschlossen ist.
Falls mit --force kombiniert, wird das Herunterfahren aller laufenden
Dienste übersprungen, alle Prozesse werden aber getötet und alle
Dateisysteme ausgehängt oder nur lesbar eingehängt, sofort
danach erfolgt der Neustart des Systems. Falls --force zweimal
angegeben ist, wird die Aktion sofort ausgeführt, ohne irgendeinen
Prozess zu beenden oder ein Dateisystem auszuhängen. Dies kann zu
Datenverlust führen. Beachten Sie, dass die Neustart-Aktion von
systemctl selbst ausgeführt wird, wenn --force zweimal
angegeben wird und der Systemverwalter dann nicht kontaktiert wird. Dies
bedeutet, dass der Befehl selbst dann erfolgreich sein sollte, wenn der
Systemverwalter abgestürzt ist.
Falls der Schalter --reboot-argument= angegeben ist, wird er als
optionales Argument an den Systemaufruf reboot(2) übergeben.
Die Optionen --boot-loader-entry=, --boot-loader-menu= und
--firmware-setup können zur Auswahl, was nach einem
Neustart erfolgen soll, verwandt werden. Für Details siehe die
Beschreibung dieser Optionen.
kexec
Fährt das System herunter und startet
mit kexec neu. Dies ist zu systemctl start kexec.target
--job-mode=replace-irreversibly --no-block äquivalent. Dieser
Befehl ist asynchron; er wird zurückkehren, nachdem die Neustart-Aktion
in die Warteschlange eingereiht ist, ohne darauf zu warten, dass er
abgeschlossen ist.
Falls mit --force kombiniert, wird das Herunterfahren aller laufenden
Dienste übersprungen, alle Prozesse werden aber getötet und alle
Dateisysteme ausgehängt oder nur lesbar eingehängt, sofort
danach erfolgt der Neustart des Systems.
exit [EXIT-CODE]
Bittet den Diensteverwalter, sich zu beenden.
Dies wird nur für Benutzerdiensteverwalter (d.h. im Zusammenspiel mit
der Option --user) oder in Containern unterstützt und ist
andernfalls zu poweroff äquivalent. Dieser Befehl ist asynchron;
er wird zurückkehren, nachdem die Beende-Aktion in die Warteschlange
eingereiht ist, ohne darauf zu warten, dass er abgeschlossen ist.
Falls EXIT_CODE übergeben wurde, wird sich der Diensteverwalter
mit dem angegebenen Exit-Code beenden.
switch-root WURZEL [INIT]
Schaltet auf ein anderes Wurzelverzeichnis und
führt darunter einen neuen Systemverwalter aus. Dies ist für den
Einsatz in der Initrd gedacht und wird vom Systemverwalter der Initrd (d.h.
dem »Init«-Prozess) auf dem Hauptsystemverwalterprozess
wechseln, der vom tatsächlichen Wurzeldateisystem des Rechners geladen
wird. Dieser Aufruf akzeptiert zwei Argumente: das Verzeichnis, das das neue
Wurzelverzeichnis werden soll und der Pfad des neuen Systemverwalterprogramms
darunter, das als PID 1 ausgeführt werden soll. Falls letzterer nicht
angegeben wird oder die leere Zeichenkette ist, wird automatisch nach einem
Systemd-Programm gesucht und dieses als Init verwandt/. Falls der
Systemverwalterpfad nicht angegeben wird, der leeren Zeichenkette gleicht oder
identisch zu dem Pfad zu dem Systemdprogramm ist, wird der Zustand des
Systemverwalterprozesses der Initrd an den Hauptsystemverwalter
übergeben, womit Letzterem eine Selbstüberprüfung des
Zustands der in der Initird-Systemstartphase beteiligten Dienste
ermöglicht wird.
suspend
Suspendiert das System. Dies wird die
Aktivierung der besonderen Ziel-Unit suspend.target auslösen. Dieser
Befehl ist asynchron; er wird zurückkehren, nachdem die
Suspendier-Aktion erfolgreich in die Warteschlange eingereiht ist. Er wird
nicht darauf warten, dass der Suspendier-/Wiederaufnahmezyklus abgeschlossen
ist.
hibernate
Bringt das System in den Ruhezustand. Dies
wird die Aktivierung der besonderen Ziel-Unit hibernate.target
auslösen. Dieser Befehl ist asynchron; er wird zurückkehren,
nachdem die Ruhezustandsaktion erfolgreich in die Warteschlange eingereiht
ist. Er wird nicht darauf warten, dass der Ruhezustand-/Wiederaufwachzyklus
abgeschlossen ist.
hybrid-sleep
Bringt das System in den Ruhezustand und
suspendiert es. Dies wird die Aktivierung der besonderen Ziel-Unit
hybrid-sleep.target auslösen. Dieser Befehl ist asynchron; er wird
zurückkehren, nachdem die hybride Schlafaktion erfolgreich in die
Warteschlange eingereiht ist. Er wird nicht darauf warten, dass der
Schlaf-/Wiederaufwachzyklus abgeschlossen ist.
suspend-then-hibernate
Suspendiert das System nach einer in
systemd-sleep.conf angegebenen Verzögerung und bringt es in den
Ruhezustand. Dies wird die Aktivierung der besonderen Ziel-Unit
suspend-then-hibernate.target auslösen. Dieser Befehl ist asynchron; er
wird zurückkehren, nachdem die hybride Schlafaktion erfolgreich in die
Warteschlange eingereiht ist. Er wird nicht darauf warten, dass der
Schlaf-/Wiederaufwachzyklus oder Ruhezustand-/Wiederaufwachzyklus
abgeschlossen ist.
Parametersyntax
Die oben aufgeführten Unit-Befehle akzeptieren entweder einen einzelnen Unit-Namen (als UNIT bezeichnet) oder mehrere Unit-Angaben (als MUSTER … bezeichnet). Im ersten Fall muss der Unit-Name mit oder ohne Endung angegeben werden. Falls die Endung nicht angegeben ist (der Unit-Name »abgekürzt« wurde), wird Systemctl eine geeignete Endung anhängen, standardmäßig ».service«, und typabhängige Endungen im Falle von Befehlen, die nur auf bestimmte Unit-Typen agieren. Beispielsweise sind# systemctl start sshd
# systemctl start sshd.service
# systemctl isolate default
# systemctl isolate default.target
# systemctl status /dev/sda # systemctl status /home
# systemctl status dev-sda.device # systemctl status home.mount
# systemctl stop sshd@*.service
# systemctl enable foo.service
# systemctl link /path/to/foo.service
OPTIONEN
Die folgenden Optionen werden verstanden: -t, --type=Das Argument ist eine Kommata-getrennte Liste
der Unit-Typen wie service und socket. Wenn Units mit
list-units, show oder status aufgelistet werden, werden
nur die angegebenen Typen gezeigt. Standardmäßig werden Units
aller Typen angezeigt.
Als Spezialfall wird eine Liste der erlaubten Werte angezeigt und das Programm
beendet sich, falls eines der Argumente help ist.
--state=
Das Argument ist eine Kommata-getrennte Liste
von Zuständen LOAD, SUB oder ACTIVE sein. Zeigt nur die Units in den
angegebenen Zuständen an, wenn diese mit list-units, show
oder status aufgelistet werden. Verwenden Sie --state=failed
oder --failed, um nur fehlgeschlagene Units anzuzeigen.
Als Spezialfall wird eine Liste der erlaubten Werte angezeigt und das Programm
beendet sich, falls eines der Argumente help ist.
-p, --property=
Begrenzt die Anzeige auf die angegebenen
Eigenschaften bei der Anzeige der Eigenschaften von
Units/Aufträgen/Verwalter mit dem Befehl show. Das Argument
sollte eine Kommata-getrennte Liste von Eigenschaftsnamen wie
»MainPID« sein. Falls nicht angegeben, werden alle bekannten
Eigenschaften angezeigt. Falls mehr als einmal angegeben, werden alle
Eigenschaften mit den angegebenen Namen angezeigt. Für
Eigenschaftsnamen ist die Shell-Vervollständigung implementiert.
Für den Verwalter selbst wird systemctl show alle
verfügbaren Eigenschaften anzeigen. Die meisten davon sind von den in
systemd-system.conf(5) beschriebenen Optionen abgeleitet oder stimmen
eng mit ihnen überein.
Eigenschaften für Units unterscheiden sich zwischen Unit-Typen, daher ist
die Anzeige einer Unit (selbst einer nicht vorhandenen) ein Weg, um die
Eigenschaften, die diese Unit betreffen, aufzulisten. Ähnlich wird die
Anzeige eines Auftrags die allen Aufträgen zugehörigen
Eigenschaften auflisten. Eigenschaften für Units sind in
systemd.unit(5) und den Seiten für die individuellen Unit-Typen
systemd.service(5), systemd.socket(5) usw. dokumentiert.
-P
Äquivalent zu --value
--property=, d.h. zeigt den Wert der Eigenschaft ohne den
Eigenschaftsnamen und »=«. Beachten Sie, dass die einmalige
Verwendung von -P auch die mit -p/--property=
aufgeführten Eigenschaften betrifft.
-a, --all
Zeigt beim Auflisten von Units mit
list-units auch inaktive Units und Units, die anderen Units folgen, an.
Bei der Anzeige der Eigenschaften von Units/Aufträgen/Verwaltern werden
alle Eigenschaften angezeigt, unabhängig davon, ob sie gesetzt sind
oder nicht.
Um alle im Dateisystem installierten Units aufzulisten, verwenden Sie
stattdessen den Befehl list-unit-files.
Zeigt beim Auflisten von Units mit list-dependencies alle
abhängigen Units rekursiv an (standardmäßig werden nur
Abhängigkeiten von Ziel-Units angezeigt).
Zeigt bei der Verwendung mit status Journal-Nachrichten
vollständig an, selbst falls sie nicht darstellbaren Zeichen enthalten
oder sehr lang sind. Standardmäßig werden Felder mit nicht
darstellbaren Zeichen als »blob data« abgekürzt«.
(Beachten Sie, dass das Textanzeigeprogramm die nicht darstellbaren Zeichen
wieder maskieren könnte.)
-r, --recursive
Beim Auflisten von Units werden auch Units von
lokalen Containern angezeigt. Units von lokalen Containern wird der
Container-Name vorangestellt, getrennt durch einen einzelnen Doppelpunkt
(»:«).
--reverse
Zeigt mit list-dependencies inverse
Abhängigkeiten an, d.h. folgt Abhängigkeiten vom Typ
WantedBy=, RequiredBy=, PartOf=, BoundBy= statt
Wants= und ähnlichen.
--after
Zeigt mit list-dependencies Units an,
die vor der angegebenen Unit angeordnet sind. Mit anderen Worten, listet
rekursiv Units, die der Abhängigkeit After= folgen, auf.
Beachten Sie, dass jede Abhängigkeit After= automatisch gespiegelt
wird, um eine Abhängigkeit Before= zu erstellen.
Temporäre Abhängigkeiten können explizit angegeben
werden, werden aber auch implizit für Units mit den Zielen
WantedBy= (siehe systemd.target(5)) und als Ergebnis von anderen
Anweisungen (beispielsweise RequiresMountsFor=) erstellt. Sowohl
explizit als auch implizit eingeführte Abhängigkeiten werden mit
list-dependencies angezeigt.
Bei der Übergabe an den Befehl list-jobs wird für jeden
dargestellten Auftrag angezeigt, welche anderen Aufträge auf ihn
warten. Kann mit --before kombiniert werden, um sowohl die
Aufträge, die auf jeden Auftrag warten, als auch alle Aufträge,
auf die jeder Auftrag wartet anzuzeigen.
--before
Zeigt mit list-dependencies Units an,
die nach der angegebenen Unit angeordnet sind. Mit anderen Worten, listet
rekursiv Units, die der Abhängigkeit Before= folgen, auf.
Bei der Übergabe an den Befehl list-jobs wird für jeden
dargestellten Auftrag angezeigt, auf welche anderen Aufträge er wartet.
Kann mit --after kombiniert werden, um sowohl die Aufträge, die
auf jeden Auftrag warten, als auch alle Aufträge, auf die jeder Auftrag
wartet anzuzeigen.
--with-dependencies
Bei der Verwendung mit status,
cat, list-units und list-unit-files geben diese Befehle
alle angegebenen Units und die Abhängigkeiten von diesen Units aus.
Die Optionen --reverse, --after, --before können zur
Änderung, welche Abhängigkeitsarten gezeigt werden, verwandt
werden.
-l, --full
Verkürzt Unit-Namen,
Prozessbaumeinträge, Journal-Ausgabe nicht und schneidet
Unit-Beschreibungen in der Ausgabe von status, list-units,
list-jobs und list-timers nicht ab.
Zeigt auch Installationsziele in der Ausgabe von is-enabled an.
--value
Zeigt bei der Ausgabe der Eigenschaften mit
show nur den Wert an, der Eigenschaftsname und das »=«
wird übersprungen. Siehe auch obige Option -P.
--show-types
Zeigt bei der Anzeige von Sockets auch den Typ
des Sockets an.
--job-mode=
Beim Einstellen eines Auftrags in die
Warteschlangen steuert diese Option, wie mit bereits in der Warteschlange
befindlichen Aufträgen umgegangen werden soll. Sie akzeptiert entweder
»fail«, »replace«,
»replace-irreversibly«, »isolate«,
»ignore-dependencies«, »ignore-requirements«,
»flush« oder »triggering«.
Standardmäßig »replace«, außer wenn der
Befehl isolate verwandt wird, da dieser den Auftragsmodus
»isolate« impliziert.
Falls »fail« angegeben ist und die angeforderte Aktion in Konflikt
mit einem anhängigen Auftrag steht (genauer: dazu führt, dass
ein anhängiger Auftrag in einen Stopp-Auftrag oder umgedreht
umgewandelt wird), wird die Aktion fehlschlagen.
Falls (die Vorgabe) »replace« angegeben ist, wird jeder in
Konflikt stehende anhängige Auftrag falls notwendig ersetzt.
Falls »replace-irreversibly« angegeben ist, wird wie bei
»replace« agiert, aber die neuen Aufträge als unumkehrbar
markiert. Dies hindert zukünftige in Konflikt stehende Transaktionen
daran, diese Aufträge zu ersetzen (oder sie selbst daran, in die
Warteschlange aufgenommen zu werden, während die irreveresiblen
Aufträge noch anhängig sind). Irreversible Aufträge
können weiterhin mit dem Befehl cancel abgebrochen werden.
Dieser Auftragmodus sollte bei jeder Transaktion, die shutdown.target
hereinzieht, verwandt werden.
»isolate« ist nur für Startaktionen gültig und
führt dazu, dass alle anderen Units beendet werden, wenn die angegebene
Unit gestartet wird. Dieser Modus wird immer verwandt, wenn der Befehl
isolate verwandt wird.
»flush« führt dazu, dass alle Aufträge in der
Warteschlange abgebrochen werden, wenn der neue Auftrag in die Warteschlange
eingestellt wird.
Falls »ignore-dependencies« angegeben ist, werden alle
Unit-Abhängigkeiten für diesen neuen Auftrag ignoriert und die
Aktion wird sofort ausgeführt. Falls übergeben, werden keine
für die Unit benötigten Units hereingezogen und keine
Ordnungsabhängigkeiten berücksichtigt. Dies dient
hauptsächlich der Fehlersuche und als Rettungswerkzeug für den
Administrator und sollte von Anwendungen nicht verwandt werden.
»ignore-requirements« ist ähnlich zu
»ignore-dependencies«, führt aber nur dazu, dass die
Voraussetzungsabhängigkeiten ignoriert werden, die
Ordnungsabhängigkeiten werden weiterhin respektiert.
»triggering« kann nur mit systemctl stop verwandt werden.
In diesem Modus wird die angegebene Unit und alle aktiven Units, die es
auslöst, gestoppt. Siehe die Diskussion von Triggers= in
systemd.unit(5) für weitere Informationen über
auslösende Units.
-T, --show-transaction
Zeigt eine knappe Information über alle
Aufträge in der Warteschlange an, wenn eine Unit in die Warteschlange
gestellt wird (beispielsweise als Auswirkung des Aufrufs systemctl
start oder ähnlichem). Dabei werden sowohl die angeforderten
Aufträge als auch alle aufgrund von Unit-Abhängigkeiten
hinzugefügte berücksichtigt. Beachten Sie, dass die Ausgabe nur
Aufträge enthalten wird, die sofort Teil der angeforderten Transaktion
sind. Es ist möglich, dass die Ausführung des Programmcodes des
Dienstes zum Hochfahren die Auswirkung hat, dass die angeforderten
Aufträge dass Hereinziehen weiterer Aufträge anfordern. Das
bedeutet, dass beim Abschluss der angezeigten Aufträge letztendlich
mehr Aufträge als die angezeigten enthalten sein könnten.
--fail
Kurzform von --job-mode=fail.
Wird dies mit dem Befehl kill zusammen verwandt, wird die Aktion zu einem
Fehler führen, falls keine Units getötet wurden.
--check-inhibitors=
Diese Option steuert, wie das
Überprüfen der Unterdrückungssperren erfolgt, wenn das
Herunterfahren oder der Schlafzustand erbeten wurde. Sie akzeptiert entweder
»auto«, »yes« oder »no«.
Standardmäßig »auto«, das sich wie
»yes« für interaktive Aufrufe (d.h. von einem TTY) und
wie »no« für nicht interaktive Aufrufe verhalten wird.
»yes« ermöglicht es, dass die Anfrage
Unterdrückungssperren berücksichtigt. »no«
führt dazu, dass die Anfrage Unterdrückungssperren ignoriert.
Anwendungen können Unterdrückungssperren einrichten, um zu
verhindern, dass bestimmte wichtige Aktionen (wie das Brennen von CDs) durch
das Herunterfahren des Systems oder Schlafen unterbrochen werden. Jeder
Benutzer kann diese Sperren erlangen und privilegierte Benutzer dürfen
diese Sperren außer Kraft setzen. Falls irgendwelche Sperren erlangt
wurden, werden Anfragen zum Herunterfahren oder für
Schlafzustände normalerweise fehlschlagen (außer sie sind
privilegiert). Falls allerdings »no« oder »auto«
bei nicht interaktiven Anfragen angegeben wurde, wird die Aktion versucht.
Falls Sperren vorhanden sind, könnte die Aktion zusätzliche
Privilegien benötigen.
Die Option --force stellt eine andere Möglichkeit,
Unterdrücker außer Kraft zu setzen, bereit.
-i
Kurzform für
--check-inhibitors=no.
--dry-run
Gibt einfach aus, was getan würde.
Momentan von den Unterbefehlen halt, poweroff, reboot,
kexec, suspend, hibernate, hybrid-sleep,
suspend-then-hibernate, default, rescue, emergency
und exit unterstützt.
-q, --quiet
Unterdrückt die Ausgabe des Ergebnisses
der verschiedenen Befehle und auch die Hinweise auf abgeschnittene
Protokollzeilen. Dies unterdrückt nicht die Ausgabe von Befehlen,
für die die dargestellte Ausgabe das einzige Ergebnis ist (wie
show). Fehler werden immer ausgegeben.
--no-block
Wartet nicht synchron darauf, dass die
angefragte Aktion sich beendet. Falls dies nicht angegeben ist, wird der
Auftrag überprüft, in die Warteschlange eingereiht und
systemctl wartet, bis das Hochfahren der Unit abgeschlossen ist. Durch
Übergabe dieses Arguments wird nur überprüft und in die
Warteschlange eingereiht. Diese Option darf nicht mit --wait kombiniert
werden.
--wait
Wartet synchron darauf, dass gestartete Units
sich wieder beenden. Diese Option darf nicht mit --no-block kombiniert
werden. Beachten Sie, dass dies ewig warten wird, falls eine übergebene
Unit sich nie beendet (entweder selbst oder explizit gestoppt wird);
insbesondere Dienste, die »RemainAfterExit=yes« verwenden.
Wird dies zusammen mit is-system-running verwandt, wird gewartet, bis der
Systemstartprozess abgeschlossen ist, bevor zurückgekehrt wird.
--user
Kommuniziert mit dem Diensteverwalter des
aufrufenden Benutzers statt mit dem Diensteverwalter des Systems.
--system
Kommuniziert mit dem Diensteverwalter des
Systems. Dies ist die implizite Vorgabe.
--failed
Listet Units im fehlgeschlagenen Zustand auf.
Dies ist zu --state=failed äquivalent.
--no-wall
Versendet keine Wall-Nachrichten vor halt,
power-off und reboot.
--global
Agiert im globalen Benutzerverzeichnis, falls
mit enable und disable verwandt, und gibt somit eine Unit-Datei
global für alle zukünftigen Anmeldungen aller Benutzer frei oder
schaltetet sie aus.
--no-reload
Lädt Daemon-Konfiguration nach der
Ausführung der Änderung nicht implizit neu, falls mit
enable und disable verwandt.
--no-ask-password
Deaktiviert bei der Verwendung mit
start und verwandten Befehlen Fragen nach Passwörtern.
Hintergrunddienste können die Eingabe von Passwörtern oder
Passphrasenzeichenketten benötigten, beispielsweise um
Systemfestplatten oder kryptographische Zertifikate zu entsperren.
Außer wenn diese Option angegeben ist und der Befehl von einem Terminal
aus ausgeführt wird, wird systemctl den Benutzer auf dem
Terminal nach den notwendigen Geheimnissen fragen. Verwenden Sie diesen
Schalter, um das Verhalten abzuschalten. In diesem Fall muss das Passwort
über einen anderen Weg bereitgestellt werden (beispielsweise graphische
Passsworte-Agenten) oder der Service könnte fehlschlagen. Dies
deaktiviert auch die Abfrage des Benutzers für die Authentifizierung
für privilegierte Aktionen.
--kill-whom=
Bei der Verwendung mit kill
wählen Sie aus, welchen Prozessen ein Signal gesandt werden soll. Muss
einer aus main, control und all sein, um
auszuwählen, ob nur der Hauptprozess, der Steuerprozess oder alle
Prozess der Unit getötet werden soll(en). Der Hauptprozess der Unit ist
derjenige, der die Lebensdauer bestimmt. Ein Steuerprozess einer Unit ist
derjenige, der durch den Verwalter aufgerufen wird, um Statusänderungen
zu veranlassen. Beispielsweise sind alle Prozesse, die aufgrund von
ExecStartPre=-, ExecStop=- oder ExecReload=-Einstellungen
von Dienste-Units gestartet werden, Steuerprozesse. Beachten Sie, dass es
für jeden Zeitpunkt nur einen Steuerprozess pro Unit gibt, da nur eine
Statusänderung gleichzeitig ausgeführt wird. Für Dienste
vom Typ Type=forking ist der vom Verwalter für ExecStart=
initial gestartete Prozess der Steuerprozess, während der
schließlich mittels Fork gestartete Prozess dann als Hauptprozess der
Unit betrachtet wird (falls er bestimmt werden kann). Dies ist für
Dienste-Units von anderen Typen verschieden, wo der vom Verwalter für
ExecStart= mit Fork gestartete Prozess immer der Hauptprozess selbst
ist. Eine Dienste-Unit besteht aus keinem oder einem Hauptprozess, keinem oder
einem Steuerprozess sowie einer beliebigen Anzahl von zusätzlichen
Prozessen. Allerdings verwalten nicht alle Unit-Typen Prozesse dieser Typen.
Für Einhänge-Units sind beispielsweise Steuerprozesse definiert
(die die Aufrufe von /bin/mount und /bin/umount sind), aber es ist kein
Hauptprozess definiert. Falls weggelassen, ist die Vorgabe all.
-s, --signal=
Sucht bei der Verwendung mit kill das
Signal aus, das an ausgewählte Prozesse gesandt wird. Muss eines der
gut bekannten Signalkennungen wie SIGTERM, SIGINT oder
SIGSTOP sein. Falls weggelassen, ist die Vorgabe SIGTERM.
Der besondere Wert »help« wird alle bekannten Werte darstellen und
das Programm wird sich sofort beenden; der besondere Wert »list«
wird alle bekannten Werte zusammen mit ihren numerischen Signalnummern
darstellen und das Programm wird sich sofort beenden.
--what=
Wählt aus, welche Art von
Unit-bezogenen Ressourcen entfernt werden, wenn der Befehl clean
aufgerufen wird, siehe unten. Akzeptiert entweder configuration,
state, cache, logs oder runtime, um die Art der
Ressource auszuwählen. Diese Option kann mehr als einmal angegeben
werden, wodurch alle angegebenen Ressourcentypen entfernt werden. Akzeptiert
auch den besonderen Wert all, als Abkürzung zur Angabe aller
fünf Ressourcentypen. Falls diese Option nicht angegeben ist, ist die
Vorgabe die Kombination von cache und runtime, d.h. den zwei
Arten von Ressourcen, die im Allgemeinen als redundant betrachtet und beim
nächsten Aufruf rekonstruiert werden können.
-f, --force
Setzt bei der Verwendung mit enable
alle existierenden, im Konflikt stehenden Symlinks außer Kraft.
Erstellt bei der Verwendung mit edit alle angegebenen Units, die noch
nicht existieren.
Führt bei der Verwendung mit halt, poweroff, reboot
oder kexec die ausgewählten Aktionen ohne Herunterfahren aller
Units aus. Allerdings werden alle Prozesse zwangsweise beendet und alle
Dateisysteme ausgehängt oder neu nur lesbar wieder eingehängt.
Dies ist daher eine drastische, aber relativ sichere Option, um einen
sofortigen Neustart anzufragen. Falls --force zweimal für diese
Aktionen angegeben ist (mit der Ausnahme von kexec), werden sie sofort
ausgeführt, ohne alle Prozesse zu beenden oder Dateisysteme
auszuhängen. Warnung: Die zweifache Angabe von --force mit jeden
dieser Aktionen kann zu Datenverlust führen. Beachten Sie, dass bei
zweifacher Angabe von --force die ausgewählte Aktion von
systemctl selbst ausgeführt wird und kein Kontakt zum
Systemverwalter aufgenommen wird. Dies bedeutet, dass dieser Befehl
erfolgreich sein sollte, selbst wenn der Systemverwalter abgestürzt
ist.
--message=
Setzt bei der Verwendung mit halt,
poweroff oder reboot eine kurze Nachricht, die den Grund
für die Aktion beschreibt. Die Nachricht wird zusammen mit der
Standard-Herunterfahrnachricht protokolliert.
--now
Startet bei der Verwendung mit enable
die Units auch. Bei der Verwendung mit disable oder mask werden
die Units auch gestoppt. Die Start- oder Stopp-Aktion wird nur
durchgeführt, wenn die zugehörige Freigabe- oder Ausschaltaktion
erfolgreich war.
--root=
Verwendet beim Einsatz mit
enable/disable/ is-enabled (und verwandten Befehlen) die
angegebenen Wurzelpfade beim Suchen nach Unit-Dateien verwandt. Falls diese
Option vorhanden ist, wird systemctl auf dem Dateisystem direkt
arbeiten, statt mit dem Daemon systemd zu kommunizieren, um die
Änderungen auszuführen.
--image=Abbild
Akzeptiert einen Pfad zu einer
Plattenabbilddatei oder einem Blockgerätenamen. Falls angegeben, werden
alle Aktionen auf das Dateisystem in dem angegebenen Plattenabbild angewandt.
Diese Option ist ähnlich zu --root=, agiert aber auf
Dateisystemen, die in Plattenabbildern oder Blockgeräten gespeichert
sind. Das Plattenabbild sollte entweder nur ein Dateisystem oder eine Reihe
von Dateisystemen innerhalb einer GPT-Partitionstabelle enthalten, die der
Spezifikation für auffindbare Partitionen[1] folgt. Für
weitere Informationen über unterstützte Plattenabbilder, siehe
den Schalter von systemd-nspawn(1) mit dem gleichen Namen.
--runtime
Führt bei der Verwendung mit
enable, disable, edit (und verwandten Befehlen)
Änderungen nur temporär durch, so dass sie beim nächsten
Neustart verloren sind. Dies hat den Effekt, dass Änderungen nicht in
dem Unterverzeichnis von /etc/, sondern in /run/ durchgeführt werden,
mit identischen sofortigen Effekten, da allerdings die Änderungen bei
letzterem beim Neustart verloren gehen, gehen auch die Änderungen
verloren.
Ähnlich erfolgen bei der Verwendung mit set-property die
Änderungen nur temporär, so dass sie beim nächsten
Neustart verloren sind.
--preset-mode=
Akzeptiert »full« (die Vorgabe),
»enable-only« oder »disable-only«. Steuert bei der
Verwendung mit den Befehlen preset oder preset-all, ob Units
entsprechend der Voreinstellungsregeln ausgeschaltet oder freigegeben oder nur
freigegeben oder nur ausgeschaltet werden sollen.
-n, --lines=
Steuert bei der Verwendung mit status
die Anzahl der anzuzeigenden Journal-Zeilen, gezählt von der neuesten.
Akzeptiert als Argument eine positive Ganzzahl oder 0, um die Journal-Ausgabe
zu deaktivieren. Standardmäßig 10.
-o, --output=
Steuert bei der Verwendung mit status
die Formatierung der angezeigten Journal-Einträge. Für die
Auswahlmöglichkeiten siehe journalctl(1).
Standardmäßig »short«.
--firmware-setup
Zeigt der Firmware des Systems bei der
Verwendung mit dem Befehl reboot an, dass in die
Firmware-Einrichtungsschnittstelle neu gestartet werden soll. Beachten Sie,
dass diese Funktionalität nicht auf allen Systemen verfügbar
ist.
--boot-loader-menu=Zeitüberschreitung
Zeigt dem System-Bootloader im Zusammenhang
mit dem Befehl reboot an, dass der Bootloader beim nächsten
Systemstart das Bootloader-Menü anzeigen soll. Akzeptiert einen
Zeitwert als Parameter, der die Zeitüberschreitung des Menüs
angibt. Übergeben Sie Null, um die Zeitüberschreitung des
Menüs zu deaktivieren. Beachten Sie, dass nicht alle Bootloader diese
Funktionalität unterstützten.
--boot-loader-entry=Kennung
Zeigt dem System-Bootloader im Zusammenhang
mit dem Befehl reboot an, dass der Bootloader beim nächsten
Systemstart in einen bestimmten Bootloader-Eintrag starten soll. Akzeptiert
einen Bootlaoder-Eintragskennzeichner als Argument oder »help«,
um die verfügbaren Einträge anzuzeigen. Beachten Sie, dass nicht
alle Bootloader diese Funktionalität unterstützten.
--reboot-argument=
Dieser Schalter wird mit reboot
verwandt. Der Wert ist architektur- und firmwarespezifisch. Beispielsweise
könnte »recovery« zum Auslösen der
Systemwiederherstellung, »fota« könnte zum
Auslösen der schnurlosen Firmware-Aktualisierung verwandt werden.
--plain
Bei der Verwendung mit
list-dependencies, list-units oder list-machines wird die
Ausgabe als Liste statt als Baum dargestellt und die Aufzählungskreise
werden weggelassen.
--timestamp=
Ändert das Format der ausgegebenen
Zeitstempel. Die folgenden Werte können verwandt werden:
pretty (dies ist die Vorgabe)
--mkdir
"Tag YYYY-MM-DD HH:MM:SS TZ"
unix
"@seconds-since-the-epoch"
us, µs
"Tag YYYY-MM-DD HH:MM:SS.UUUUUU
TZ"
utc
"Tag YYYY-MM-DD HH:MM:SS UTC"
us+utc, µs+utc
"Tag YYYY-MM-DD HH:MM:SS.UUUUUU
UTC"
Wird dies mit bind verwandt, dann wird
die Zieldatei oder das Zielverzeichnis erstellt, bevor die
Bind-Einhängung angewandt wird. Beachten Sie, dass der Name dieser
Option zwar anzeigt, dass sie nur für Verzeichnisse geeignet ist, sie
aber auch den Zieldateiknoten, über den eingehängt werden soll,
falls das einzuhängende Objekt kein Verzeichnis, sondern eine
reguläre Datei, ein Geräteknoten, ein Socket oder ein FIFO ist,
erstellt.
--marked
Nur zusammen mit reload-or-restart
erlaubt. Stellt Neustartaufträge für alle Units, die die
Markierung »needs-restart« tragen und Neulade-Aufträge
für Units, die die Markierung »needs-reload« tragen, in
die Warteschlange. Wenn eine Unit, die zum Neuladen markiert ist, kein
Neuladen unterstützt, dann wird ein Neustart in die Warteschlange
eingestellt. Diese Eigenschaften können mittels set-property
Markers=… gesetzt werden.
systemctl wird darauf warten, dass in die Warteschlange eingestellte
Aufträge sich beenden, außer wenn --no-block verwandt
wird.
--read-only
Erstellt bei der Verwendung mit bind
eine nur lesbare Bind-Einhängung.
-H, --host=
Führt die Aktion aus der Ferne aus.
Geben Sie den Rechnernamen oder einen Benutzernamen und Rechnernamen (getrennt
durch »@«) an, zu dem verbunden werden soll. Dem Rechnernamen
darf optional ein Port, auf dem SSH auf Anfragen wartet, getrennt durch
»:« und dann ein Container auf dem angegebenen Host
angehängt werden, womit direkt zu einem bestimmten Container auf dem
angegebenen Rechner verbunden wird. Dies verwendet SSH, um mit der
Maschinen-Verwalterinstanz auf dem Rechner in der Ferne zu kommunizieren.
Container-Namen dürfen mit machinectl -H RECHNER
aufgezählt werden. Stellen Sie IPv6-Adressen in Klammern.
-M, --machine=
Führt die Aktion in einem lokalen
Container aus. Geben Sie den Namen des Containers an, zu dem verbunden werden
soll. Optional kann diesem ein Benutzername, abgetrennt durch ein
»@«-Zeichen, als der verbunden werden soll, vorangestellt
werden. Falls die besondere Zeichenkette ».host« anstelle des
Container-Names verwandt wird, wird eine Verbindung zu dem lokalen System
aufgebaut (das ist nützlich, um sich zu dem Benutzerbus eines
bestimmten Benutzers zu verbinden: »--user
--machine=[email protected]«. Falls die »@«-Syntax nicht
verwandt wird, wird die Verbindung als Benutzer »root«
vorgenommen. Falls die »@«-Syntax verwandt wird, kann entweder
die linke oder die rechte Seite fortgelassen werden (aber nicht beide). In
diesem Fall wird der lokale Benutzername und ».host«
angenommen.
--no-pager
Leitet die Ausgabe nicht an ein
Textanzeigeprogramm weiter.
--legend=LOGISCH
Aktiviert oder deaktiviert die Ausgabe der
Legende, d.h. der Spaltenüberschriften und der Fußzeile mit
Hinweisen. Standardmäßig wird die Legende ausgegeben,
außer dies wurde mit --quiet oder ähnlichem
deaktiviert.
-h, --help
Zeigt einen kurzen Hilfetext an und beendet
das Programm.
--version
Zeigt eine kurze Versionszeichenkette an und
beendet das Programm.
EXIT-STATUS
Bei Erfolg wird 0 zurückgegeben, anderenfalls ein Fehlercode ungleich Null. systemctl verwendet die durch LSB definierten Rückgabewerte, wie sie in LSB 3.0.0[2] definiert sind.| Wert | Beschreibung in LSB | Verwendung in Systemd |
| 0 | "Programm läuft oder Dienst ist OK" | Unit ist aktiv |
| 1 | "Programm ist tot und /var/run-PID-Datei existiert" | Unit ist nicht fehlgeschlagen (von is-failed verwandt) |
| 2 | "Programm ist tot und /var/lock-Sperrdatei existiert" | nicht verwandt |
| 3 | "Programm läuft nicht" | Unit ist nicht aktiv |
| 4 | "Programm- oder Dienstezustand unbekannt" | keine solche Unit |
UMGEBUNGSVARIABLEN
$SYSTEMD_EDITORDer bei der Bearbeitung von Units zu
verwendende Editor: setzt $EDITOR und $VISUAL außer
Kraft. Falls weder $SYSTEMD_EDITOR, $EDITOR noch $VISUAL
vorhanden sind oder falls es auf eine leere Zeichenkette gesetzt ist oder
falls seine Ausführung fehlschlug, wird Systemctl versuchen, gut
bekannte Editoren in dieser Reihenfolge auszuführen: editor(1),
nano(1), vim(1), vi(1).
$SYSTEMD_LOG_LEVEL
Die maximale Protokollierstufe ausgesandter
Nachrichten (Nachrichten mit einer höheren Protokollierstufe, d.h.
weniger wichtige, werden unterdrückt). Sie muss (in absteigender
Reihenfolge) entweder alert, crit, err, warning,
notice, info, debug oder eine Ganzzahl im Bereich
0…7 sein. Siehe syslog(3) für weitere
Informationen.
$SYSTEMD_LOG_COLOR
Ein logischer Wert. Falls wahr, werden auf das
TTY geschriebene Nachrichten gemäß ihrer Priorität
eingefärbt.
Diese Einstellung ist nur nützlich, falls die Nachrichten direkt auf das
Terminal geschrieben werden, da journalctl(1) und andere Werkzeuge, die
Protokolle anzeigen, selbständig Nachrichten gemäß ihrer
Protokollierungsstufe einfärben.
$SYSTEMD_LOG_TIME
Ein logischer Wert. Falls wahr, wird den
Protokollnachrichten der Konsole ein Zeitstempel vorangestellt.
Diese Einstellung ist nur nützlich, falls die Nachrichten direkt auf das
Terminal oder in eine Datei geschrieben werden, da journalctl(1) und
andere Werkzeuge, die Protokolle anzeigen, selbständig Zeitstempel
basierend auf ihren Metadaten den Nachrichten anhängen werden.
$SYSTEMD_LOG_LOCATION
Ein logischer Wert. Falls wahr, wird den
Protokollnachrichten ein Dateinamen und eine Zeilenummer in dem Quellcode, aus
dem die Nachrichten stammen, vorangestellt.
Beachten Sie, dass der Protokollierort sowieso oft als Metadaten zu den
Journal-Einträgen angehängt ist. Die Aufnahme in den
Nachrichtentext kann bei der Fehlersuche in Programmen dennoch praktisch
sein.
$SYSTEMD_LOG_TARGET
Das Ziel für Protokolliernachrichten.
Entweder console (auf das angehängte TTY protokollieren),
console-prefixed (auf das angehängte TTY protokollieren, aber
die Protokollierstufe und »Einrichtung« voranstellen, siehe
syslog(3)), kmsg (in den zirkulären
Kernel-Protokollpuffer protokollieren), journal (in das Journal
protokollieren ( journal-or-kmsg (in das Journal protokollieren, falls
verfügbar, und andernfalls nach Kmsg), auto (das geeignete
Protokollierziel automatisch ermitteln, die Vorgabe) oder null (die
Protokollierung deaktivieren).
$SYSTEMD_PAGER
Zu verwendendes Textanzeigeprogramm, wenn
--no-pager nicht angegeben ist; setzt $PAGER außer Kraft.
Falls weder $SYSTEMD_PAGER noch $PAGER gesetzt sind, wird eine
Reihe wohlbekannter Textanzeigeprogrammimplementierungen der Reihe nach
ausprobiert, einschließlich less(1) und more(1), bis
eines gefunden wird. Falls keine Textanzeigeprogrammimplementierung gefunden
wird, wird keines aufgerufen. Setzen der Umgebungsvariablen auf die leere
Zeichenkette oder den Wert »cat« ist äquivalent zur
Übergabe von --no-pager.
Beachten Sie: Falls $SYSTEMD_PAGERSECURE nicht gesetzt ist, dann wird
$SYSTEMD_PAGER (sowie $PAGER) ohne Rückmeldung
ignoriert.
$SYSTEMD_LESS
Setzt die an less übergebenen
Optionen (standardmäßig »FRSXMK«) außer
Kraft.
Benutzer könnten insbesondere zwei Optionen ändern wollen:
K
Siehe less(1) für weitere Ausführungen.
$SYSTEMD_LESSCHARSET
Diese Option weist das Textanzeigeprogramm an,
sich sofort beim Druck von Strg-C zu beenden. Um less die Handhabung
von Strg-C selbst zum Umschalten auf die Eingabeaufforderung zu erlauben,
setzen Sie diese Option zurück.
Falls der Wert von $SYSTEMD_LESS kein »K« enthält
und less das aufgerufene Textanzeigeprogramm ist, wird Strg+C durch das
Programm ignoriert und muss durch das Textanzeigeprogramm selbst gehandhabt
werden.
X
Diese Option weist das Textanzeigeprogramm an,
keine Termcap-Initialisierungs- und -Deinitalisierungszeichenketten an das
Terminal zu senden. Dies ist standardmäßig gesetzt, damit die
Darstellung von Befehlen selbst nach dem Beenden des Textanzeigeprogramms
sichtbar bleibt. Allerdings stehen dadurch einige Funktionen des
Textanzeigeprogramms nicht zur Verfügung; insbesondere ist das Scrollen
in der Ausgabe mit der Maus nicht möglich.
Setzt den an less zu
übergebenden Zeichensatz (standardmäßig
»utf-8«, falls das aufrufende Terminal als UTF-8-kompatibel
erkannt wurde) außer Kraft.
$SYSTEMD_PAGERSECURE
Akzeptiert einen logischen Wert. Wenn wahr,
wird der »sichere« Modus des Seitenanzeigeprogramms verwandt,
falls falsch, wird dieser deaktiviert. Falls $SYSTEMD_PAGERSECURE
überhaupt nicht gesetzt ist, dann wird der sichere Modus aktiviert,
falls die effektive Kennung nicht identisch zu dem Eigentümer der
Anmeldesitzung ist, siehe geteuid(2) und
sd_pid_get_owner_uid(3). Im sicheren Modus wird LESSSECURE=1
beim Aufruf des Seitenanzeigeprogramms gesetzt und das Seitenanzeigeprogramm
muss Befehle deaktivieren, die neue Dateien öffnen oder erstellen oder
die einen neuen Unterprozess starten. Falls $SYSTEMD_PAGERSECURE
überhaupt nicht gesetzt ist, werden Seitenanzeigeprogramme, bei denen
unbekannt ist, ob sie einen sicheren Modus implementieren, nicht verwandt.
(Derzeit implementiert nur less(1) einen sicheren Modus.)
Hinweis: Wenn Befehle mit erhöhten Rechten ausgeführt werden,
beispielsweise mittels sudo(8) oder pkexec(1), muss Vorsicht
walten gelassen werden, um sicherzustellen, dass keine ungeplanten
interaktiven Funktionalitäten aktiviert werden. Der
»sichere« Modus für das Seitenanzeigeprogramm kann wie
oben beschrieben automatisch aktiviert werden. Durch Setzen von
SYSTEMD_PAGERSECURE=0 oder durch Nichtenfernen dieser Einstellung aus
der ererbten Umgebung wird es dem Benutzer ermöglicht, beliebige
Befehle auszuführen. Beachten Sie, dass auch
$SYSTEMD_PAGERSECURE gesetzt werden muss, falls die Variablen
$SYSTEMD_PAGER oder $PAGER berücksichtigt werden sollen.
Es kann sinnvoll sein, stattdessen den Seitenanzeiger komplett mit
--no-pager zu deaktivieren.
$SYSTEMD_COLORS
Akzeptiert ein logisches Argument. Wenn wahr,
werden systemd und verwandte Hilfswerkzeuge Farben in ihrer Ausgabe
verwenden, andernfalls wird die Ausgabe einfarbig sein. Zusätzlich kann
die Variable eine der folgenden besonderen Werte annehmen: »16«,
»256«, um die Verwendung von Farbe auf die grundlegenden 16 bzw.
256 ANSI-Farben zu beschränken. Dies kann festgelegt werden, um die auf
$TERM und der vorliegenden Verbindung der Konsole basierende
automatische Entscheidung außer Kraft zu setzen.
$SYSTEMD_URLIFY
Dies muss ein logischer Wert sein. Er steuert,
ob anklickbare Links für Terminal-Emulatoren, die dies
unterstützen, erstellt werden sollen. Dies kann angegeben werden, um
die Entscheidung, die systemd basierend auf $TERM und anderen
Bedingungen trifft, außer Kraft zu setzen.
SIEHE AUCH
systemd(1), journalctl(1), loginctl(1), machinectl(1), systemd.unit(5), systemd.resource-control(5), systemd.special(7), wall(1), systemd.preset(5), systemd.generator(7), glob(7)ANMERKUNGEN
- 1.
- Spezifikation für auffindbare Partitionen
- 2.
- LSB 3.0.0
ÜBERSETZUNG
Die deutsche Übersetzung dieser Handbuchseite wurde von Helge Kreutzmann <[email protected]> erstellt. Diese Übersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 3 oder neuer bezüglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG übernommen. Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an die Mailingliste der Übersetzer| systemd 252 |