Systemctl: Unterschied zwischen den Versionen

Aus Foxwiki
Subpages:
Versionsgeschichte interaktiv durchsuchen
← Zum vorherigen Versionsunterschied
VisuellWikitext
K Textersetzung - „== Syntax ==“ durch „== Aufruf ==“
 
(22 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 2: Zeile 2:


== Beschreibung ==
== Beschreibung ==
== Installation ==
'''systemctl''' kann zum Prüfen und Steuern des Zustandes des »Systemd«-Systems und -Diensteverwalters verwandt werden
== Syntax ==
* Bitte lesen Sie systemd(1) für eine Einführung in die grundlegenden Konzepte und Funktionalitäten, die dieses Werkezeug verwaltet
'''systemctl [OPTIONEN…] BEFEHL [UNIT…]'''


=== Optionen ===
Wer nur an bestimmten Units interessiert ist, kann die Anzeige über den Parameter "--type=" einschränken
=== Parameter ===
* Alle Dienste präsentiert etwa "systemctl --type=service"
=== Umgebungsvariablen ===
* Die Ausgaben von "systemctl" zeigt standardmäßig "less" an, die Navigation erfolgt mit den Pfeiltasten und der Leertaste, [q] wiederum beendet die Anzeige
=== Exit-Status ===
* Neben dem Namen der Unit verrät "systemctl" in der zweiten und dritten Spalte, ob es die Unit laden und aktivieren konnte
* Die Spalte "SUB" gibt Auskunft über den derzeitigen Status: Bei einem Dateisystem erfährt man etwa, ob dieses gemountet ist, bei einem Dienst hingegen, ob dieser läuft ("running")
* In der letzten Spalte findet man schließlich noch eine kurze Beschreibung der Unit
* Sofern ein Dienst beim Start nicht hochfahren wollte oder abgestürzt ist, markiert "systemctl" dies in seiner Ausgabe in hell leuchtendem Rot
* Eine Liste mit allen nicht funktionierenden Units liefert "systemctl --failed", detaillierte Informationen über eine Unit zeigt ein Aufruf von "systemctl status" an
* In bestimmten Situationen erzeugt Systemd selbst eine Unit
* Das passiert beispielsweise nach dem Anstöpseln eines neuen Gerätes
* Die dann unter Umständen mithilfe von Udev generierten Units erscheinen zwar in der Ausgabe von "systemctl", es existieren aber keine passenden Unit-Dateien auf der Festplatte
* Von diesen dynamisch generierten Units dürfen aber wiederum andere Units abhängen


== Installation ==
== Anwendung ==
== Anwendung ==
=== Fehlerbehebung ===
[[File:systemdCommands.jpg|mini|400px|[https://www.instagram.com/p/C6lgUh8AULu/ Useful systemd commands on Linux]]]
== Konfiguration ==
=== Dienste verwalten ===
=== Dateien ===
Der grundlegende Zweck eines Init-Systems ist die Initialisierung der Komponenten, die nach dem Booten des Linux-Kernels gestartet werden müssen (traditionell als „userland“-Komponenten bekannt)
<noinclude>
* Das Init-System wird auch dazu verwendet, Dienste und Daemons für den Server zu jedem Zeitpunkt während des Systembetriebs zu verwalten
== Anhang ==
* Vor diesem Hintergrund beginnen wir mit einigen grundlegenden Operationen zur Verwaltung von Diensten
=== Siehe auch ===
{{Special:PrefixIndex/{{BASEPAGENAME}}}}
----
* [[cgroups]]
 
==== Dokumentation ====
===== Man-Pages =====
===== Info-Pages =====
==== Links ====
===== Projekt =====
===== Weblinks =====
 
{{DISPLAYTITLE:systemctl}}


= TMP =
In systemd sind die meisten Aktionen auf „Einheiten“ (sog
== Beschreibung ==
* Units) ausgerichtet, wobei es sich um Ressourcen handelt, die systemd verwalten kann
* systemctl kann zum Prüfen und Steuern des Zustandes des »Systemd«-Systems und -Diensteverwalters verwandt werden.
* Einheiten werden nach der Art der Ressource, die sie repräsentieren, kategorisiert und mit Dateien definiert, die als Unit-Dateien bekannt sind
* Bitte lesen Sie systemd(1) für eine Einführung in die grundlegenden Konzepte und Funktionalitäten, die dieses Werkezeug verwaltet.
* Die Art jeder Einheit kann aus dem Suffix am Ende der Datei abgeleitet werden


* Wer nur an bestimmten Units interessiert ist, kann die Anzeige über den Parameter "--type=" einschränken.  
Für Dienstverwaltungsaufgaben ist die Zieleinheit die Diensteinheiten, die Unit-Dateien mit dem Suffix .service aufweisen
* Alle Dienste präsentiert etwa "systemctl --type=service".
* Bei den meisten Dienstverwaltungsbefehlen können Sie jedoch das Suffix .service weglassen, da systemd intelligent genug ist, um zu wissen, dass Sie bei der Verwendung von Dienstverwaltungsbefehlen wahrscheinlich an einem Dienst arbeiten möchten
* Die Ausgaben von "systemctl" zeigt standardmäßig "less" an, die Navigation erfolgt mit den Pfeiltasten und der Leertaste, [q] wiederum beendet die Anzeige.
* Neben dem Namen der Unit verrät "systemctl" in der zweiten und dritten Spalte, ob es die Unit laden und aktivieren konnte.
* Die Spalte "SUB" gibt Auskunft über den derzeitigen Status: Bei einem Dateisystem erfährt man etwa, ob dieses gemountet ist, bei einem Dienst hingegen, ob dieser läuft ("running").
* In der letzten Spalte findet man schließlich noch eine kurze Beschreibung der Unit.
* Sofern ein Dienst beim Start nicht hochfahren wollte oder abgestürzt ist, markiert "systemctl" dies in seiner Ausgabe in hell leuchtendem Rot.
* Eine Liste mit allen nicht funktionierenden Units liefert "systemctl --failed", detaillierte Informationen über eine Unit zeigt ein Aufruf von "systemctl status" an
* In bestimmten Situationen erzeugt Systemd selbst eine Unit.
* Das passiert beispielsweise nach dem Anstöpseln eines neuen Gerätes.
* Die dann unter Umständen mithilfe von Udev generierten Units erscheinen zwar in der Ausgabe von "systemctl", es existieren aber keine passenden Unit-Dateien auf der Festplatte.
* Von diesen dynamisch generierten Units dürfen aber wiederum andere Units abhängen.


== Sicherheit ==
===Starten und beenden===
Um einen systemd-Dienst zu starten, indem Anweisungen in der Unit-Datei des Dienstes ausgeführt werden, verwenden Sie den Befehl start
* Wenn Sie als Nicht-root-Benutzer arbeiten, müssen Sie sudo verwenden, da dies den Status des Betriebssystems beeinflusst:
# ''' systemctl start application.service'''


== Dokumentation ==
Wie bereits erwähnt, weiß systemd, nach *.service-Dateien für die Dienstverwaltungsbefehle zu suchen, sodass der Befehl auch einfach wie folgt eingegeben werden könnte:
=== RFC ===
# ''' systemctl start application'''
=== Man-Pages ===
=== Info-Pages ===
=== 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)
# LSB 3.0.0 - http://refspecs.linuxbase.org/LSB_3.0.0/LSB-PDA/LSB-PDA/iniscrptact.html
# systemd 250, SYSTEMCTL(1)


== Links ==
Obwohl Sie das obige Format für die allgemeine Verwaltung verwenden können, verwenden wir aus Gründen der Übersichtlichkeit für die restlichen Befehle das Suffix .service, um das Ziel, an dem wir arbeiten, explizit zu kennzeichnen
=== Projekt-Homepage ===
=== Weblinks ===


Um einen derzeit laufenden Dienst zu stoppen, können Sie stattdessen den Befehl stop verwenden:
# ''' systemctl stop application.service'''


===Neustarten und Neuladen===
Um einen laufenden Dienst neu zu starten, können Sie den Befehl restart verwenden:
# ''' systemctl restart application.service'''


= Unit-Dateibefehle =
Wenn die betreffende Anwendung ihre Konfigurationsdateien neu laden kann (ohne Neustart), können Sie den Befehl reload erteilen, um diesen Prozess zu starten:
; list-unit-files [MUSTER…]
# ''' systemctl reload application.service'''
    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
Wenn Sie nicht sicher sind, ob der Dienst die Funktionalität zum Neuladen seiner Konfiguration hat, können Sie den Befehl reload-or-restart erteilen
    Units Vorlagenunits auflisten.
* Dadurch wird die vorhandene Konfiguration, sofern verfügbar, neu geladen
* Andernfalls startet der Befehl den Dienst, sodass die neue Konfiguration abgerufen wird:
# ''' systemctl reload-or-restart application.service'''


; enable UNIT…, enable PFAD…
===Aktivieren und Deaktivieren von Diensten===
    Gibt eine oder mehrere Units oder Unit-Instanzen frei. Dies wird eine Gruppe von
Die obigen Befehle sind für das Starten oder Anhalten von Diensten während der aktuellen Sitzung nützlich
    Symlinks erzeugen, wie dies in dem Abschnitt »[Install]« der angezeigten
* Um systemd anzuweisen, Dienste beim Booten automatisch zu starten, müssen Sie sie aktivieren
    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 foo@bar.service)
    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
Um einen Dienst beim Booten zu starten, verwenden Sie den Befehl enable:
    verschiedene Unit-Datei-Verzeichnisse automatisch nach Unit-Dateien mit geeigneten
# ''' systemctl enable application.service'''
    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.&nbsp;B.&nbsp; 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
Dadurch wird ein symbolischer Link von der Kopie der Dienst-Datei des Systems (normalerweise in /lib/systemd/system oder /etc/systemd/system) zu dem Speicherort auf Festplatte, wo systemd nach Autostart-Dateien sucht (normalerweise /etc/systemd/system/some_target.target.wants
    durch Übergabe von --quiet unterdrückt werden.
* Wir werden später in diesem Leitfaden darauf eingehen, was ein Ziel (target) ist)


    Beachten Sie, dass diese Aktion nur die in dem Abschnitt »[Install]« der
Um das automatische Starten des Dienstes zu deaktivieren, können Sie Folgendes eingeben:
    Unit-Dateien vorgeschlagenen Symlinks erstellt. Obwohl dieser Befehl die empfohlene
# ''' systemctl disable application.service'''
    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,
Dadurch wird der symbolische Link entfernt, der angab, dass der Dienst automatisch gestartet werden sollte
    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
Denken Sie daran, dass das Aktivieren eines Dienstes diesen nicht in der aktuellen Sitzung startet
    dies die Unit für das System, nur den aufrufenden Benutzer, nur für diesen
* Wenn Sie den Dienst starten und ihn auch beim Booten aktivieren möchten, müssen Sie sowohl den Befehl start als auch den Befehl enable erteilen
    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
=== Status ===
    einem Fehler.
Um den Status eines Dienstes auf Ihrem System zu überprüfen, können Sie den Befehl status verwenden:
# '''systemctl status application.service'''


; disable UNIT…
Dadurch erhalten Sie den Dienststatus, die cgroup-Hierarchie und die ersten paar Protokollzeilen
    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
Wenn Sie beispielsweise den Status eines Nginx-Servers überprüfen, sehen Sie möglicherweise eine Ausgabe wie diese:
    Unit-Dateien.


    Zusätzlich zu den als Argument angegebenen Unit-Dateien werden alle Units
● nginx.service - A high performance web server and a reverse proxy server
    ausgeschaltet, die in der in Abschnitt »[Install]« aufgeführten Einstellung Also= in
Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; vendor preset: disabled)
    jeder der Unit-Dateien, auf die agiert wird, enthalten sind.
Active: active (running) since Tue 2015-01-27 19:41:23 EST; 22h ago
Main PID: 495 (nginx)
CGroup: /system.slice/nginx.service
├─495 nginx: master process /usr/bin/nginx -g pid /run/nginx.pid; error_log stderr;
└─496 nginx: worker process
Jan 27 19:41:23 desktop systemd[1]: Starting A high performance web server and a reverse proxy server
Jan 27 19:41:23 desktop systemd[1]: Started A high performance web server and a reverse proxy server


    Dieser Befehl lädt implizit die Systemverwalterkonfiguration nach Abschluss der
Dadurch erhalten Sie einen schönen Überblick über den aktuellen Status der Anwendung und Sie werden über alle Probleme und eventuell erforderliche Maßnahmen informiert
    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
Es gibt auch Methoden zur Überprüfung bestimmter Zustände
    (Entfernung der Symlinks) ausgeben. Durch Übergabe von --quiet kann diese Ausgabe
* Um beispielsweise zu überprüfen, ob eine Einheit derzeit aktiv ist (läuft), können Sie den Befehl is-active verwenden:
    unterdrückt werden.
# '''systemctl is-active application.service'''


    Dieser Befehl berücksichtigt --system, --user, --runtime und --global auf eine
Dies gibt den aktuellen Zustand der Einheit zurück, der normalerweise active oder inactive ist
    ähnliche Art wie enable.
* Der Exit-Code ist „0“, wenn er aktiv ist, wodurch das Ergebnis in Shell-Skripten einfacher zu parsen ist


; reenable UNIT…
Um zu sehen, ob die Einheit aktiviert ist, können Sie den Befehl is-enabled verwenden:
    Gibt eine oder mehrere Units erneut frei, wie dies auf der Befehlszeile angegeben
# '''systemctl is-enabled application.service'''
    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…
Dies gibt aus, ob der Dienst enabled oder disabled ist und setzt den Exit-Code erneut auf „0“ oder „1“, abhängig von der Antwort auf die Befehlsfrage
    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
Eine dritte Überprüfung ist, ob sich die Einheit in einem fehlerhaften Zustand befindet
    oder nur freigegeben oder nur ausgeschaltet sein sollen.
* Dies deutet darauf hin, dass es ein Problem beim Starten der betreffenden Einheit gab:
# '''systemctl is-failed application.service'''


    Falls die Unit keine Installationsinformationen überträgt, wird sie durch diesen
Dies gibt bei ordnungsgemäßer Ausführung active zurück oder failed, wenn ein Fehler aufgetreten ist
    Befehl ohne Rückmeldung ignoriert. UNIT muss ein echter Unit-Name sein, jeder
* Wurde die Einheit absichtlich angehalten, kann unknown oder inactive zurückgegeben werden
    Aliasname wird ohne Rückmeldung ignoriert.
* Ein Rückgabewert von „0“ gibt an, dass ein Fehler aufgetreten ist, und ein Rückgabewert von „1“ zeigt jeden anderen Status an


    Weitere Informationen über das Format der Voreinstellungsrichtlinien finden Sie
=== Systemstatus ===
    unter systemd.preset(5).
Die bisherigen Befehle haben sich für die Verwaltung einzelner Dienste als nützlich erwiesen, doch sind sie nicht sehr hilfreich, um den aktuellen Zustand des Systems zu untersuchen
* Es gibt eine Reihe von systemctl-Befehlen, die diese Informationen bereitstellen


; preset-all
===Auflisten aktueller Einheiten===
    Setzt alle installierten Unit-Dateien auf die in der Voreinstellungsrichtliniendatei
Um eine Liste aller aktiven Einheiten zu sehen, von denen systemd Kenntnis hat, können wir den Befehl list-units verwenden:
    konfigurierten Vorgaben zurück (siehe oben).
# '''systemctl list-units'''


    Verwenden Sie --preset-mode=, um zu steuern, ob Units freigegeben und ausgeschaltet
Dies zeigt eine Liste aller Einheiten, die systemd derzeit im System aktiv hat
    oder nur freigegeben oder nur ausgeschaltet sein sollen.
* Die Ausgabe sieht in etwa folgendermaßen aus:
UNIT LOAD ACTIVE SUB DESCRIPTION
atd.service loaded active running ATD daemon
avahi-daemon.service loaded active running Avahi mDomain Name System/DNS-SD Stack
dbus.service loaded active running D-Bus System Message Bus
dcron.service loaded active running Periodic Command Scheduler
dkms.service loaded active exited Dynamic Kernel Modules System
getty@tty1.service loaded active running Getty on tty1
.  


; is-enabled UNIT…
; Ausgabespalten
    Prüft, ob eine der angegebenen Unit-Dateien eingeschaltet ist (wie mit enable).
{| class="wikitable sortable options"
    Liefert einen Exit-Code 0 zurück, falls mindestens eine freigegeben ist, andernfalls
|-
    eine von Null verschiedene Zahl. Gibt den derzeitigen Freigabestatus (siehe Tabelle)
! Option !! Beschreibung
    aus. Um diese Ausgabe zu unterdrücken, verwenden Sie --quiet. Um Installationsziele
|-
    anzuzeigen, verwenden Sie --full.
| UNIT || der systemd-Einheitenname
|-
| LOAD || ob die Konfiguration der Einheit durch systemd geparst wurdd. Die Konfiguration von geladenen Einheiten wird im Speicher gespeichert
|-
| ACTIVE || ein zusammenfassender Status darüber, ob die Einheit aktiv ist. Dies ist normalerweise eine recht einfache Möglichkeit, um festzustellen, ob die Einheit erfolgreich gestartet wurde oder nicht
|-
| SUB || Dies ist ein untergeordneter Status, der detailliertere Informationen über die Einheit anzeigt. Dies variiert oft nach Art der Einheit, Status und der tatsächlichen Methode, in der die Einheit ausgeführt wird
|-
| DESCRIPTION || Beschreibung, was die Einheit ist oder tut
|}


    Tabelle 1.  Ausgabe von is-enabled
Da der Befehl list-units standardmäßig nur aktive Einheiten anzeigt, zeigen alle obigen Einträge in der Spalte LOAD loaded und active in der Spalte ACTIVE
    ┌──────────────────┬───────────────────────────┬───────────┐
* Diese Anzeige ist tatsächlich das Standardverhalten von systemctl bei dem Aufruf ohne zusätzliche Befehle
    │Name              │ Beschreibung              │ Exit-Code │
Daher sehen Sie dasselbe, wenn Sie systemctl ohne Argumente aufrufen:
    ├──────────────────┼───────────────────────────┼───────────┤
  # '''systemctl'''
    │"enabled"        │ Über .wants/, .requires/  │          │
    ├──────────────────┤ oder Alias=-Symlinks      │          │
    │"enabled-runtime" │ freigegeben (dauerhaft    │ 0        │
    │                  │ in /etc/systemd/system/  │          │
    │                  │ oder flüchtig in          │          │
    │                  │ /run/systemd/system/).    │          │
    ├──────────────────┼───────────────────────────┼───────────┤
    │"linked"          │ Über einen oder mehrere  │          │
    ├──────────────────┤ Symlinks auf die          │          │
    │"linked-runtime"  │ Unit-Datei verfügbar      │          │
    │                  │ gemacht (dauerhaft in    │          │
    │                  │ /etc/systemd/system/      │          │
    │                  │ oder flüchtig in          │ > 0      │
    │                  │ /run/systemd/system/),    │          │
    │                  │ obwohl die Unit-Datei    │          │
    │                  │ selbst außerhalb des      │          │
    │                  │ Unit-Dateisuchpfades      │          │
    │                  │ liegen kann.              │          │
    ├──────────────────┼───────────────────────────┼───────────┤
    │"alias"          │ Der Name ist ein Alias    │ 0        │
    │                  │ (Symlink auf eine andere  │          │
    │                  │ Unit-Datei).              │          │
    ├──────────────────┼───────────────────────────┼───────────┤
    │"masked"          │ Komplett ausgeschaltet,  │          │
    ├──────────────────┤ so dass jede Startaktion  │          │
    │"masked-runtime"  │ darauf fehlschlägt        │          │
    │                  │ (dauerhaft in            │ > 0      │
    │                  │ /etc/systemd/system/      │          │
    │                  │ oder flüchtig in          │          │
    │                  │ /run/systemd/systemd/).  │          │
    ├──────────────────┼───────────────────────────┼───────────┤
    │"static"          │ Die Unit-Datei ist nicht  │ 0        │
    │                  │ freigegeben und hat      │          │
    │                  │ keine Vorkehrungen für    │          │
    │                  │ die Freigabe in dem      │          │
    │                  │ Unit-Dateiabschnitt      │          │
    │                  │ »[Install]«.              │          │
    ├──────────────────┼───────────────────────────┼───────────┤
    │"indirect"        │ Die Unit-Datei selbst    │ 0        │
    │                  │ 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.              │          │
    ├──────────────────┼───────────────────────────┼───────────┤
    │"disabled"        │ Die Unit-Datei ist nicht  │ > 0      │
    │                  │ freigegeben, enthält      │          │
    │                  │ aber einen Abschnitt      │          │
    │                  │ »[Install]« mit          │          │
    │                  │ Installationsanweisungen. │          │
    ├──────────────────┼───────────────────────────┼───────────┤
    │"generated"      │ Die Unit wurde dynamisch  │ 0        │
    │                  │ mit einem                │          │
    │                  │ Generatorwerkzeug        │          │
    │                  │ erstellt. Siehe          │          │
    │                  │ systemd.generator(7).    │          │
    │                  │ Erstellte Unit-Dateien    │          │
    │                  │ können nicht freigegeben  │          │
    │                  │ werden, sie werden        │          │
    │                  │ implizit durch ihren      │          │
    │                  │ Generator freigegeben.    │          │
    ├──────────────────┼───────────────────────────┼───────────┤
    │"transient"      │ Die Unit-Datei wurde      │ 0        │
    │                  │ dynamisch mit der        │          │
    │                  │ Laufzeit-API erstellt.    │          │
    │                  │ Flüchtige Units können    │          │
    │                  │ nicht freigegeben werden. │          │
    ├──────────────────┼───────────────────────────┼───────────┤
    │"bad"            │ Die Unit-Datei ist        │ > 0      │
    │                  │ 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.                │          │
    └──────────────────┴───────────────────────────┴───────────┘


; mask UNIT…
Durch Hinzufügen von zusätzlichen Flags können wir systemctl anweisen, andere Informationen auszugeben
    Blendet eine oder mehrere Units, wie auf der Befehlszeile angegeben, aus. Dies wird
* Um beispielsweise alle Einheiten zu sehen, die systemd geladen hat (oder versucht hat zu laden), unabhängig davon, ob sie derzeit aktiv sind, können Sie das Flag --all wie folgt verwenden:
    die Unit-Dateien nach /dev/null linken, wodurch sie nicht gestartet werden können.
# '''systemctl list-units --all'''
    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…
Dies zeigt jede Einheit an, die systemd geladen oder versucht hat zu laden, unabhängig von ihrem aktuellen Zustand im System
    Blendet eine oder mehrere Unit-Dateien, wie auf der Befehlszeile angegeben, ein.
* Einige Einheiten werden nach der Ausführung inaktiv und einige Einheiten, die systemd versucht hat zu laden, wurden möglicherweise nicht auf der Festplatte gefunden
    Dies macht die Wirkung von mask rückgängig. Dieser Befehl erwartet nur gültige
    Unit-Namen, er akzeptiert keine Unit-Dateipfade.


; link PFAD…
Sie können andere Flags verwenden, um diese Ergebnisse zu filtern
    Linkt eine Unit-Datei, die nicht im Unit-Dateisuchpfad ist, in den Dateisuchpfad.
* Beispielsweise können wir das Flag --state= verwenden, um die Zustände LOAD, ACTIVE oder SUB anzugeben, die wir sehen möchten
    Dieser Befehl erwartet einen absoluten Pfad zu einer Unit-Datei. Die Wirkung kann
* Sie müssen das Flag --all beibehalten, damit systemctl die Anzeige nicht aktiver Einheiten erlaubt:
    mit disable zurückgenommen werden. Die Wirkung des Befehls besteht darin, dass die
# '''systemctl list-units --all --state=inactive'''
    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…
Ein weiterer gebräuchlicher Filter ist der Filter --type=
    Bringt eine oder mehrere Unit-Dateien auf die Version des Lieferanten zurück. Dieser
* Wir können systemctl anweisen, nur Einheiten der Art anzuzeigen, an der wir interessiert sind
    Befehl entfernt Ergänzungskonfigurationsdateien, die die angegebene Unit verändern,
* Um beispielsweise nur aktive Diensteinheiten zu sehen, können wir verwenden:
    sowie alle benutzerkonfigurierten Unit-Dateien, die eine passende, vom Lieferanten
# '''systemctl list-units --type=service'''
    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
===Unit-Dateien auflisten===
    set-property und systemctl mask vorgenommenen Änderungen zurückzusetzen und alle
Der Befehl list-units zeigt nur Einheiten an, die systemd versucht hat zu parsen und in den Speicher zu laden
    ursprünglichen Unit-Dateien mit ihren Einstellungen wieder zur Wirkung zu bringen.
* Da systemd nur Einheiten liest, von denen es glaubt, dass sie benötigt werden, beinhaltet dies nicht unbedingt alle verfügbaren Einheiten im System
* Um alle verfügbaren Unit-Datei innerhalb der systemd-Pfade anzuzeigen, einschließlich derjenigen, die systemd nicht versucht hat zu laden, können Sie stattdessen den Befehl list-unit-files verwenden:
# '''systemctl list-unit-files'''


; add-wants ZIEL UNIT…, add-requires ZIELUNIT…
Units (Einheiten) sind Repräsentationen von Ressourcen, von denen systemd Kenntnis hat
    Fügt zu dem ZIEL für eine oder mehrere Units Abhängigkeiten »Wants=« bzw.
* Da systemd nicht unbedingt alle Unit-Definitionen in dieser Ansicht gelesen hat, zeigt es nur Informationen über die Dateien selbst an
    »Requires=« hinzu.
* Die Ausgabe hat zwei Spalten: die Unit-Datei und den Zustand


    Dieser Befehl berücksichtigt --system, --user, --runtime und --global auf eine
UNIT FILE STATE
    ähnliche Art wie enable.
proc-sys-fs-binfmt_misc.automount static
dev-hugepages.mount static
dev-mqueue.mount static
proc-fs-nfsd.mount static
proc-sys-fs-binfmt_misc.mount static
sys-fs-fuse-connections.mount static
sys-kernel-config.mount static
sys-kernel-debug.mount static
tmp.mount static
var-lib-nfs-rpc_pipefs.mount static
org.cups.cupsd.path enabled
.  


; edit UNIT…
Der Zustand ist in der Regel enabled (aktiviert), disabled (deaktiviert), static (statisch) oder masked (maskiert)
    Bearbeitet ein Ergänzungsschnippsel oder eine gesamte Ersetzungsdatei, falls --full
* In diesem Zusammenhang bedeutet statisch, dass die Unit-Datei keinen Abschnitt install enthält, der zur Aktivierung einer Einheit verwendet wird
    angegeben ist, oder erweitert die angegebene Unit oder setzt sie außer Kraft.
* Daher können diese Einheiten nicht aktiviert werden
* Normalerweise bedeutet dies, dass die Einheit eine einmalige Aktion ausführt oder nur als Abhängigkeit einer anderen Einheit verwendet wird und nicht allein ausgeführt werden sollte


    Abhängig davon, ob --system (die Vorgabe), --user, oder --global angegeben ist,
Die Bedeutung von masked werden wir in Kürze besprechen
    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
=== Einheiten verwalten ===
    Ergänzungsdateien zu erstellen.
Bisher haben wir mit Diensten gearbeitet und Informationen über die Einheit und die Unit-Dateien angezeigt, von denen systemd Kenntnis hat
* Mit einigen zusätzlichen Befehlen können wir jedoch spezifischere Informationen über Einheiten herausfinden


    Falls --force angegeben ist und eine der Units nicht existiert, werden neue
===Unit-Datei anzeigen===
    Unit-Dateien für die Bearbeitung geöffnet.
Um die Unit-Datei anzuzeigen, die systemd in sein System geladen hat, können Sie den Befehl cat verwenden (dieser wurde in systemd Version 209 hinzugefügt)
* Um beispielsweise die Unit-Datei des atd Scheduling-Daemons zu sehen, könnten wir Folgendes eingeben:


    Falls --runtime angegeben ist, wird die Änderung temporär in /run/ vorgenommen und
# '''systemctl cat atd.service'''
    geht beim nächsten Neustart verloren.


    Falls die temporäre Datei beim Beenden leer ist, wird die Änderung der zugehörigen
[Unit]
    Unit abgebrochen.
Description=ATD daemon
[Service]
Type=forking
ExecStart=/usr/bin/atd
[Install]
WantedBy=multi-user.target


    Nachdem die Units bearbeitet wurden, wird die Systemd-Konfiguration neu geladen (auf
Die Ausgabe ist die Unit-Datei, die dem aktuell laufenden systemd-Prozess bekannt ist
    eine Art, die äquivalent zu daemon-reload ist).
* Dies kann wichtig sein, wenn Sie kürzlich Unit-Dateien geändert haben oder wenn Sie bestimmte Optionen in einem Unit-Dateifragment überschreiben (wir werden dies später behandeln)


    Beachten Sie, dass dieser Befehl nicht zur Bearbeitung ferner Units verwandt werden
===Abhängigkeiten anzeigen===
    kann und dass Sie keine Units, die in /etc/ liegen, temporär bearbeiten können, da
Um den Abhängigkeitsbaum einer Einheit anzuzeigen, können Sie den Befehl list-dependencies verwenden:
    diese vor /run/ Vorrang haben.
# '''systemctl list-dependencies sshd.service'''


; get-default
Dadurch wird eine Hierarchie angezeigt, die die Abhängigkeiten abbildet, die behandelt werden müssen, um die betreffende Einheit zu starten
    Liefert das Standardziel, in welches der Systemstart erfolgt, zurück. Dies liefert
* Abhängigkeiten umfassen in diesem Zusammenhang diejenigen Einheiten, die entweder von darüber liegenden Einheiten benötigt oder gewünscht werden
    den Ziel-Unit-Namen, auf das der Alias (Symlink) von default.target zeigt.


; set-default ZIEL
sshd.service
    Setzt das Vorgabeziel, in das der Systemstart erfolgen soll. Dies setzt (als
├─system.slice
    Symlink) den default.target-Alias auf die angegebene Ziel-Unit.
└─basic.target
├─microcode.service
├─rhel-autorelabel-mark.service
├─rhel-autorelabel.service
├─rhel-configure.service
├─rhel-dmesg.service
├─rhel-loadmodules.service
├─paths.target
├─slices.target
.  


= Maschinenbefehle =
Die rekursiven Abhängigkeiten werden nur für .target-Einheiten angezeigt, wobei diese Systemzustände angeben
; list-machines [MUSTER…]
* Um alle Abhängigkeiten rekursiv aufzulisten, fügen Sie das Flag --all hinzu
    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 =
Um umgekehrte Abhängigkeiten (Einheiten, die von der angegebenen Einheit abhängen) anzuzeigen, können Sie dem Befehl das Flag --reverse hinzufügen
; list-jobs [MUSTER…]
* Andere nützliche Flags sind die Flags --before und --after, die zur Anzeige von Einheiten verwendet werden können, die von der angegebenen Einheit abhängen und vor bzw
    Listet laufende Aufträge auf. Falls eines oder mehrere MUSTER angegeben sind, werden
* nach sich selbst beginnen
    nur Aufträge von Units, die auf die Muster passen, angezeigt.


    Wird dies mit --after oder --before kombiniert, wird die Liste mit Informationen
===Überprüfen der Einheit-Eigenschaften===
    darüber angereichert, auf welchen anderen Auftrag jeder Auftrag wartet und welche
Um die untergeordneten Eigenschaften einer Einheit zu sehen, können Sie den Befehl show verwenden
    anderen Aufträge auf ihn warten, siehe oben.
* Dadurch wird eine Liste der Eigenschaften angezeigt, die für die angegebene Einheit mit dem Format key=value festgelegt werden:


; cancel AUFTRAG…
# '''systemctl show sshd.service'''
    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 =
Id=sshd.service
  systemd unterstützt einen Umgebungsblock, der an vom Systemverwalter erzeugte Prozesse
Names=sshd.service
  übergeben wird. Die Namen der Variablen können ASCII-Buchstaben, Ziffern und das
  Requires=basic.target
  Unterstrichzeichen enthalten. Variablennamen dürfen nicht leer sein oder mit einer
  Wants=system.slice
  Ziffer starten. In den Variablenwerten sind die meisten Zeichen erlaubt, aber die
  WantedBy=multi-user.target
  gesamte Sequenz muss gültiges UTF-8 sein. (Beachten Sie, dass Steuerzeichen wie der
  Conflicts=shutdown.target
  Zeilenumbruch (NL), der Tabulator (TAB) oder das Maskierzeichen (ESC) gültiges ASCII und
  Before=shutdown.target multi-user.target
  damit gültiges UTF-8 sind). Die Gesamtlänge des Umgebungsblocks ist auf den Wert
  After=syslog.target network.target auditd.service systemd-journald.socket basic.target system.slice
  _SC_ARG_MAX, der in sysconf(3) definiert ist, begrenzt.
  Description=OpenSSH server daemon
  .  


; show-environment
Wenn Sie eine einzelne Eigenschaft anzeigen möchten, können Sie das Flag -p mit dem Eigenschaftsnamen übergeben
    Zeigt den Umgebungsblock des Systemd-Verwalters an. Dies ist der Umgebungsblock, der
* Um beispielsweise die Konflikte zu sehen, die die Einheit sshd.service hat, können Sie Folgendes eingeben:
    an alle vom Verwalter erzeugten Prozesse übergeben wird. Der Umgebungsblock wird in
# '''systemctl show sshd.service -p Conflicts'''
    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…
Conflicts=shutdown.target
    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…
===Maskieren und Demaskieren von Einheiten ===
    Setzt eine oder mehrere Umgebungsvariablen des Systemd-Verwalters zurück. Falls nur
Wir haben im Abschnitt Verwaltung von Diensten gesehen, wie ein Dienst angehalten oder deaktiviert werden kann, aber systemd weist auch die Möglichkeit auf, eine Einheit durch Verknüpfung mit /dev/null automatisch oder manuell als vollständig nicht startbar zu markieren
    ein Variablenname angegeben ist, wird er unabhängig von seinem Wert entfernt. Falls
* Dies wird als Maskieren der Einheit bezeichnet und ist mit dem Befehl mask möglich:
    eine Variable und ein Wert angegeben werden, wird die Variable nur entfernt, falls
# ''' systemctl mask nginx.service'''
    sie den angegebenen Wert hat.


; import-environment VARIABLE…
Dadurch wird verhindert, dass der Nginx-Dienst automatisch oder manuell gestartet wird, solange er maskiert ist
    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
Wenn Sie die list-unit-files überprüfen, sehen Sie, dass der Dienst nun als maskiert aufgelistet ist:
    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 =
# '''systemctl list-unit-files'''
; daemon-reload
    Lä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.
kmod-static-nodes.service static
ldconfig.service static
mandb.service static
messagebus.service static
nginx.service masked
quotaon.service static
rc-local.service static
rdisc.service disabled
rescue.service static


; daemon-reexec
Wenn Sie versuchen, den Dienst zu starten, sehen Sie eine Nachricht wie diese:
    Führt den Systemd-Verwalter neu aus. Dies wird den Verwalterzustand serialisieren,
# ''' systemctl start nginx.service'''
    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]
