Systemctl: Unterschied zwischen den Versionen
K Textersetzung - „== Syntax ==“ durch „== Aufruf ==“ |
|||
| (17 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) | |||
| Zeile 2: | Zeile 2: | ||
== Beschreibung == | == Beschreibung == | ||
'''systemctl''' kann zum Prüfen und Steuern des Zustandes des »Systemd«-Systems und -Diensteverwalters verwandt werden | '''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 | * 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" | * 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 | * 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 | * 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") | * 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 | * 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 | * 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 | * 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 | * In bestimmten Situationen erzeugt Systemd selbst eine Unit | ||
* Das passiert beispielsweise nach dem Anstöpseln eines neuen Gerätes | * 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 | * 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 | * Von diesen dynamisch generierten Units dürfen aber wiederum andere Units abhängen | ||
== Installation == | == Installation == | ||
== Anwendung == | == Anwendung == | ||
[[File:systemdCommands.jpg|mini|400px|[https://www.instagram.com/p/C6lgUh8AULu/ Useful systemd commands on Linux]]] | |||
=== Dienste verwalten === | === 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) | 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 | * 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 | * Vor diesem Hintergrund beginnen wir mit einigen grundlegenden Operationen zur Verwaltung von Diensten | ||
In systemd sind die meisten Aktionen auf „Einheiten“ (sog | In systemd sind die meisten Aktionen auf „Einheiten“ (sog | ||
* Units) ausgerichtet, wobei es sich um Ressourcen handelt, die systemd verwalten kann | * 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 | * 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 | * 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 | 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 | * 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=== | ===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 | 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: | * Wenn Sie als Nicht-root-Benutzer arbeiten, müssen Sie sudo verwenden, da dies den Status des Betriebssystems beeinflusst: | ||
# ''' systemctl start application.service''' | # ''' systemctl start application.service''' | ||
| Zeile 49: | Zeile 42: | ||
# ''' systemctl start application''' | # ''' 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 | 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: | Um einen derzeit laufenden Dienst zu stoppen, können Sie stattdessen den Befehl stop verwenden: | ||
| Zeile 61: | Zeile 54: | ||
# ''' systemctl reload application.service''' | # ''' 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 | 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 | * Dadurch wird die vorhandene Konfiguration, sofern verfügbar, neu geladen | ||
* Andernfalls startet der Befehl den Dienst, sodass die neue Konfiguration abgerufen wird: | * Andernfalls startet der Befehl den Dienst, sodass die neue Konfiguration abgerufen wird: | ||
# ''' systemctl reload-or-restart application.service''' | # ''' systemctl reload-or-restart application.service''' | ||
===Aktivieren und Deaktivieren von Diensten=== | ===Aktivieren und Deaktivieren von Diensten=== | ||
Die obigen Befehle sind für das Starten oder Anhalten von Diensten während der aktuellen Sitzung nützlich | 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 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: | Um einen Dienst beim Booten zu starten, verwenden Sie den Befehl enable: | ||
# ''' systemctl enable application.service''' | # ''' 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 | 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) | * 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: | Um das automatische Starten des Dienstes zu deaktivieren, können Sie Folgendes eingeben: | ||
# ''' systemctl disable application.service''' | # ''' systemctl disable application.service''' | ||
Dadurch wird der symbolische Link entfernt, der angab, dass der Dienst automatisch gestartet werden sollte | 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 | 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 | * 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 === | === Status === | ||
| Zeile 88: | Zeile 81: | ||
# '''systemctl status application.service''' | # '''systemctl status application.service''' | ||
Dadurch erhalten Sie den Dienststatus, die cgroup-Hierarchie und die ersten paar Protokollzeilen | 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: | 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 | ● 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) | 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]: 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 | 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 | 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 | 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: | * 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''' | # '''systemctl is-active application.service''' | ||
Dies gibt den aktuellen Zustand der Einheit zurück, der normalerweise active oder inactive ist | 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 | * 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: | Um zu sehen, ob die Einheit aktiviert ist, können Sie den Befehl is-enabled verwenden: | ||
# '''systemctl is-enabled application.service''' | # '''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 | 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 | 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: | * Dies deutet darauf hin, dass es ein Problem beim Starten der betreffenden Einheit gab: | ||
# '''systemctl is-failed application.service''' | # '''systemctl is-failed application.service''' | ||
Dies gibt bei ordnungsgemäßer Ausführung active zurück oder failed, wenn ein Fehler aufgetreten ist | 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 | * Wurde die Einheit absichtlich angehalten, kann unknown oder inactive zurückgegeben werden | ||
* Ein | * Ein Rückgabewert von „0“ gibt an, dass ein Fehler aufgetreten ist, und ein Rückgabewert von „1“ zeigt jeden anderen Status an | ||
=== Systemstatus === | === 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 | 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 | * Es gibt eine Reihe von systemctl-Befehlen, die diese Informationen bereitstellen | ||
===Auflisten aktueller Einheiten=== | ===Auflisten aktueller Einheiten=== | ||
| Zeile 132: | Zeile 125: | ||
# '''systemctl list-units''' | # '''systemctl list-units''' | ||
Dies zeigt eine Liste aller Einheiten, die systemd derzeit im System aktiv hat | Dies zeigt eine Liste aller Einheiten, die systemd derzeit im System aktiv hat | ||
* Die Ausgabe sieht in etwa folgendermaßen aus: | * Die Ausgabe sieht in etwa folgendermaßen aus: | ||
UNIT | UNIT LOAD ACTIVE SUB DESCRIPTION | ||
atd.service | atd.service loaded active running ATD daemon | ||
avahi-daemon.service | avahi-daemon.service loaded active running Avahi mDomain Name System/DNS-SD Stack | ||
dbus.service | dbus.service loaded active running D-Bus System Message Bus | ||
dcron.service | dcron.service loaded active running Periodic Command Scheduler | ||
dkms.service | dkms.service loaded active exited Dynamic Kernel Modules System | ||
getty@tty1.service | getty@tty1.service loaded active running Getty on tty1 | ||
. | |||
; Ausgabespalten | |||
{| class="wikitable sortable options" | |||
|- | |||
! 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 | 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 | * 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: | Daher sehen Sie dasselbe, wenn Sie systemctl ohne Argumente aufrufen: | ||
# '''systemctl''' | # '''systemctl''' | ||
Durch Hinzufügen von zusätzlichen Flags können wir systemctl anweisen, andere Informationen auszugeben | 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: | * 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''' | # '''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 | 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 | * 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 | 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 | * 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: | * Sie müssen das Flag --all beibehalten, damit systemctl die Anzeige nicht aktiver Einheiten erlaubt: | ||
# '''systemctl list-units --all --state=inactive''' | # '''systemctl list-units --all --state=inactive''' | ||
Ein weiterer gebräuchlicher Filter ist der Filter --type= | Ein weiterer gebräuchlicher Filter ist der Filter --type= | ||
* Wir können systemctl anweisen, nur Einheiten der Art anzuzeigen, an der wir interessiert sind | * 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: | * Um beispielsweise nur aktive Diensteinheiten zu sehen, können wir verwenden: | ||
# '''systemctl list-units --type=service''' | # '''systemctl list-units --type=service''' | ||
===Unit-Dateien auflisten=== | ===Unit-Dateien auflisten=== | ||
Der Befehl list-units zeigt nur Einheiten an, die systemd versucht hat zu parsen und in den Speicher zu laden | 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 | * 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: | * 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''' | # '''systemctl list-unit-files''' | ||
Units (Einheiten) sind Repräsentationen von Ressourcen, von denen systemd Kenntnis hat | 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 | * 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 | * Die Ausgabe hat zwei Spalten: die Unit-Datei und den Zustand | ||
UNIT FILE | UNIT FILE STATE | ||
proc-sys-fs-binfmt_misc.automount | proc-sys-fs-binfmt_misc.automount static | ||
dev-hugepages.mount | dev-hugepages.mount static | ||
dev-mqueue.mount | dev-mqueue.mount static | ||
proc-fs-nfsd.mount | proc-fs-nfsd.mount static | ||
proc-sys-fs-binfmt_misc.mount | proc-sys-fs-binfmt_misc.mount static | ||
sys-fs-fuse-connections.mount | sys-fs-fuse-connections.mount static | ||
sys-kernel-config.mount | sys-kernel-config.mount static | ||
sys-kernel-debug.mount | sys-kernel-debug.mount static | ||
tmp.mount | tmp.mount static | ||
var-lib-nfs-rpc_pipefs.mount | var-lib-nfs-rpc_pipefs.mount static | ||
org.cups.cupsd.path | org.cups.cupsd.path enabled | ||
. | |||
Der Zustand ist in der Regel enabled (aktiviert), disabled (deaktiviert), static (statisch) oder masked (maskiert) | 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 | * 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 | * 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 | * 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 | Die Bedeutung von masked werden wir in Kürze besprechen | ||
=== Einheiten verwalten === | === Einheiten verwalten === | ||
Bisher haben wir mit Diensten gearbeitet und Informationen über die Einheit und die Unit-Dateien angezeigt, von denen systemd Kenntnis hat | 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 | * Mit einigen zusätzlichen Befehlen können wir jedoch spezifischere Informationen über Einheiten herausfinden | ||
===Unit-Datei anzeigen=== | ===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 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: | * Um beispielsweise die Unit-Datei des atd Scheduling-Daemons zu sehen, könnten wir Folgendes eingeben: | ||
| Zeile 224: | Zeile 223: | ||
WantedBy=multi-user.target | WantedBy=multi-user.target | ||
Die Ausgabe ist die Unit-Datei, die dem aktuell laufenden systemd-Prozess bekannt ist | 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) | * 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=== | ===Abhängigkeiten anzeigen=== | ||
| Zeile 231: | Zeile 230: | ||
# '''systemctl list-dependencies sshd.service''' | # '''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 | 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 | * Abhängigkeiten umfassen in diesem Zusammenhang diejenigen Einheiten, die entweder von darüber liegenden Einheiten benötigt oder gewünscht werden | ||
sshd.service | sshd.service | ||
├─system.slice | ├─system.slice | ||
└─basic.target | └─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 | 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 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 | 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 | * 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 | * nach sich selbst beginnen | ||
===Überprüfen der Einheit-Eigenschaften=== | ===Überprüfen der Einheit-Eigenschaften=== | ||
Um die untergeordneten Eigenschaften einer Einheit zu sehen, können Sie den Befehl show verwenden | 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: | * Dadurch wird eine Liste der Eigenschaften angezeigt, die für die angegebene Einheit mit dem Format key=value festgelegt werden: | ||
| Zeile 269: | Zeile 268: | ||
After=syslog.target network.target auditd.service systemd-journald.socket basic.target system.slice | After=syslog.target network.target auditd.service systemd-journald.socket basic.target system.slice | ||
Description=OpenSSH server daemon | Description=OpenSSH server daemon | ||
. | |||
Wenn Sie eine einzelne Eigenschaft anzeigen möchten, können Sie das Flag -p mit dem Eigenschaftsnamen übergeben | 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: | * Um beispielsweise die Konflikte zu sehen, die die Einheit sshd.service hat, können Sie Folgendes eingeben: | ||
# '''systemctl show sshd.service -p Conflicts''' | # '''systemctl show sshd.service -p Conflicts''' | ||
| Zeile 278: | Zeile 277: | ||
===Maskieren und Demaskieren von Einheiten === | ===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 | 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: | * Dies wird als Maskieren der Einheit bezeichnet und ist mit dem Befehl mask möglich: | ||
# ''' systemctl mask nginx.service''' | # ''' systemctl mask nginx.service''' | ||
Dadurch wird verhindert, dass der Nginx-Dienst automatisch oder manuell gestartet wird, solange er maskiert ist | 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: | Wenn Sie die list-unit-files überprüfen, sehen Sie, dass der Dienst nun als maskiert aufgelistet ist: | ||
| Zeile 288: | Zeile 287: | ||
# '''systemctl list-unit-files''' | # '''systemctl list-unit-files''' | ||
kmod-static-nodes.service | kmod-static-nodes.service static | ||
ldconfig.service | ldconfig.service static | ||
mandb.service | mandb.service static | ||
messagebus.service | messagebus.service static | ||
nginx.service | nginx.service masked | ||
quotaon.service | quotaon.service static | ||
rc-local.service | rc-local.service static | ||
rdisc.service | rdisc.service disabled | ||
rescue.service | rescue.service static | ||
Wenn Sie versuchen, den Dienst zu starten, sehen Sie eine Nachricht wie diese: | Wenn Sie versuchen, den Dienst zu starten, sehen Sie eine Nachricht wie diese: | ||
# ''' systemctl start nginx.service''' | # ''' systemctl start nginx.service''' | ||
Failed to start nginx.service: Unit nginx.service is masked | 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: | Um eine Einheit zu demaskieren und wieder für die Verwendung verfügbar zu machen, verwenden Sie den Befehl unmask: | ||
# ''' systemctl unmask nginx.service''' | # ''' systemctl unmask nginx.service''' | ||
Dadurch wird die Einheit in ihren vorherigen Zustand zurückversetzt, sodass sie gestartet oder aktiviert werden kann | Dadurch wird die Einheit in ihren vorherigen Zustand zurückversetzt, sodass sie gestartet oder aktiviert werden kann | ||
=== Bearbeiten von Unit-Dateien === | === 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 | 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 | * Diese Funktionalität wurde in systemd Version 218 hinzugefügt | ||
Der Befehl edit öffnet standardmäßig eine Unit-Datei für die betreffende Einheit | Der Befehl edit öffnet standardmäßig eine Unit-Datei für die betreffende Einheit | ||
# ''' systemctl edit nginx.service''' | # ''' 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 | 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 | * 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 | * Für den nginx.service wird beispielsweise ein Verzeichnis namens nginx.service.d erstellt | ||
Innerhalb dieses Verzeichnisses wird ein Snippet namens override.conf 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 | * 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 | * 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: | 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''' | # ''' systemctl edit --full nginx.service''' | ||
Dadurch wird die aktuelle Unit-Datei in den Editor geladen, wo sie geändert werden kann | 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) | * 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 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: | * Um beispielsweise ein Snippet zu entfernen, können wir Folgendes eingeben: | ||
# ''' rm -r /etc/systemd/system/nginx.service.d''' | # ''' rm -r /etc/systemd/system/nginx.service.d''' | ||
| Zeile 337: | Zeile 336: | ||
# ''' rm /etc/systemd/system/nginx.service''' | # ''' 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 | 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: | * Geben Sie dazu Folgendes ein: | ||
# ''' systemctl daemon-reload''' | # ''' systemctl daemon-reload''' | ||
=== Anpassen des Systemzustands (Runlevel) mit Zielen === | === Anpassen des Systemzustands (Runlevel) mit Zielen === | ||
Ziele sind spezielle Unit-Dateien, die einen Systemzustand oder Synchronisationspunkt beschreiben | 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 | * 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 | * 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 | 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 | * 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 | 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, 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 | * 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 === | ===Abrufen und Einrichten des Standardziels === | ||
Der Prozess systemd hat ein Standardziel, das er beim Booten des Systems verwendet | 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 | * 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: | * Um das Standardziel für Ihr System zu finden, geben Sie Folgendes ein: | ||
| Zeile 361: | Zeile 360: | ||
multi-user.target | multi-user.target | ||
Wenn Sie ein anderes Standardziel festlegen möchten, können Sie set-default verwenden | 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: | * 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''' | # ''' systemctl set-default graphical.target''' | ||
| Zeile 369: | Zeile 368: | ||
# '''systemctl list-unit-files --type=target''' | # '''systemctl list-unit-files --type=target''' | ||
Im Gegensatz zu Runleveln können mehrere Ziele gleichzeitig aktiv sein | 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 | * 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: | * Um alle aktiven Ziele zu sehen, geben Sie Folgendes ein: | ||
# '''systemctl list-units --type=target''' | # '''systemctl list-units --type=target''' | ||
===Isolieren von Zielen=== | ===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 | 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 | * Der Befehl, den wir dazu benötigen, heißt entsprechend isolate | ||
* Dies ist ähnlich wie das Ändern der Runlevel in anderen Init-Systemen | * 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 | 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 | * 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 | 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''' | # '''systemctl list-dependencies multi-user.target''' | ||
| Zeile 389: | Zeile 388: | ||
===Verwenden von Shortcuts für wichtige Ereignisse=== | ===Verwenden von Shortcuts für wichtige Ereignisse=== | ||
Es gibt Ziele, die für wichtige Ereignisse wie Ausschalten oder Neustart definiert sind | 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 | * 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 | Um beispielsweise das System in den (Einzelbenutzer) Rettungsmodus zu versetzen, können Sie einfach den Befehl rescue verwenden, anstatt isolate rescue.target | ||
# ''' systemctl rescue''' | # ''' systemctl rescue''' | ||
Dies bietet die zusätzliche Funktionalität, alle angemeldeten Benutzer über das Ereignis zu alarmieren | 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: | Um das System anzuhalten, können Sie den Befehl halt verwenden: | ||
| Zeile 406: | Zeile 405: | ||
# ''' systemctl reboot''' | # ''' systemctl reboot''' | ||
Diese alarmieren angemeldete Benutzer, dass das Ereignis auftritt, was nur durch Ausführen oder Isolieren des Ziels nicht möglich ist | 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 | * 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: | Um beispielsweise das System neu zu starten, können Sie normalerweise eingeben: | ||
| Zeile 414: | Zeile 413: | ||
https://www.digitalocean.com/community/tutorials/how-to-use-systemctl-to-manage-systemd-services-and-units-de | https://www.digitalocean.com/community/tutorials/how-to-use-systemctl-to-manage-systemd-services-and-units-de | ||
; Anwendungen | ; Anwendungen | ||
* Änderungen als root | * Änderungen als root | ||
** Alle vorgestellten Informationen darf jeder Nutzer abfragen | ** Alle vorgestellten Informationen darf jeder Nutzer abfragen | ||
* Um Änderungen an der Konfiguration vorzunehmen, müssen Sie "systemctl" jedoch mit Root-Rechten starten | * 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 | * Dann lassen sich einzelne Units über »<tt>systemctl start</tt>« aktivieren beziehungsweise mit »<tt>systemctl stop</tt>« anhalten | ||
Der folgende Befehl fährt den SSH-Daemon hoch: | Der folgende Befehl fährt den SSH-Daemon hoch: | ||
# '''systemctl start sshd.service''' | # '''systemctl start sshd.service''' | ||
* Auf Systemen mit SysV-Init würde dies dem Aufruf des Skripts "/etc/init.d/sshd start" entsprechen | * 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 | * 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 | * Den SSH-Daemon könnten Sie folglich einfach mit »<tt>systemctl start sshd</tt>« anwerfen. "systemctl" wechselt natürlich auch Targets | ||
Der folgende Befehl aktiviert beispielsweise das Target "rescue.target", was wiederum zu einem Rettungssystem führt: | Der folgende Befehl aktiviert beispielsweise das Target "rescue.target", was wiederum zu einem Rettungssystem führt: | ||
# '''systemctl isolate rescue.target''' | # '''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 | * 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: | Um zu verhindern, dass ein Dienst beim Systemstart automatisch hochfährt, deaktivieren Sie ihn: | ||
| Zeile 437: | Zeile 436: | ||
In diesem Beispiel würde Systemd den SSH-Daemon aus sämtlichen Targets nehmen. Mit "enable" knipsen Sie ihn wieder an: | 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''' | # '''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 | 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 | * Im Hintergrund setzt Systemd dabei übrigens lediglich die symbolischen Links in den ".wants"-Unterverzeichnissen | ||
<nowiki>[[Image:Bild1.png|top]]</nowiki> | <nowiki>[[Image:Bild1.png|top]]</nowiki> | ||
* 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) | * 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 == | == Konfiguration == | ||
=== Dateien === | === Dateien === | ||
<noinclude> | <noinclude> | ||
== Anhang == | == Anhang == | ||
=== Siehe auch === | === Siehe auch === | ||
| Zeile 468: | Zeile 474: | ||
==== Dokumentation ==== | ==== Dokumentation ==== | ||
===== Man- | ===== 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 ===== | ===== Info-Pages ===== | ||
==== Links ==== | ==== Links ==== | ||
| Zeile 476: | Zeile 486: | ||
{{DISPLAYTITLE:systemctl}} | {{DISPLAYTITLE:systemctl}} | ||
[[Kategorie:Linux/Befehl]] | |||
[[Kategorie:Systemd]] | [[Kategorie:Systemd]] | ||
</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
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
- 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
- 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)
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