Systemd
ist ein Init-System und Systemmanager, der weitgehend zum neuen Standard für Linux-Distributionen geworden ist. Aufgrund seiner starken Verbreitung lohnt es sich, sich mit systemd
vertraut zu machen, da es die Administration von Servern erheblich erleichtert. Wenn Sie die Werkzeuge und Daemons, aus denen systemd
besteht, kennenlernen und verwenden, werden Sie die Leistungsfähigkeit, Flexibilität und Fähigkeiten, die es bietet, besser zu schätzen wissen oder zumindest ihre Arbeit mit minimalem Aufwand erledigen können.
In diesem Leitfaden besprechen wir den Befehl systemctl
, bei dem es sich um das zentrale Verwaltungswerkzeug zur Steuerung des Init-Systems handelt. Wir behandeln die Verwaltung von Diensten, die Überprüfung des Status, die Änderung von Systemzuständen und die Arbeit im Umgang mit den Konfigurationsdateien.
Bitte beachten Sie, dass systemd
zwar zum Standard-Init-System für viele Linux-Distributionen geworden ist, aber nicht durchgängig in allen Distributionen implementiert ist. Wenn Ihr Terminal beim Durcharbeiten dieses Tutorials die Fehlermeldung bash: systemctl is not installed
ausgibt, ist es wahrscheinlich, dass auf Ihrem Rechner ein anderes Init-System installiert ist.
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.
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:
- sudo 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:
- sudo 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:
- sudo systemctl stop application.service
Um einen laufenden Dienst neu zu starten, können Sie den Befehl restart
verwenden:
- sudo 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:
- sudo 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:
- sudo systemctl reload-or-restart application.service
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
:
- sudo 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:
- sudo 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.
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:
Output● 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 Exit-Status von „0“ gibt an, dass ein Fehler aufgetreten ist, und ein Exit-Status von „1“ zeigt jeden anderen Status an.
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.
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:
OutputUNIT LOAD ACTIVE SUB DESCRIPTION
atd.service loaded active running ATD daemon
avahi-daemon.service loaded active running Avahi mDNS/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
. . .
Die Ausgabe weist die folgenden Spalten auf:
systemd
-Einheitennamesystemd
geparst wurde. Die Konfiguration von geladenen Einheiten wird im Speicher gespeichert.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 hat 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
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.
OutputUNIT 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.
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.
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
Output[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).
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.
Outputsshd.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.
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
OutputId=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
OutputConflicts=shutdown.target
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:
- sudo 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
Output. . .
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:
- sudo systemctl start nginx.service
OutputFailed 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
:
- sudo systemctl unmask nginx.service
Dadurch wird die Einheit in ihren vorherigen Zustand zurückversetzt, sodass sie gestartet oder aktiviert werden kann.
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.
- sudo 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:
- sudo 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:
- sudo rm -r /etc/systemd/system/nginx.service.d
Um eine vollständige geänderte Unit-Datei zu entfernen, geben wir Folgendes ein:
- sudo 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:
- sudo systemctl daemon-reload
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.
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
Outputmulti-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:
- sudo systemctl set-default graphical.target
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
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:
- sudo systemctl isolate multi-user.target
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
.
- sudo 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:
- sudo systemctl halt
Um eine vollständiges Herunterfahren einzuleiten, können Sie den Befehl poweroff
verwenden:
- sudo systemctl poweroff
Ein Neustart kann mit dem Befehl reboot
gestartet werden:
- sudo 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:
- sudo reboot
Inzwischen sollten Sie mit einigen der grundlegenden Funktionen des Befehls systemctl
vertraut sein, die es Ihnen ermöglichen, mit Ihrer systemd
-Instanz zu interagieren und sie zu steuern. Das Dienstprogramm systemctl
wird Ihr Hauptinteraktionspunkt für die Verwaltung von Diensten und Systemzuständen sein.
Während systemctl
hauptsächlich mit dem Kernproszess systemd
arbeitet, gibt es andere Komponenten für das Ökosystem systemd
, die von anderen Dienstprogrammen gesteuert werden. Andere Funktionen, wie Protokollverwaltung und Benutzersitzungen werden von separaten Daemons und Verwaltungsdienstprogrammen (journald
/journalctl
bzw. logind
/loginctl
) verwaltet. Wenn Sie sich die Zeit nehmen, sich mit diesen anderen Werkzeugen und Daemons vertraut zu machen, wird die Verwaltung zu einer einfacheren Aufgabe.
Thanks for learning with the DigitalOcean Community. Check out our offerings for compute, storage, networking, and managed databases.
This textbox defaults to using Markdown to format your answer.
You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!
Sign up for Infrastructure as a Newsletter.
Working on improving health and education, reducing inequality, and spurring economic growth? We'd like to help.
Get paid to write technical tutorials and select a tech-focused charity to receive a matching donation.