Failed to start nginx.service: Unit nginx.service is masked
    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]
Um eine Einheit zu demaskieren und wieder für die Verwendung verfügbar zu machen, verwenden Sie den Befehl unmask:
    Zeigt das aktuelle Protokollierziel des Verwalters an, falls kein Argument angegeben
# ''' systemctl unmask nginx.service'''
    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]
Dadurch wird die Einheit in ihren vorherigen Zustand zurückversetzt, sodass sie gestartet oder aktiviert werden kann
    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.&nbsp;B.&nbsp;
    OnFailure= oder StartLimitAction=) aktiviert oder deaktiviert; siehe
    systemd.service(5). Der Hardware-Watchdog ist von dieser Einstellung nicht
    betroffen.


= Systembefehle =
=== Bearbeiten von Unit-Dateien ===
; is-system-running
Während das spezifische Format für Unit-Dateien außerhalb des Rahmens dieses Tutorials liegt, bietet systemctl integrierte Mechanismen für die Bearbeitung und Änderung von Unit-Dateien, falls Sie Anpassungen vornehmen müssen
    Prüft, ob das System einsatzfähig ist. Dies liefert Erfolg (Exit-Code 0) zurück,
* Diese Funktionalität wurde in systemd Version 218 hinzugefügt
    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
Der Befehl edit öffnet standardmäßig eine Unit-Datei für die betreffende Einheit
    ist, bevor der aktuelle Zustand angezeigt und der angemessene Fehlerstatus
# ''' systemctl edit nginx.service'''
    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
Dabei handelt es sich um eine leere Datei, die zum Überschreiben oder Hinzufügen von Anweisungen zu Unit-Definition verwendet werden kann
    ┌─────────────┬──────────────────────────┬───────────┐
* Innerhalb des Verzeichnisses /etc/systemd/system wird ein Verzeichnis erstellt, das den Namen der Einheit mit angehängtem .d enthält
    │Name        │ Beschreibung            │ Exit-Code │
* Für den nginx.service wird beispielsweise ein Verzeichnis namens nginx.service.d erstellt
    ├─────────────┼──────────────────────────┼───────────┤
    │initializing │ Früher Systemstart, vor  │ > 0      │
    │            │ basic.target erreicht    │          │
    │            │ oder der Wartungs-       │          │
    │            │ Zustand betreten wurde.  │          │
    ├─────────────┼──────────────────────────┼───────────┤
    │starting    │ Späte Startphase, bevor  │ > 0      │
    │            │ die                      │          │
    │            │ Auftragswarteschlange    │          │
    │            │ erstmalig in den         │          │
    │            │ Leerlauf geht oder eines │          │
    │            │ der Rettungsziele        │          │
    │            │ erreicht wird.           │          │
    ├─────────────┼──────────────────────────┼───────────┤
    │running      │ Das System ist komplett  │ 0        │
    │            │ betriebsbereit.         │          │
    ├─────────────┼──────────────────────────┼───────────┤
    │degraded    │ Das System ist          │ > 0      │
    │            │ betriebsbereit, aber    │          │
    │            │ eine oder mehrere Units  │          │
    │            │ sind fehlgeschlagen.    │          │
    ├─────────────┼──────────────────────────┼───────────┤
    │maintenance  │ Das Rettungs- oder      │ > 0      │
    │            │ Notfallziel ist aktiv.  │          │
    ├─────────────┼──────────────────────────┼───────────┤
    │stopping    │ Der Verwalter fährt sich │ > 0      │
    │            │ herunter.                │          │
    ├─────────────┼──────────────────────────┼───────────┤
    │offline      │ Der Verwalter läuft      │ > 0      │
    │            │ nicht. Insbesondere ist  │          │
    │            │ dies der                │          │
    │            │ Betriebszustand, falls  │          │
    │            │ ein inkompatibles        │          │
    │            │ Programm als            │          │
    │            │ Systemverwalter (PID 1)  │          │
    │            │ läuft.                   │          │
    ├─────────────┼──────────────────────────┼───────────┤
    │unknown      │ Der Betriebszustand      │ > 0      │
    │            │ konnte aufgrund von      │          │
    │            │ fehlenden Ressourcen    │          │
    │            │ oder einer anderen      │          │
    │            │ Fehlerursache nicht      │          │
    │            │ bestimmt werden.         │          │
    └─────────────┴──────────────────────────┴───────────┘


; default
Innerhalb dieses Verzeichnisses wird ein Snippet namens override.conf erstellt
    Betritt den Standardmodus. Dies ist zu systemctl isolate default.target äquivalent.
* Wenn die Einheit geladen ist, führt systemd das Überschreiben-Snippet im Speicher mit der vollständigen Unit-Datei zusammen
    Diese Aktion blockiert standardmäßig, verwenden Sie --no-block für asynchrones
* Die Anweisungen des Snippets haben Vorrang vor denen, die in der ursprünglichen Unit-Datei zu finden sind
    Verhalten.


; rescue
Wenn Sie die vollständige Unit-Datei bearbeiten möchten, anstatt einen Snippet zu erstellen, können Sie das Flag --full übergeben:
    Betritt den Rettungsmodus. Dies ist zu systemctl isolate rescue.target äquivalent.
# ''' systemctl edit --full nginx.service'''
    Diese Aktion blockiert standardmäßig, verwenden Sie --no-block für asynchrones
    Verhalten.


; emergency
Dadurch wird die aktuelle Unit-Datei in den Editor geladen, wo sie geändert werden kann
    Betritt den Notfallmodus. Dies ist zu systemctl isolate emergency.target äquivalent.
* Wird der Editor verlassen, wird die geänderte Datei in /etc/systemd/system geschrieben, wobei diese Datei Vorrang vor der Unit-Definition des Systems hat (normalerweise irgendwo in /lib/systemd/system zu finden)
    Diese Aktion blockiert standardmäßig, verwenden Sie --no-block für asynchrones
    Verhalten.


; halt
Um alle von Ihnen vorgenommenen Ergänzungen zu entfernen, löschen Sie entweder das Konfigurationsverzeichnis .d der Einheit oder die geänderte Dienst-Datei aus /etc/systemd/system
    Fährt das System herunter und hält es an. Dies ist größtenteils äquivalent zu
* Um beispielsweise ein Snippet zu entfernen, können wir Folgendes eingeben:
    systemctl start halt.target --job-mode=replace-irreversibly --no-block, gibt aber
# ''' rm -r /etc/systemd/system/nginx.service.d'''
    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
Um eine vollständige geänderte Unit-Datei zu entfernen, geben wir Folgendes ein:
    übersprungen, alle Prozesse werden aber getötet und alle Dateisysteme ausgehängt
# ''' rm /etc/systemd/system/nginx.service'''
    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
Nach dem Löschen der Datei oder des Verzeichnisses sollten Sie den Prozess systemd neu laden, sodass er nicht mehr versucht, auf diese Dateien zu verweisen und wieder die Systemkopie verwendet
    Fährt das System herunter und schaltet es aus. Dies ist größtenteils zu systemctl
* Geben Sie dazu Folgendes ein:
    start poweroff.target --job-mode=replace-irreversibly --no-block äquivalent, gibt
# ''' systemctl daemon-reload'''
    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
=== Anpassen des Systemzustands (Runlevel) mit Zielen ===
    übersprungen, alle Prozesse werden aber getötet und alle Dateisysteme ausgehängt
Ziele sind spezielle Unit-Dateien, die einen Systemzustand oder Synchronisationspunkt beschreiben
    oder nur lesbar eingehängt, sofort danach erfolgt das Ausschalten des Systems. Falls
* Wie andere Einheiten können die Dateien, die Ziele definieren, durch ihr Suffix identifiziert werden, was in diesem Fall .target ist
    --force zweimal angegeben ist, wird die Aktion sofort ausgeführt, ohne irgendeinen
* Ziele machen selbst nicht viel, sondern werden stattdessen verwendet, um andere Einheiten zusammenzufassen
    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
Dies kann verwendet werden, um das System in bestimmte Zustände zu bringen, ähnlich wie andere Init-Systeme Runlevel verwenden
    Fährt das System herunter und startet es neu. Dies ist größtenteils zu systemctl
* Sie werden als Referenz verwendet, wenn bestimmte Funktionen verfügbar sind, sodass Sie anstelle der einzelnen Einheiten, die zur Erzeugung dieses Zustands benötigt werden, den gewünschten Zustand angeben können
    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
Beispielsweise gibt es ein swap.target, das verwendet, um anzugeben, dass Swap einsatzbereit ist
    übersprungen, alle Prozesse werden aber getötet und alle Dateisysteme ausgehängt
* Einheiten, die Teil dieses Prozesses sind, können mit diesem Ziel synchronisieren, indem sie in ihrer Konfiguration angeben, dass sie WantedBy= oder RequiredBy= vom swap.target sind
    oder nur lesbar eingehängt, sofort danach erfolgt der Neustart des Systems. Falls
* Einheiten, für die Swap verfügbar sein muss, können diese Bedingung mit den Spezifikationen Wants=, Requires= und After= angeben, um die Art ihrer Beziehung anzugeben
    --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
===Abrufen und Einrichten des Standardziels ===
    an den Systemaufruf reboot(2) übergeben.
Der Prozess systemd hat ein Standardziel, das er beim Booten des Systems verwendet
* Die Befriedigung der Kaskade von Abhängigkeiten von diesem einzelnen Ziel bringt das System in den gewünschten Zustand
* Um das Standardziel für Ihr System zu finden, geben Sie Folgendes ein:


; kexec
# '''systemctl get-default'''
    Fährt das System herunter und startet mit kexec neu. Dies ist zu systemctl start
multi-user.target
    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
Wenn Sie ein anderes Standardziel festlegen möchten, können Sie set-default verwenden
    übersprungen, alle Prozesse werden aber getötet und alle Dateisysteme ausgehängt
* Wenn Sie beispielsweise eine grafische Arbeitsoberfläche installiert haben und möchten, dass das System standardmäßig in diese bootet, können Sie Ihr Standardziel entsprechend ändern:
    oder nur lesbar eingehängt, sofort danach erfolgt der Neustart des Systems.
# ''' systemctl set-default graphical.target'''


; exit [EXIT-CODE]
===Auflisten verfügbarer Ziele===
    Bittet den Diensteverwalter, sich zu beenden. Dies wird nur für
Sie können eine Liste der auf Ihrem System verfügbaren Ziele erhalten, indem Sie Folgendes eingeben:
    Benutzerdiensteverwalter (d.h. im Zusammenspiel mit der Option --user) oder in
# '''systemctl list-unit-files --type=target'''
    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
Im Gegensatz zu Runleveln können mehrere Ziele gleichzeitig aktiv sein
    Exit-Code beenden.
* Ein aktives Ziel gibt an, dass systemd versucht hat, alle an das Ziel gebundene Einheiten zu starten und nicht versucht hat, sie wieder zu entfernen
* Um alle aktiven Ziele zu sehen, geben Sie Folgendes ein:
# '''systemctl list-units --type=target'''


; switch-root WURZEL [INIT]
===Isolieren von Zielen===
    Schaltet auf ein anderes Wurzelverzeichnis und führt darunter einen neuen
Es ist möglich, alle mit einem Ziel verknüpften Einheiten zu starten und alle Einheiten zu stoppen, die nicht Teil des Abhängigkeitsbaums sind
    Systemverwalter aus. Dies ist für den Einsatz in anfänglichen RAM-Platten (»initrd«)
* Der Befehl, den wir dazu benötigen, heißt entsprechend isolate
    gedacht und wird vom Systemverwalter der Initrd (d.h. dem »Init«-Prozess) auf dem
* Dies ist ähnlich wie das Ändern der Runlevel in anderen Init-Systemen
    Hauptsystemverwalterprozess wechseln, der vom tatsächlichen Datenträger 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
Wenn Sie beispielsweise in einer grafischen Umgebung mit aktivem graphical.target arbeiten, können Sie das grafische System herunterfahren und das System in einen Multibenutzer-Befehlszeilenzustand versetzen, indem Sie multi-user.target isolieren
    Suspendiert das System. Dies wird die Aktivierung der besonderen Ziel-Unit
* Da graphical.target von multi-user.target abhängt, aber nicht umgekehrt, werden alle grafischen Einheiten angehalten
    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
Sie sollten sich vor der Durchführung dieses Vorgangs die Abhängigkeiten des zu isolierenden Ziels ansehen, um sicherzustellen, dass Sie keine wichtigen Dienste anhalten
    Bringt das System in den Ruhezustand. Dies wird die Aktivierung der besonderen
# '''systemctl list-dependencies multi-user.target'''
    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
Wenn Sie mit den Einheiten, die weiterhin aktiv bleiben sollen, zufrieden sind, können Sie das Ziel isolieren, indem Sie Folgendes eingeben:
    Bringt das System in den Ruhezustand und suspendiert es. Dies wird die Aktivierung
# ''' systemctl isolate multi-user.target'''
    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
===Verwenden von Shortcuts für wichtige Ereignisse===
    Suspendiert das System nach einer in systemd-sleep.conf angegebenen Verzögerung und
Es gibt Ziele, die für wichtige Ereignisse wie Ausschalten oder Neustart definiert sind
    bringt es in den Ruhezustand. Dies wird die Aktivierung der besonderen Ziel-Unit
* Allerdings verfügt systemctl auch über einige Shortcuts, die einige zusätzliche Funktionalität hinzufügen
    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 =
Um beispielsweise das System in den (Einzelbenutzer) Rettungsmodus zu versetzen, können Sie einfach den Befehl rescue verwenden, anstatt isolate rescue.target
Die oben aufgeführten Unit-Befehle akzeptieren entweder einen einzelnen Unit-Namen (als
  # ''' systemctl rescue'''
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
Dies bietet die zusätzliche Funktionalität, alle angemeldeten Benutzer über das Ereignis zu alarmieren


  und
Um das System anzuhalten, können Sie den Befehl halt verwenden:
  # ''' systemctl halt'''


    # systemctl start sshd.service
Um eine vollständiges Herunterfahren einzuleiten, können Sie den Befehl poweroff verwenden:
# ''' systemctl poweroff'''


  äquivalent, wie auch
Ein Neustart kann mit dem Befehl reboot gestartet werden:
  # ''' systemctl reboot'''


    # systemctl isolate default
Diese alarmieren angemeldete Benutzer, dass das Ereignis auftritt, was nur durch Ausführen oder Isolieren des Ziels nicht möglich ist
* Zu beachten ist, dass die meisten Rechner die kürzeren, konventionelleren Befehle für diese Operationen verknüpfen, damit sie ordnungsgemäß mit systemd arbeiten


  und
Um beispielsweise das System neu zu starten, können Sie normalerweise eingeben:
  # ''' reboot'''


    # systemctl isolate default.target
https://www.digitalocean.com/community/tutorials/how-to-use-systemctl-to-manage-systemd-services-and-units-de


Beachten Sie, dass der (absolute) Pfad zu den Geräteknoten automatisch in einen
; Anwendungen
Geräte-Unit-Namen und andere (absolute) Pfade zu Einhänge-Unit-Namen umgewandelt werden.
* Änderungen als root
** Alle vorgestellten Informationen darf jeder Nutzer abfragen
* Um Änderungen an der Konfiguration vorzunehmen, müssen Sie "systemctl" jedoch mit Root-Rechten starten
* Dann lassen sich einzelne Units über »<tt>systemctl start</tt>« aktivieren beziehungsweise mit »<tt>systemctl stop</tt>« anhalten


    # systemctl status /dev/sda
Der folgende Befehl fährt den SSH-Daemon hoch:
    # systemctl status /home
# '''systemctl start sshd.service'''


ist äquivalent zu:
* Auf Systemen mit SysV-Init würde dies dem Aufruf des Skripts "/etc/init.d/sshd start" entsprechen
* Vergessen Sie im Unit-Namen den Typ, geht Systemd von ".service" aus
* Den SSH-Daemon könnten Sie folglich einfach mit »<tt>systemctl start sshd</tt>« anwerfen. "systemctl" wechselt natürlich auch Targets


    # systemctl status dev-sda.device
Der folgende Befehl aktiviert beispielsweise das Target "rescue.target", was wiederum zu einem Rettungssystem führt:
    # systemctl status home.mount
# '''systemctl isolate rescue.target'''


Im zweiten Fall werden Shell-artige Globs mit den primären Namen aller derzeit im
* Die Angabe "isolate" sorgt dafür, dass ausschließlich die von "rescue.target" vorgegebenen Units aktiv sind, alle anderen Dienste und Units beendet Systemd
Speicher befindlichen Units abgeglichen; wörtliche Unit-Namen, mit oder ohne eine
Endung, werden wie im ersten Fall behandelt. Das bedeutet, dass sich wörtliche
Unit-Namen immer auf genau eine Unit beziehen, aber Globs auf null Units passen können,
was nicht als Fehler betrachtet wird.


Glob-Muster verwenden fnmatch(3), daher werden normale Shell-artige Glob-Regeln verwandt
Um zu verhindern, dass ein Dienst beim Systemstart automatisch hochfährt, deaktivieren Sie ihn:
und »*«, »?« und »[]« dürfen verwendet werden. Siehe glob(7) für weitere Details. Die
  # '''systemctl disable sshd.service'''
  Muster werden mit den primären Namen der derzeit im Speicher befindlichen Units
verglichen und Muster, die auf nichts passen, werden ohne Rückmeldung übersprungen.
Beispielsweise wird


    # systemctl stop sshd@*.service
In diesem Beispiel würde Systemd den SSH-Daemon aus sämtlichen Targets nehmen. Mit "enable" knipsen Sie ihn wieder an:
# '''systemctl enable sshd.service'''
Damit gehört der SSH-Daemon wieder zu allen Targets, die in seiner Unit-Datei (aus dem Listing "sshd.service") hinter "WantedBy" vermerkt sind
* Im Hintergrund setzt Systemd dabei übrigens lediglich die symbolischen Links in den ".wants"-Unterverzeichnissen


  alle sshd@.service-Instanzen stoppen. Beachten Sie, dass Aliasnamen von Units und Units,
  <nowiki>[[Image:Bild1.png|top]]</nowiki>
die sich nicht im Speicher befinden, für die Glob-Erweiterung nicht berücksichtigt
* Bild 2: In den Status-Informationen liefert "systemctl" unter anderem auch die PID (hier die 1270) und die Laufzeit des Dienstes (hier über eine Stunde)
werden.


Für Unit-Dateibefehle sollte die angegebene UNIT der Name der Unit-Datei (möglicherweise
== Aufruf ==
  abgekürzt, siehe oben) oder der absolute Pfad zu der Unit-Datei sein:
  '''systemctl [OPTIONEN…] BEFEHL [UNIT…]'''


    # systemctl enable foo.service
=== Optionen ===
=== Parameter ===
=== Umgebung ===
=== Rückgabewert ===


oder
== Konfiguration ==
=== Dateien ===
<noinclude>


    # systemctl link /path/to/foo.service
== Anhang ==
=== Siehe auch ===
{{Special:PrefixIndex/{{BASEPAGENAME}}}}
----
* [[cgroups]]
* [[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)
* LSB 3.0.0 - http://refspecs.linuxbase.org/LSB_3.0.0/LSB-PDA/LSB-PDA/iniscrptact.html
* systemd 250, SYSTEMCTL(1)


== OPTIONEN ==
==== Dokumentation ====
Die folgenden Optionen werden verstanden:
===== Man-Page =====
 
-t, --type=
    Dieses Argument sollte eine Kommata-getrennte Liste von Unit-Typen wie service und
    socket sein.
 
    Begrenzt die Anzeige auf bestimmte Unit-Typen, wenn Units aufgelistet werden, falls
    eines der Argumente ein Unit-Typ ist. Andernfalls werden alle 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 sollte eine Kommata-getrennte Liste von Zuständen LOAD, SUB oder ACTIVE
    sein. Zeigt nur die Units in den angegebenen Zuständen an, wenn diese aufgelistet
    werden. Verwenden Sie --state=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 mit Unterdrückungssperren umgegangen werden soll, 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 vermeiden, dass bestimmte
    wichtige Aktionen (wie das Brennen von CDs oder ähnlichem) durch das Herunterfahren
    des Systems oder Schlafzustände 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) und eine
    Liste der aktiven Sperren wird ausgegeben. Falls allerdings »no« oder »auto« bei
    nicht interaktiven Anfragen angegeben wurde, werden die etablierten Sperren
    ignoriert und nicht angezeigt und die Aktion wird dennoch versucht, wobei
    möglicherweise zusätzliche Privilegien benötigt werden. Kann durch --force außer
    Kraft gesetzt werden.
 
-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-who=
    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.
 
--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=
    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=
    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)
        "Tag YYYY-MM-DD HH:MM:SS TZ"
 
    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"
 
--mkdir
    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 Marks
    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=lennart@.host«. 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[1]
definiert sind.
 
Tabelle 3. LSB-Rückgabe-Codes
┌─────┬────────────────────────┬───────────────────────┐
│Wert │ Beschreibung in LSB    │ Verwendung in Systemd │
├─────┼────────────────────────┼───────────────────────┤
│0    │ "Programm läuft oder  │ Unit ist aktiv        │
│    │ Dienst ist OK"        │                      │
├─────┼────────────────────────┼───────────────────────┤
│1    │ "Programm ist tot und  │ Unit ist nicht        │
│    │ /var/run-PID-Datei    │ fehlgeschlagen (von  │
│    │ existiert"            │ is-failed verwandt)  │
├─────┼────────────────────────┼───────────────────────┤
│2    │ "Programm ist tot und  │ nicht verwandt        │
│    │ /var/lock-Sperrdatei  │                      │
│    │ existiert"            │                      │
├─────┼────────────────────────┼───────────────────────┤
│3    │ "Programm läuft nicht" │ Unit ist nicht aktiv  │
├─────┼────────────────────────┼───────────────────────┤
│4    │ "Programm- oder        │ keine solche Unit    │
│    │ Dienstezustand        │                      │
│    │ unbekannt"            │                      │
└─────┴────────────────────────┴───────────────────────┘
 
Die Abbildung der LSB-Dienstezustände auf Systemd-Unit-Zustände ist nicht perfekt. Daher
ist es besser, sich nicht auf diese Rückgabewerte zu verlassen, sondern stattdessen nach
bestimmten Unit-Zuständen und Unterzuständen zu schauen.
 
== UMGEBUNGSVARIABLEN ==
$SYSTEMD_EDITOR
    Der 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.
 
$SYSTEMD_LESS
    Setzt die an less übergebenen Optionen (standardmäßig »FRSXMK«) außer Kraft.
 
    Benutzer könnten insbesondere zwei Optionen ändern wollen:
 
    K
        Diese Option weist das Textanzeigeprogramm an, sich sofort beim Druck von Strg-C
        zu beenden. Um less die Handhabung von Strg-C selbst zum Umschalten auf die
        Eingabeaufforderung zu erlauben, setzen Sie diese Option zurück.
 
        Falls der Wert von $SYSTEMD_LESS kein »K« enthält und less das aufgerufene
        Textanzeigeprogramm ist, wird Strg+C durch das Programm ignoriert und muss durch
        das Textanzeigeprogramm selbst gehandhabt werden.
 
    X
        Diese Option weist das Textanzeigeprogramm an, keine Termcap-Initialisierungs-
        und -Deinitalisierungszeichenketten an das Terminal zu senden. Dies ist
        standardmäßig gesetzt, damit die Darstellung von Befehlen selbst nach dem
        Beenden des Textanzeigeprogramms sichtbar bleibt. Allerdings stehen dadurch
        einige Funktionen des Textanzeigeprogramms nicht zur Verfügung; insbesondere ist
        das Scrollen in der Ausgabe mit der Maus nicht möglich.
 
    Siehe less(1) für weitere Ausführungen.
 
$SYSTEMD_LESSCHARSET
    Setzt den an less zu übergebenden Zeichensatz (standardmäßig »utf-8«, falls das
    aufrufende Terminal als UTF-8-kompatibel erkannt wurde) außer Kraft.
 
$SYSTEMD_PAGERSECURE
    Akzeptiert einen logischen Wert. Wenn wahr, wird der »sichere« Modus des
    Seitenanzeigeprogramms verwandt, falls falsch, wird dieser deaktiviert. Falls
    $SYSTEMD_PAGERSECURE überhaupt nicht gesetzt ist, dann wird der sichere Modus
    aktiviert, falls die effektive Kennung nicht identisch zu dem Eigentümer der
    Anmeldesitzung ist, siehe geteuid(2) und sd_pid_get_owner_uid(3). Im sicheren Modus
    wird LESSSECURE=1 beim Aufruf des Seitenanzeigeprogramms gesetzt und das
    Seitenanzeigeprogramm muss Befehle deaktivieren, die neue Dateien öffnen oder
    erstellen oder die einen neuen Unterprozess starten. Falls $SYSTEMD_PAGERSECURE
    überhaupt nicht gesetzt ist, werden Seitenanzeigeprogramme, bei denen unbekannt ist,
    ob sie einen sicheren Modus implementieren, nicht verwandt. (Derzeit implementiert
    nur less(1) einen sicheren Modus.)
 
    Hinweis: Wenn Befehle mit erhöhten Rechten ausgeführt werden, beispielsweise mittels
    sudo(8) oder pkexec(1), muss Vorsicht walten gelassen werden, um sicherzustellen,
    dass keine ungeplanten interaktiven Funktionalitäten aktiviert werden. Der »sichere«
    Modus für das Seitenanzeigeprogramm kann wie oben beschrieben automatisch aktiviert
    werden. Durch Setzen von SYSTEMD_PAGERSECURE=0 oder durch Nichtenfernen dieser
    Einstellung aus der ererbten Umgebung wird es dem Benutzer ermöglicht, beliebige
    Befehle auszuführen. Beachten Sie, dass auch $SYSTEMD_PAGERSECURE gesetzt werden
    muss, falls die Variablen $SYSTEMD_PAGER oder $PAGER berücksichtigt werden sollen.
    Es kann sinnvoll sein, stattdessen den Seitenanzeiger komplett mit --no-pager zu
    deaktivieren.
 
$SYSTEMD_COLORS
    Akzeptiert ein logisches Argument. Wenn wahr, werden systemd und verwandte
    Hilfswerkzeuge Farben in ihrer Ausgabe verwenden, andernfalls wird die Ausgabe
    einfarbig sein. Zusätzlich kann die Variable eine der folgenden besonderen Werte
    annehmen: »16«, »256«, um die Verwendung von Farbe auf die grundlegenden 16 bzw. 256
    ANSI-Farben zu beschränken. Dies kann festgelegt werden, um die auf $TERM und der
    vorliegenden Verbindung der Konsole basierende automatische Entscheidung außer Kraft
    zu setzen.
 
$SYSTEMD_URLIFY
    Dies muss ein logischer Wert sein. Er steuert, ob anklickbare Links für
    Terminal-Emulatoren, die dies unterstützen, erstellt werden sollen. Dies kann
    angegeben werden, um die Entscheidung, die systemd basierend auf $TERM und anderen
    Bedingungen trifft, außer Kraft zu setzen.
 
== SIEHE AUCH ==
  systemd(1), journalctl(1), loginctl(1), machinectl(1), systemd.unit(5),
  systemd(1), journalctl(1), loginctl(1), machinectl(1), systemd.unit(5),
  systemd.resource-control(5), systemd.special(7), wall(1), systemd.preset(5),
  systemd.resource-control(5), systemd.special(7), wall(1), systemd.preset(5),
  systemd.generator(7), glob(7)
  systemd.generator(7), glob(7)


== ANMERKUNGEN ==
===== Info-Pages =====
  1. LSB 3.0.0
==== Links ====
    http://refspecs.linuxbase.org/LSB_3.0.0/LSB-PDA/LSB-PDA/iniscrptact.html
===== Projekt =====
===== Weblinks =====


== ÜBERSETZUNG ==
{{DISPLAYTITLE:systemctl}}
Die deutsche Übersetzung dieser Handbuchseite wurde von Helge Kreutzmann
<debian@helgefjell.de> erstellt.
 
Diese Übersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License
Version 3 ⟨https://www.gnu.org/licenses/gpl-3.0.html⟩ oder neuer bezüglich der Copy‐
right-Bedingungen. Es wird KEINE HAFTUNG übernommen.
 
Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken Sie bitte eine
E-Mail an die Mailingliste der Übersetzer ⟨debian-l10n-german@lists.debian.org⟩.
 
systemd 250, SYSTEMCTL(1)


[[Kategorie:Linux/Befehl]]
[[Kategorie:Systemd]]
[[Kategorie:Systemd]]
[[Kategorie:Linux/Befehl]]
{{DEFAULTSORT:systemctl}}
<div id="BackToTop"  class="noprint" style="background-color:#DDEFDD; position:fixed;
bottom:32px; left:2%; z-index:9999; padding:0; margin:0;"><span style="color:blue;
font-size:8pt; font-face:verdana,sans-serif;  border:0.2em outset #ceebf7;
padding:0.1em; font-weight:bolder; -moz-border-radius:8px; ">
[[#top| Back to the Top ]]</span></div>
<button class="noprint" onclick="topFunction()" id="myBtn" title="Go to top">Top</button>


</noinclude>
</noinclude>

Aktuelle Version vom 12. November 2024, 19:40 Uhr

systemctl - Steuerung des Systemd-Systems und des Diensteverwalters

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

Wer nur an bestimmten Units interessiert ist, kann die Anzeige über den Parameter "--type=" einschränken

  • Alle Dienste präsentiert etwa "systemctl --type=service"
  • Die Ausgaben von "systemctl" zeigt standardmäßig "less" an, die Navigation erfolgt mit den Pfeiltasten und der Leertaste, [q] wiederum beendet die Anzeige
  • Neben dem Namen der Unit verrät "systemctl" in der zweiten und dritten Spalte, ob es die Unit laden und aktivieren konnte
  • Die Spalte "SUB" gibt Auskunft über den derzeitigen Status: Bei einem Dateisystem erfährt man etwa, ob dieses gemountet ist, bei einem Dienst hingegen, ob dieser läuft ("running")
  • In der letzten Spalte findet man schließlich noch eine kurze Beschreibung der Unit
  • Sofern ein Dienst beim Start nicht hochfahren wollte oder abgestürzt ist, markiert "systemctl" dies in seiner Ausgabe in hell leuchtendem Rot
  • Eine Liste mit allen nicht funktionierenden Units liefert "systemctl --failed", detaillierte Informationen über eine Unit zeigt ein Aufruf von "systemctl status" an
  • In bestimmten Situationen erzeugt Systemd selbst eine Unit
  • Das passiert beispielsweise nach dem Anstöpseln eines neuen Gerätes
  • Die dann unter Umständen mithilfe von Udev generierten Units erscheinen zwar in der Ausgabe von "systemctl", es existieren aber keine passenden Unit-Dateien auf der Festplatte
  • Von diesen dynamisch generierten Units dürfen aber wiederum andere Units abhängen

Installation

Anwendung

Useful systemd commands on Linux

Dienste verwalten

Der grundlegende Zweck eines Init-Systems ist die Initialisierung der Komponenten, die nach dem Booten des Linux-Kernels gestartet werden müssen (traditionell als „userland“-Komponenten bekannt)

  • Das Init-System wird auch dazu verwendet, Dienste und Daemons für den Server zu jedem Zeitpunkt während des Systembetriebs zu verwalten
  • Vor diesem Hintergrund beginnen wir mit einigen grundlegenden Operationen zur Verwaltung von Diensten

In systemd sind die meisten Aktionen auf „Einheiten“ (sog

  • Units) ausgerichtet, wobei es sich um Ressourcen handelt, die systemd verwalten kann
  • Einheiten werden nach der Art der Ressource, die sie repräsentieren, kategorisiert und mit Dateien definiert, die als Unit-Dateien bekannt sind
  • Die Art jeder Einheit kann aus dem Suffix am Ende der Datei abgeleitet werden

Für Dienstverwaltungsaufgaben ist die Zieleinheit die Diensteinheiten, die Unit-Dateien mit dem Suffix .service aufweisen

  • Bei den meisten Dienstverwaltungsbefehlen können Sie jedoch das Suffix .service weglassen, da systemd intelligent genug ist, um zu wissen, dass Sie bei der Verwendung von Dienstverwaltungsbefehlen wahrscheinlich an einem Dienst arbeiten möchten

Starten und beenden

Um einen systemd-Dienst zu starten, indem Anweisungen in der Unit-Datei des Dienstes ausgeführt werden, verwenden Sie den Befehl start

  • Wenn Sie als Nicht-root-Benutzer arbeiten, müssen Sie sudo verwenden, da dies den Status des Betriebssystems beeinflusst:
#  systemctl start application.service

Wie bereits erwähnt, weiß systemd, nach *.service-Dateien für die Dienstverwaltungsbefehle zu suchen, sodass der Befehl auch einfach wie folgt eingegeben werden könnte: 

#  systemctl start application

Obwohl Sie das obige Format für die allgemeine Verwaltung verwenden können, verwenden wir aus Gründen der Übersichtlichkeit für die restlichen Befehle das Suffix .service, um das Ziel, an dem wir arbeiten, explizit zu kennzeichnen

Um einen derzeit laufenden Dienst zu stoppen, können Sie stattdessen den Befehl stop verwenden: 

#  systemctl stop application.service

Neustarten und Neuladen

Um einen laufenden Dienst neu zu starten, können Sie den Befehl restart verwenden: 

#  systemctl restart application.service

Wenn die betreffende Anwendung ihre Konfigurationsdateien neu laden kann (ohne Neustart), können Sie den Befehl reload erteilen, um diesen Prozess zu starten: 

#  systemctl reload application.service

Wenn Sie nicht sicher sind, ob der Dienst die Funktionalität zum Neuladen seiner Konfiguration hat, können Sie den Befehl reload-or-restart erteilen

  • Dadurch wird die vorhandene Konfiguration, sofern verfügbar, neu geladen
  • Andernfalls startet der Befehl den Dienst, sodass die neue Konfiguration abgerufen wird:
#  systemctl reload-or-restart application.service

Aktivieren und Deaktivieren von Diensten

Die obigen Befehle sind für das Starten oder Anhalten von Diensten während der aktuellen Sitzung nützlich

  • Um systemd anzuweisen, Dienste beim Booten automatisch zu starten, müssen Sie sie aktivieren

Um einen Dienst beim Booten zu starten, verwenden Sie den Befehl enable: 

#  systemctl enable application.service

Dadurch wird ein symbolischer Link von der Kopie der Dienst-Datei des Systems (normalerweise in /lib/systemd/system oder /etc/systemd/system) zu dem Speicherort auf Festplatte, wo systemd nach Autostart-Dateien sucht (normalerweise /etc/systemd/system/some_target.target.wants

  • Wir werden später in diesem Leitfaden darauf eingehen, was ein Ziel (target) ist)

Um das automatische Starten des Dienstes zu deaktivieren, können Sie Folgendes eingeben: 

#  systemctl disable application.service

Dadurch wird der symbolische Link entfernt, der angab, dass der Dienst automatisch gestartet werden sollte

Denken Sie daran, dass das Aktivieren eines Dienstes diesen nicht in der aktuellen Sitzung startet

  • Wenn Sie den Dienst starten und ihn auch beim Booten aktivieren möchten, müssen Sie sowohl den Befehl start als auch den Befehl enable erteilen

Status

Um den Status eines Dienstes auf Ihrem System zu überprüfen, können Sie den Befehl status verwenden: 

# systemctl status application.service

Dadurch erhalten Sie den Dienststatus, die cgroup-Hierarchie und die ersten paar Protokollzeilen

Wenn Sie beispielsweise den Status eines Nginx-Servers überprüfen, sehen Sie möglicherweise eine Ausgabe wie diese: 

● nginx.service - A high performance web server and a reverse proxy server
Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; vendor preset: disabled)
Active: active (running) since Tue 2015-01-27 19:41:23 EST; 22h ago
Main PID: 495 (nginx)
CGroup: /system.slice/nginx.service
├─495 nginx: master process /usr/bin/nginx -g pid /run/nginx.pid; error_log stderr;
└─496 nginx: worker process
Jan 27 19:41:23 desktop systemd[1]: Starting A high performance web server and a reverse proxy server
Jan 27 19:41:23 desktop systemd[1]: Started A high performance web server and a reverse proxy server

Dadurch erhalten Sie einen schönen Überblick über den aktuellen Status der Anwendung und Sie werden über alle Probleme und eventuell erforderliche Maßnahmen informiert

Es gibt auch Methoden zur Überprüfung bestimmter Zustände

  • Um beispielsweise zu überprüfen, ob eine Einheit derzeit aktiv ist (läuft), können Sie den Befehl is-active verwenden:
# systemctl is-active application.service

Dies gibt den aktuellen Zustand der Einheit zurück, der normalerweise active oder inactive ist

  • Der Exit-Code ist „0“, wenn er aktiv ist, wodurch das Ergebnis in Shell-Skripten einfacher zu parsen ist

Um zu sehen, ob die Einheit aktiviert ist, können Sie den Befehl is-enabled verwenden: 

# systemctl is-enabled application.service

Dies gibt aus, ob der Dienst enabled oder disabled ist und setzt den Exit-Code erneut auf „0“ oder „1“, abhängig von der Antwort auf die Befehlsfrage

Eine dritte Überprüfung ist, ob sich die Einheit in einem fehlerhaften Zustand befindet

  • Dies deutet darauf hin, dass es ein Problem beim Starten der betreffenden Einheit gab:
# systemctl is-failed application.service

Dies gibt bei ordnungsgemäßer Ausführung active zurück oder failed, wenn ein Fehler aufgetreten ist

  • Wurde die Einheit absichtlich angehalten, kann unknown oder inactive zurückgegeben werden
  • Ein Rückgabewert von „0“ gibt an, dass ein Fehler aufgetreten ist, und ein Rückgabewert von „1“ zeigt jeden anderen Status an

Systemstatus

Die bisherigen Befehle haben sich für die Verwaltung einzelner Dienste als nützlich erwiesen, doch sind sie nicht sehr hilfreich, um den aktuellen Zustand des Systems zu untersuchen

  • Es gibt eine Reihe von systemctl-Befehlen, die diese Informationen bereitstellen

Auflisten aktueller Einheiten

Um eine Liste aller aktiven Einheiten zu sehen, von denen systemd Kenntnis hat, können wir den Befehl list-units verwenden: 

# systemctl list-units

Dies zeigt eine Liste aller Einheiten, die systemd derzeit im System aktiv hat

  • Die Ausgabe sieht in etwa folgendermaßen aus:
UNIT LOAD ACTIVE SUB DESCRIPTION
atd.service loaded active running ATD daemon
avahi-daemon.service loaded active running Avahi mDomain Name System/DNS-SD Stack
dbus.service loaded active running D-Bus System Message Bus
dcron.service loaded active running Periodic Command Scheduler
dkms.service loaded active exited Dynamic Kernel Modules System
getty@tty1.service loaded active running Getty on tty1
.
Ausgabespalten
Option Beschreibung
UNIT der systemd-Einheitenname
LOAD ob die Konfiguration der Einheit durch systemd geparst wurdd. Die Konfiguration von geladenen Einheiten wird im Speicher gespeichert
ACTIVE ein zusammenfassender Status darüber, ob die Einheit aktiv ist. Dies ist normalerweise eine recht einfache Möglichkeit, um festzustellen, ob die Einheit erfolgreich gestartet wurde oder nicht
SUB Dies ist ein untergeordneter Status, der detailliertere Informationen über die Einheit anzeigt. Dies variiert oft nach Art der Einheit, Status und der tatsächlichen Methode, in der die Einheit ausgeführt wird
DESCRIPTION Beschreibung, was die Einheit ist oder tut

Da der Befehl list-units standardmäßig nur aktive Einheiten anzeigt, zeigen alle obigen Einträge in der Spalte LOAD loaded und active in der Spalte ACTIVE

  • Diese Anzeige ist tatsächlich das Standardverhalten von systemctl bei dem Aufruf ohne zusätzliche Befehle

Daher sehen Sie dasselbe, wenn Sie systemctl ohne Argumente aufrufen: 

# systemctl

Durch Hinzufügen von zusätzlichen Flags können wir systemctl anweisen, andere Informationen auszugeben

  • Um beispielsweise alle Einheiten zu sehen, die systemd geladen hat (oder versucht hat zu laden), unabhängig davon, ob sie derzeit aktiv sind, können Sie das Flag --all wie folgt verwenden:
# systemctl list-units --all

Dies zeigt jede Einheit an, die systemd geladen oder versucht hat zu laden, unabhängig von ihrem aktuellen Zustand im System

  • Einige Einheiten werden nach der Ausführung inaktiv und einige Einheiten, die systemd versucht hat zu laden, wurden möglicherweise nicht auf der Festplatte gefunden

Sie können andere Flags verwenden, um diese Ergebnisse zu filtern

  • Beispielsweise können wir das Flag --state= verwenden, um die Zustände LOAD, ACTIVE oder SUB anzugeben, die wir sehen möchten
  • Sie müssen das Flag --all beibehalten, damit systemctl die Anzeige nicht aktiver Einheiten erlaubt:
# systemctl list-units --all --state=inactive

Ein weiterer gebräuchlicher Filter ist der Filter --type=

  • Wir können systemctl anweisen, nur Einheiten der Art anzuzeigen, an der wir interessiert sind
  • Um beispielsweise nur aktive Diensteinheiten zu sehen, können wir verwenden:
# systemctl list-units --type=service

Unit-Dateien auflisten

Der Befehl list-units zeigt nur Einheiten an, die systemd versucht hat zu parsen und in den Speicher zu laden

  • Da systemd nur Einheiten liest, von denen es glaubt, dass sie benötigt werden, beinhaltet dies nicht unbedingt alle verfügbaren Einheiten im System
  • Um alle verfügbaren Unit-Datei innerhalb der systemd-Pfade anzuzeigen, einschließlich derjenigen, die systemd nicht versucht hat zu laden, können Sie stattdessen den Befehl list-unit-files verwenden:
# systemctl list-unit-files

Units (Einheiten) sind Repräsentationen von Ressourcen, von denen systemd Kenntnis hat

  • Da systemd nicht unbedingt alle Unit-Definitionen in dieser Ansicht gelesen hat, zeigt es nur Informationen über die Dateien selbst an
  • Die Ausgabe hat zwei Spalten: die Unit-Datei und den Zustand
UNIT FILE STATE
proc-sys-fs-binfmt_misc.automount static
dev-hugepages.mount static
dev-mqueue.mount static
proc-fs-nfsd.mount static
proc-sys-fs-binfmt_misc.mount static
sys-fs-fuse-connections.mount static
sys-kernel-config.mount static
sys-kernel-debug.mount static
tmp.mount static
var-lib-nfs-rpc_pipefs.mount static
org.cups.cupsd.path enabled
.

Der Zustand ist in der Regel enabled (aktiviert), disabled (deaktiviert), static (statisch) oder masked (maskiert)

  • In diesem Zusammenhang bedeutet statisch, dass die Unit-Datei keinen Abschnitt install enthält, der zur Aktivierung einer Einheit verwendet wird
  • Daher können diese Einheiten nicht aktiviert werden
  • Normalerweise bedeutet dies, dass die Einheit eine einmalige Aktion ausführt oder nur als Abhängigkeit einer anderen Einheit verwendet wird und nicht allein ausgeführt werden sollte

Die Bedeutung von masked werden wir in Kürze besprechen

Einheiten verwalten

Bisher haben wir mit Diensten gearbeitet und Informationen über die Einheit und die Unit-Dateien angezeigt, von denen systemd Kenntnis hat

  • Mit einigen zusätzlichen Befehlen können wir jedoch spezifischere Informationen über Einheiten herausfinden

Unit-Datei anzeigen

Um die Unit-Datei anzuzeigen, die systemd in sein System geladen hat, können Sie den Befehl cat verwenden (dieser wurde in systemd Version 209 hinzugefügt)

  • Um beispielsweise die Unit-Datei des atd Scheduling-Daemons zu sehen, könnten wir Folgendes eingeben:
# systemctl cat atd.service

[Unit]
Description=ATD daemon
[Service]
Type=forking
ExecStart=/usr/bin/atd
[Install]
WantedBy=multi-user.target

Die Ausgabe ist die Unit-Datei, die dem aktuell laufenden systemd-Prozess bekannt ist

  • Dies kann wichtig sein, wenn Sie kürzlich Unit-Dateien geändert haben oder wenn Sie bestimmte Optionen in einem Unit-Dateifragment überschreiben (wir werden dies später behandeln)

Abhängigkeiten anzeigen

Um den Abhängigkeitsbaum einer Einheit anzuzeigen, können Sie den Befehl list-dependencies verwenden: 

# systemctl list-dependencies sshd.service

Dadurch wird eine Hierarchie angezeigt, die die Abhängigkeiten abbildet, die behandelt werden müssen, um die betreffende Einheit zu starten

  • Abhängigkeiten umfassen in diesem Zusammenhang diejenigen Einheiten, die entweder von darüber liegenden Einheiten benötigt oder gewünscht werden
sshd.service
├─system.slice
└─basic.target
├─microcode.service
├─rhel-autorelabel-mark.service
├─rhel-autorelabel.service
├─rhel-configure.service
├─rhel-dmesg.service
├─rhel-loadmodules.service
├─paths.target
├─slices.target
.

Die rekursiven Abhängigkeiten werden nur für .target-Einheiten angezeigt, wobei diese Systemzustände angeben

  • Um alle Abhängigkeiten rekursiv aufzulisten, fügen Sie das Flag --all hinzu

Um umgekehrte Abhängigkeiten (Einheiten, die von der angegebenen Einheit abhängen) anzuzeigen, können Sie dem Befehl das Flag --reverse hinzufügen

  • Andere nützliche Flags sind die Flags --before und --after, die zur Anzeige von Einheiten verwendet werden können, die von der angegebenen Einheit abhängen und vor bzw
  • nach sich selbst beginnen

Überprüfen der Einheit-Eigenschaften

Um die untergeordneten Eigenschaften einer Einheit zu sehen, können Sie den Befehl show verwenden

  • Dadurch wird eine Liste der Eigenschaften angezeigt, die für die angegebene Einheit mit dem Format key=value festgelegt werden:
# systemctl show sshd.service

Id=sshd.service
Names=sshd.service
Requires=basic.target
Wants=system.slice
WantedBy=multi-user.target
Conflicts=shutdown.target
Before=shutdown.target multi-user.target
After=syslog.target network.target auditd.service systemd-journald.socket basic.target system.slice
Description=OpenSSH server daemon
.

Wenn Sie eine einzelne Eigenschaft anzeigen möchten, können Sie das Flag -p mit dem Eigenschaftsnamen übergeben

  • Um beispielsweise die Konflikte zu sehen, die die Einheit sshd.service hat, können Sie Folgendes eingeben:
# systemctl show sshd.service -p Conflicts

Conflicts=shutdown.target

Maskieren und Demaskieren von Einheiten

Wir haben im Abschnitt Verwaltung von Diensten gesehen, wie ein Dienst angehalten oder deaktiviert werden kann, aber systemd weist auch die Möglichkeit auf, eine Einheit durch Verknüpfung mit /dev/null automatisch oder manuell als vollständig nicht startbar zu markieren

  • Dies wird als Maskieren der Einheit bezeichnet und ist mit dem Befehl mask möglich:
#  systemctl mask nginx.service

Dadurch wird verhindert, dass der Nginx-Dienst automatisch oder manuell gestartet wird, solange er maskiert ist

Wenn Sie die list-unit-files überprüfen, sehen Sie, dass der Dienst nun als maskiert aufgelistet ist: 

# systemctl list-unit-files

kmod-static-nodes.service static
ldconfig.service static
mandb.service static
messagebus.service static
nginx.service masked
quotaon.service static
rc-local.service static
rdisc.service disabled
rescue.service static

Wenn Sie versuchen, den Dienst zu starten, sehen Sie eine Nachricht wie diese: 

#  systemctl start nginx.service

Failed to start nginx.service: Unit nginx.service is masked

Um eine Einheit zu demaskieren und wieder für die Verwendung verfügbar zu machen, verwenden Sie den Befehl unmask: 

#  systemctl unmask nginx.service

Dadurch wird die Einheit in ihren vorherigen Zustand zurückversetzt, sodass sie gestartet oder aktiviert werden kann

Bearbeiten von Unit-Dateien

Während das spezifische Format für Unit-Dateien außerhalb des Rahmens dieses Tutorials liegt, bietet systemctl integrierte Mechanismen für die Bearbeitung und Änderung von Unit-Dateien, falls Sie Anpassungen vornehmen müssen

  • Diese Funktionalität wurde in systemd Version 218 hinzugefügt

Der Befehl edit öffnet standardmäßig eine Unit-Datei für die betreffende Einheit 

#  systemctl edit nginx.service

Dabei handelt es sich um eine leere Datei, die zum Überschreiben oder Hinzufügen von Anweisungen zu Unit-Definition verwendet werden kann

  • Innerhalb des Verzeichnisses /etc/systemd/system wird ein Verzeichnis erstellt, das den Namen der Einheit mit angehängtem .d enthält
  • Für den nginx.service wird beispielsweise ein Verzeichnis namens nginx.service.d erstellt

Innerhalb dieses Verzeichnisses wird ein Snippet namens override.conf erstellt

  • Wenn die Einheit geladen ist, führt systemd das Überschreiben-Snippet im Speicher mit der vollständigen Unit-Datei zusammen
  • Die Anweisungen des Snippets haben Vorrang vor denen, die in der ursprünglichen Unit-Datei zu finden sind

Wenn Sie die vollständige Unit-Datei bearbeiten möchten, anstatt einen Snippet zu erstellen, können Sie das Flag --full übergeben: 

#  systemctl edit --full nginx.service

Dadurch wird die aktuelle Unit-Datei in den Editor geladen, wo sie geändert werden kann

  • Wird der Editor verlassen, wird die geänderte Datei in /etc/systemd/system geschrieben, wobei diese Datei Vorrang vor der Unit-Definition des Systems hat (normalerweise irgendwo in /lib/systemd/system zu finden)

Um alle von Ihnen vorgenommenen Ergänzungen zu entfernen, löschen Sie entweder das Konfigurationsverzeichnis .d der Einheit oder die geänderte Dienst-Datei aus /etc/systemd/system

  • Um beispielsweise ein Snippet zu entfernen, können wir Folgendes eingeben:
#  rm -r /etc/systemd/system/nginx.service.d

Um eine vollständige geänderte Unit-Datei zu entfernen, geben wir Folgendes ein: 

#  rm /etc/systemd/system/nginx.service

Nach dem Löschen der Datei oder des Verzeichnisses sollten Sie den Prozess systemd neu laden, sodass er nicht mehr versucht, auf diese Dateien zu verweisen und wieder die Systemkopie verwendet

  • Geben Sie dazu Folgendes ein:
#  systemctl daemon-reload

Anpassen des Systemzustands (Runlevel) mit Zielen

Ziele sind spezielle Unit-Dateien, die einen Systemzustand oder Synchronisationspunkt beschreiben

  • Wie andere Einheiten können die Dateien, die Ziele definieren, durch ihr Suffix identifiziert werden, was in diesem Fall .target ist
  • Ziele machen selbst nicht viel, sondern werden stattdessen verwendet, um andere Einheiten zusammenzufassen

Dies kann verwendet werden, um das System in bestimmte Zustände zu bringen, ähnlich wie andere Init-Systeme Runlevel verwenden

  • Sie werden als Referenz verwendet, wenn bestimmte Funktionen verfügbar sind, sodass Sie anstelle der einzelnen Einheiten, die zur Erzeugung dieses Zustands benötigt werden, den gewünschten Zustand angeben können

Beispielsweise gibt es ein swap.target, das verwendet, um anzugeben, dass Swap einsatzbereit ist

  • Einheiten, die Teil dieses Prozesses sind, können mit diesem Ziel synchronisieren, indem sie in ihrer Konfiguration angeben, dass sie WantedBy= oder RequiredBy= vom swap.target sind
  • Einheiten, für die Swap verfügbar sein muss, können diese Bedingung mit den Spezifikationen Wants=, Requires= und After= angeben, um die Art ihrer Beziehung anzugeben

Abrufen und Einrichten des Standardziels

Der Prozess systemd hat ein Standardziel, das er beim Booten des Systems verwendet

  • Die Befriedigung der Kaskade von Abhängigkeiten von diesem einzelnen Ziel bringt das System in den gewünschten Zustand
  • Um das Standardziel für Ihr System zu finden, geben Sie Folgendes ein:
# systemctl get-default
multi-user.target

Wenn Sie ein anderes Standardziel festlegen möchten, können Sie set-default verwenden

  • Wenn Sie beispielsweise eine grafische Arbeitsoberfläche installiert haben und möchten, dass das System standardmäßig in diese bootet, können Sie Ihr Standardziel entsprechend ändern:
#  systemctl set-default graphical.target

Auflisten verfügbarer Ziele

Sie können eine Liste der auf Ihrem System verfügbaren Ziele erhalten, indem Sie Folgendes eingeben: 

# systemctl list-unit-files --type=target

Im Gegensatz zu Runleveln können mehrere Ziele gleichzeitig aktiv sein

  • Ein aktives Ziel gibt an, dass systemd versucht hat, alle an das Ziel gebundene Einheiten zu starten und nicht versucht hat, sie wieder zu entfernen
  • Um alle aktiven Ziele zu sehen, geben Sie Folgendes ein:
# systemctl list-units --type=target

Isolieren von Zielen

Es ist möglich, alle mit einem Ziel verknüpften Einheiten zu starten und alle Einheiten zu stoppen, die nicht Teil des Abhängigkeitsbaums sind

  • Der Befehl, den wir dazu benötigen, heißt entsprechend isolate
  • Dies ist ähnlich wie das Ändern der Runlevel in anderen Init-Systemen

Wenn Sie beispielsweise in einer grafischen Umgebung mit aktivem graphical.target arbeiten, können Sie das grafische System herunterfahren und das System in einen Multibenutzer-Befehlszeilenzustand versetzen, indem Sie multi-user.target isolieren

  • Da graphical.target von multi-user.target abhängt, aber nicht umgekehrt, werden alle grafischen Einheiten angehalten

Sie sollten sich vor der Durchführung dieses Vorgangs die Abhängigkeiten des zu isolierenden Ziels ansehen, um sicherzustellen, dass Sie keine wichtigen Dienste anhalten 

# systemctl list-dependencies multi-user.target

Wenn Sie mit den Einheiten, die weiterhin aktiv bleiben sollen, zufrieden sind, können Sie das Ziel isolieren, indem Sie Folgendes eingeben: 

#  systemctl isolate multi-user.target

Verwenden von Shortcuts für wichtige Ereignisse

Es gibt Ziele, die für wichtige Ereignisse wie Ausschalten oder Neustart definiert sind

  • Allerdings verfügt systemctl auch über einige Shortcuts, die einige zusätzliche Funktionalität hinzufügen

Um beispielsweise das System in den (Einzelbenutzer) Rettungsmodus zu versetzen, können Sie einfach den Befehl rescue verwenden, anstatt isolate rescue.target 

#  systemctl rescue

Dies bietet die zusätzliche Funktionalität, alle angemeldeten Benutzer über das Ereignis zu alarmieren

Um das System anzuhalten, können Sie den Befehl halt verwenden: 

#  systemctl halt

Um eine vollständiges Herunterfahren einzuleiten, können Sie den Befehl poweroff verwenden: 

#  systemctl poweroff

Ein Neustart kann mit dem Befehl reboot gestartet werden: 

#  systemctl reboot

Diese alarmieren angemeldete Benutzer, dass das Ereignis auftritt, was nur durch Ausführen oder Isolieren des Ziels nicht möglich ist

  • Zu beachten ist, dass die meisten Rechner die kürzeren, konventionelleren Befehle für diese Operationen verknüpfen, damit sie ordnungsgemäß mit systemd arbeiten

Um beispielsweise das System neu zu starten, können Sie normalerweise eingeben: 

#  reboot

https://www.digitalocean.com/community/tutorials/how-to-use-systemctl-to-manage-systemd-services-and-units-de

Anwendungen
  • Änderungen als root
    • Alle vorgestellten Informationen darf jeder Nutzer abfragen
  • Um Änderungen an der Konfiguration vorzunehmen, müssen Sie "systemctl" jedoch mit Root-Rechten starten
  • Dann lassen sich einzelne Units über »systemctl start« aktivieren beziehungsweise mit »systemctl stop« anhalten

Der folgende Befehl fährt den SSH-Daemon hoch: 

# systemctl start sshd.service
  • Auf Systemen mit SysV-Init würde dies dem Aufruf des Skripts "/etc/init.d/sshd start" entsprechen
  • Vergessen Sie im Unit-Namen den Typ, geht Systemd von ".service" aus
  • Den SSH-Daemon könnten Sie folglich einfach mit »systemctl start sshd« anwerfen. "systemctl" wechselt natürlich auch Targets

Der folgende Befehl aktiviert beispielsweise das Target "rescue.target", was wiederum zu einem Rettungssystem führt: 

# systemctl isolate rescue.target
  • Die Angabe "isolate" sorgt dafür, dass ausschließlich die von "rescue.target" vorgegebenen Units aktiv sind, alle anderen Dienste und Units beendet Systemd

Um zu verhindern, dass ein Dienst beim Systemstart automatisch hochfährt, deaktivieren Sie ihn: 

# systemctl disable sshd.service

In diesem Beispiel würde Systemd den SSH-Daemon aus sämtlichen Targets nehmen. Mit "enable" knipsen Sie ihn wieder an: 

# systemctl enable sshd.service

Damit gehört der SSH-Daemon wieder zu allen Targets, die in seiner Unit-Datei (aus dem Listing "sshd.service") hinter "WantedBy" vermerkt sind

  • Im Hintergrund setzt Systemd dabei übrigens lediglich die symbolischen Links in den ".wants"-Unterverzeichnissen
[[Image:Bild1.png|top]]
  • Bild 2: In den Status-Informationen liefert "systemctl" unter anderem auch die PID (hier die 1270) und die Laufzeit des Dienstes (hier über eine Stunde)

Aufruf

systemctl [OPTIONEN…] BEFEHL [UNIT…]

Optionen

Parameter

Umgebung

Rückgabewert

Konfiguration

Dateien

Anhang

Siehe auch

Dokumentation

Man-Page
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)
Info-Pages

Links

Projekt
Weblinks


Abgerufen von „https://wiki.foxtom.de/index.php?title=Systemctl&oldid=115332“