Kapitel 4. Dienste mit systemd verwalten
Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: translation-feedback@oreilly.com
Jedes Mal, wenn du deinen Linux-Computer startest, startet das Initialisierungssystem eine Reihe von Prozessen, je nach Systemeinstellung ein paar Dutzend bis Hunderte. Du kannst dies auf deinem Startbildschirm sehen(Abbildung 4-1; drücke die Escape-Taste, um deinen grafischen Startbildschirm auszublenden und die Startmeldungen zu sehen).
Abbildung 4-1. Linux-Startmeldungen
Früher hatten wir das Unix System V Initialisierungssystem (SysV init), BSD init und Linux Standard Base (LSB) init, um Prozesse beim Start zu starten. SysV init war das gängigste. Diese Zeiten sind vorbei, und jetzt ist systemd das glänzende neue Init-System für Linux. Es wurde von allen großen Linux-Distributionen übernommen, obwohl es natürlich auch eine Reihe von Distributionen gibt, die noch die altenInit-Systeme verwenden.
In diesem Kapitel erfährst du, ob deine Linux-Distribution systemd verwendet. Du erfährst, was Prozesse, Threads, Dienste und Daemons sind und wie du systemd verwendest, um Dienste zu verwalten: starten, stoppen, aktivieren, deaktivieren und den Status überprüfen. Du lernst den systemctl-Befehl kennen, den systemd-System- und Dienstmanager.
systemd ( ) wurde entwickelt, um Funktionen für moderne, komplexe Server- und Desktopsysteme bereitzustellen, und es kann wesentlich mehr als die alten Init-Systeme. Es bietet eine vollständige Verwaltung der Dienste vom Start bis zum Herunterfahren, indem es Prozesse beim Booten und bei Bedarf nach dem Booten startet und Dienste herunterfährt, wenn sie nicht benötigt werden. Es verwaltet Funktionen wie die Systemprotokollierung, das automatische Einhängen von Dateisystemen, die automatische Auflösung von Dienstabhängigkeiten, Namensdienste, die Geräteverwaltung, die Verwaltung von Netzwerkverbindungen, die Login-Verwaltung und eine Vielzahl anderer Aufgaben.
Das hört sich nach viel an, bis du erkennst, dass Prozesse alles auf einem Computer machen und all diese Funktionen früher von einer großen Auswahl anderer Programme bereitgestellt wurden. systemd fasst alles in einer integrierten Software-Suite zusammen, die auf allen Linux-Systemen gleich funktionieren sollte, obwohl es wie immer bei Linux einige kleinere Ausnahmen gibt, wie z. B. Dateispeicherorte und Dienstnamen. Sei dir bewusst, dass dein spezielles Linux möglicherweise von den Beispielen in diesem Kapitel abweicht.
systemd versucht, die Startzeiten zu verkürzen und die Systemressourcen effizienter zu verteilen, indem Prozesse gleichzeitig und parallel gestartet werden und nur die notwendigen Dienste gestartet werden. Ein Dienst, der von anderen Diensten abhängt, muss nicht mehr darauf warten, dass diese Dienste verfügbar werden, weil er nur einen wartenden Unix-Socket braucht, um verfügbar zu werden. Rezept 4.9 zeigt, wie du Prozesse findest, die deinen Systemstart verlangsamen.
Die systemd-Binärdateien sind in C geschrieben, was eine gewisse Leistungssteigerung ermöglicht. Die Legacy-Inits sind Massen von Shell-Skripten, und jede kompilierte Sprache arbeitet schneller als Shell-Skripte.
systemd ist rückwärtskompatibel mit SysV init. Die meisten Linux-Distributionen behalten die alten SysV-Konfigurationsdateien und -Skripte bei, darunter /etc/inittab und die Verzeichnisse /etc/rc.d/ und /etc/init.d/. Wenn ein Dienst keine systemd-Konfigurationsdatei hat, sucht systemd nach einer SysV-Konfigurationsdatei. systemd ist auch rückwärtskompatibel mit Linux Standard Base (LSB) init.
systemd-Dienstdateien sind kleiner und leichter zu verstehen als SysV-Initdateien. Vergleiche eine SysV-Initdatei für sshd mit ihrer systemd-Dienstdatei. Dies ist ein Ausschnitt aus der sshd-Initdatei /etc/init.d/ssh von MX Linux:
#! /bin/sh ### BEGIN INIT INFO # Provides: sshd # Required-Start: $remote_fs $syslog # Required-Stop: $remote_fs $syslog # Default-Start: 2 3 4 5 # Default-Stop: # Short-Description: OpenBSD Secure Shell server ### END INIT INFO set -e # /etc/init.d/ssh: start and stop the OpenBSD "secure shell(tm)" daemon test -x /usr/sbin/sshd || exit 0 umask 022 if test -f /etc/default/ssh; then [...]
Das geht insgesamt 162 Zeilen lang so weiter. Dies ist eine vollständige systemd-Dienstdatei von Ubuntu 20.04, /lib/systemd/system/ssh.service:
[Unit] Description=OpenBSD Secure Shell server Documentation=man:sshd(8) man:sshd_config(5) After=network.target auditd.service ConditionPathExists=!/etc/ssh/sshd_not_to_be_run [Service] EnvironmentFile=-/etc/default/ssh ExecStartPre=/usr/sbin/sshd -t ExecStart=/usr/sbin/sshd -D $SSHD_OPTS ExecReload=/usr/sbin/sshd -t ExecReload=/bin/kill -HUP $MAINPID KillMode=process Restart=on-failure RestartPreventExitStatus=255 Type=notify RuntimeDirectory=sshd RuntimeDirectoryMode=0755 [Install] WantedBy=multi-user.target Alias=sshd.service
Auch ohne die Dokumentation zu lesen oder etwas über systemd zu wissen, kannst du verstehen, was diese Datei tun soll.
Unter Rethinking PID 1 findest du eine ausführliche Einführung in systemd von Lennart Poettering, einem seiner Erfinder und Betreuer. Rethinking PID 1 beschreibt die Gründe für die Entwicklung eines neuen Init-Systems, seine Architektur, seine Vorteile und wie es bestehende Linux-Kernel-Funktionen nutzt, anstatt bestehende Funktionen zu duplizieren.
4.1 Lernen, ob dein Linux systemd verwendet
Lösung
Suche nach dem Verzeichnis /run/systemd/system/. Wenn es existiert, dann ist dein Init-System systemd.
Diskussion
Das Verzeichnis /run/systemd/ kann auf deinem System vorhanden sein, wenn deine Distribution mehrere Init-Systeme unterstützt. Aber systemd ist nicht das aktive Init, wenn du nicht /run/systemd/system/ siehst.
Es gibt verschiedene andere Möglichkeiten, um herauszufinden, welches Init-System dein System verwendet. Versuche, /sbin/init abzufragen. Ursprünglich war dies die ausführbare Datei SysV. Heute behalten die meisten Linux-Distributionen den Namen bei und verlinken ihn mit der ausführbaren Datei systemd. Dieses Beispiel bestätigt, dass es sich bei init um systemd handelt:
$ stat /sbin/init File: /sbin/init -> /lib/systemd/systemd [...]
Auf einem System, das SysV init verwendet, hat es keinen Symlink:
$ stat /sbin/init File: /sbin/init [...]
Das Pseudodateisystem /proc ist eine Schnittstelle zu deinem Linux-Kernel und enthält den aktuellen Status eines laufenden Systems. Es wird Pseudodateisystem genannt, weil es nur im Speicher und nicht auf der Festplatte existiert. In diesem Beispiel ist /proc/1/exe mit der ausführbaren Datei systemd verlinkt:
$ sudo stat /proc/1/exe File: /proc/1/exe -> /lib/systemd/systemd [...]
Auf einem SysV-System ist es mit init verknüpft:
$ sudo stat /proc/1/exe File: /proc/1/exe -> /sbin/init [...]
Die Datei /proc/1/comm zeigt dein aktives Init-System an:
$ cat /proc/1/comm systemd
Auf einem SysV-System meldet es init:
$ cat /proc/1/comm init
Der Befehl , der der Prozess-ID (PID) 1 zugeordnet ist, ist dein Init. PID 1 ist der erste Prozess, der beim Start gestartet wird und der dann alle anderen Prozesse startet. Du kannst dies mit dem Befehl ps sehen:
$ ps -p 1
PID TTY TIME CMD
1 ? 00:00:00 systemd
Wenn das Init SysV ist, sieht es so aus:
$ ps -p 1
PID TTY TIME CMD
1 ? 00:00:00 init
Siehe Rezept 4.2 für weitere Informationen zu PID 1.
Die Linux-Unterstützung für systemd variiert. Die meisten der großen Linux-Distributionen haben systemd übernommen, darunter Fedora, Red Hat, CentOS, openSUSE, SUSE Linux Enterprise, Debian, Ubuntu, Linux Mint, Arch, Manjaro, Elementary und Mageia Linux.
Einige beliebte Distributionen, die systemd nicht unterstützen oder es zwar enthalten, aber nicht als Standard-Init verwenden, sind Slackware, PCLinuxOS, Gentoo Linux, MX Linux, und antiX.
Siehe auch
-
Distrowatch für Informationen über Hunderte vonLinux-Distributionen
-
man 5 proc
-
Mann 1 pstree
-
Mann 1 ps
4.2 PID 1, die Mutter aller Prozesse, verstehen
Lösung
PID 1 ist die Mutter aller Prozesse auf Linux-Systemen. Er ist der erste Prozess, der gestartet wird, und startet dann alle anderen Prozesse.
Prozesse sind eine oder mehrere laufende Instanzen eines Programms. Jede Aufgabe in einem Linux-System wird von einem Prozess ausgeführt. Prozesse können unabhängige Kopien von sich selbst erstellen, das heißt, sie können sich gabeln. Die Fork-Kopien werdenChilds genannt, das Original ist der Parent. Jedes Kind hat seine eigene eindeutige PID und eine eigene Zuweisung von Systemressourcen wie CPU und Speicher. Threads sind leichtgewichtige Prozesse, die parallel laufen und Systemressourcen mit ihren Eltern teilen.
Einige Prozesse laufen im Hintergrund und interagieren nicht mit den Benutzern. Linux nennt diese Prozesse Dienste oder Daemons, und ihre Namen enden meist mit dem Buchstaben D, wie z. B. httpd, sshd und systemd.
Jedes Linux-System startet zuerst die PID 1, die dann alle anderen Prozesse startet. Verwende den Befehl ps , um alle laufenden Prozesse in der PID-Reihenfolge aufzulisten:
$ ps -ef UID PID PPID C STIME TTY TIME CMD root 1 0 0 10:06 ? 00:00:01 /sbin/init splash root 2 0 0 10:06 ? 00:00:00 [kthreadd] root 3 2 0 10:06 ? 00:00:00 [rcu_gp] root 4 2 0 10:06 ? 00:00:00 [rcu_par_gp] [...]
Der pstree-Befehl organisiert diese Masse an Informationen in einem Baumdiagramm. Dieses Beispiel zeigt alle Prozesse, ihre Kindprozesse, PIDs und Threads, die in geschweifte Klammern eingeschlossen sind:
$ pstree -p
systemd(1)─┬─ModemManager(925)─┬─{ModemManager}(944)
│ └─{ModemManager}(949)
├─NetworkManager(950)─┬─dhclient(1981)
│ ├─{NetworkManager}(989)
│ └─{NetworkManager}(991)
├─accounts-daemon(927)─┬─{accounts-daemon}(938)
│ └─{accounts-daemon}(948)
├─acpid(934)
├─agetty(1103)
├─avahi-daemon(953)───avahi-daemon(970)
[...]
Die vollständige Ausgabe von pstree ist ziemlich groß. Du kannst dir einen einzelnen Prozess, der durch seine PID identifiziert wird, sowie seine Eltern, Kinder und Threads ansehen, wie im folgenden Beispiel für den Texteditor Kate:
$ pstree -sp 5193
systemd(1)───kate(5193)─┬─bash(5218)
├─{kate}(5195)
├─{kate}(5196)
├─{kate}(5197)
├─{kate}(5198)
├─{kate}(5199)
[...]
Das zeigt, dass systemd(1) Kates Elternteil ist, bash(5218) ist Kates Kind und alle Prozesse in geschweiften Klammern sind Kates Threads.
Diskussion
Prozesse befinden sich immer in einem von mehreren Zuständen, und diese Zustände ändern sich je nach Systemaktivität. Im folgenden pstree-Beispiel werden die Felder PID, Benutzer, Status und Befehl angezeigt:
$ ps -eo pid,user,stat,comm
PID USER STAT COMMAND
1 root Ss systemd
2 root S kthreadd
32 root I< kworker/3:0H-kb
68 root SN khugepaged
11222 duchess Rl konsole
-
R wird entweder gerade ausgeführt oder wartet in der Warteschlange.
-
l bedeutet, dass der Prozess multithreadingfähig ist.
-
S ist ein unterbrechbarer Schlaf; der Prozess wartet auf ein Ereignis, um es zu beenden.
-
s ist ein Sitzungsleiter. Sitzungen sind zusammenhängende Prozesse, die als eine Einheit verwaltet werden.
-
I ist ein ungenutzter Kernel-Thread.
-
< bedeutet hohe Priorität.
-
N ist eine niedrige Priorität.
Es gibt einige seltene Zustände, die du unter in Mann 1 ps nachlesen kannst.
Siehe auch
- Rezept 4.7
- man 5 proc
- Mann 1 pstree
- Mann 1 ps
4.3 Auflisten der Dienste und ihrer Zustände mit systemctl
Lösung
systemctl, der systemd Manager-Befehl, verrät alles. Wenn du ihn ohne Optionen ausführst, erhältst du eine detaillierte Liste aller geladenen Units. Eine systemd-Unit ist ein zusammenhängender Stapel von Prozessen, der in einer Unit-Konfigurationsdatei definiert und von systemd verwaltet wird:
$ systemctl
Das druckt einen riesigen Haufen an Informationen aus: 177 aktive geladene Einheiten auf meinem Testsystem mit den vollständigen Namen der Einheiten, dem Status und einer langen Beschreibung. Leite die Ausgabe zum leichteren Studium in eine Textdatei um:
$ systemctl > /tmp/systemctl-units.txt
Gönne dir noch mehr Informationen, indem du alle Einheiten auflistest, aktive und inaktive:
$ systemctl --all
Das Ergebnis sind 349 geladene Einheiten auf meinem Testsystem, einschließlichnicht gefundener und inaktiver Einheiten. Wie viele Unit-Dateien gibt es insgesamt? Das folgende Beispiel zeigt 5 von 322:
$ systemctl list-unit-files UNIT FILE STATE proc-sys-fs-binfmt_misc.automount static -.mount generated mount generated dev-hugepages.mount static home.mount generated [...] 322 unit files listed.
Wir interessieren uns für Servicedateien, weil Linux-Benutzer und -Administratoren hauptsächlich mit Servicedateien interagieren und sich nur selten mit anderen Arten von Unit-Dateien befassen müssen. Wie viele sind installiert? Schauen wir mal:
$ systemctl list-unit-files --type=service UNIT FILE STATE accounts-daemon.service enabled acpid.service disabled alsa-state.service static alsa-utils.service masked anacron.service enabled [...] 212 unit files listed.
Das vorangehende Beispiel zeigt die vier häufigsten Zustände, in denen sich ein Dienst befinden kann: aktiviert, deaktiviert, statisch oder maskiert.
Nur aktivierte Dienste auflisten:
$ systemctl list-unit-files --type=service --state=enabled UNIT FILE STATE accounts-daemon.service enabled anacron.service enabled apparmor.service enabled autovt@.service enabled avahi-daemon.service enabled [...] 62 unit files listed.
Führe nur behinderte Dienste auf:
$ systemctl list-unit-files --type=service --state=disabled UNIT FILE STATE acpid.service disabled brltty.service disabled console-getty.service disabled mariadb@.service disabled [...] 12 unit files listed.
Nur statische Dienste auflisten:
$ systemctl list-unit-files --type=service --state=static UNIT FILE STATE alsa-restore.service static alsa-state.service static apt-daily-upgrade.service static apt-daily.service static [...] 106 unit files listed.
Liste nur maskierte Dienste auf:
$ systemctl list-unit-files --type=service --state=masked UNIT FILE STATE alsa-utils.service masked bootlogd.service masked bootlogs.service masked checkfs.service masked [...] 36 unit files listed.
Diskussion
Die Service-Unit-Dateien befinden sich in /usr/lib/systemd/system/ oder/lib/systemd/system/, je nachdem, wo deine Linux-Distribution sie ablegt. Es sind Dateien im Klartext, die du lesen kannst.
- aktiviert
-
Diese zeigt an, dass der Dienst verfügbar geworden ist und von systemd verwaltet wird. Wenn ein Dienst aktiviert wird, erstellt systemd einen Symlink in/etc/systemd/system/ von der Unit-Datei in /lib/systemd/system/. Er kann vom Benutzer mit dem Befehlsystemctl gestartet, gestoppt, neu geladen und deaktiviert werden.
Hinweis
Wenn du einen Dienst aktivierst, wird er nicht sofort gestartet, und wenn du einen Dienst deaktivierst, wird er nicht sofort gestoppt (siehe Rezept 4.6).
- deaktiviert
-
Diabled bedeutet, dass es keinen Symlink in /etc/systemd/system/ gibt und er nicht automatisch beim Booten startet. Du kannst ihn manuell stoppen und starten.
- maskiert
-
Diese bedeutet, dass der Dienst mit /dev/null/ verknüpft ist. Er ist vollständig deaktiviert und kann auf keinen Fall gestartet werden.
- statisch
-
Das bedeutet, dass die Unit-Datei von anderen Unit-Dateien abhängig ist und nicht vom Benutzer gestartet oder gestoppt werden kann.
Du wirst einige weniger verbreitete Dienstzustände sehen:
- indirekt
-
Indirekte Zustände gehören zu Diensten, die nicht von den Nutzern verwaltet werden sollen, sondern von anderen Diensten genutzt werden können.
- erzeugt
-
Die erzeugten Zustände zeigen an, dass der Dienst von einer nicht-nativen systemd-Initialisierungskonfigurationsdatei konvertiert wurde, entweder SysV oder LSB init.
Siehe auch
-
man 1 systemctl
4.4 Abfrage des Status ausgewählter Dienste
Lösung
systemctl status bietet ein nettes kleines Bündel an nützlichen Statusinformationen. Das folgende Beispiel fragt den CUPS-Dienst ab. CUPS, das Common Unix Printing System, sollte auf allen Linux-Systemen vorhanden sein:
$ systemctl status cups.service
● cups.service - CUPS Scheduler
Loaded: loaded (/lib/systemd/system/cups.service; enabled; vendor preset:
enabled)
Active: active (running) since Sun 2021-11-22 11:01:48 PST; 4h 17min ago
TriggeredBy: ● cups.path
● cups.socket
Docs: man:cupsd(8)
Main PID: 1403 (cupsd)
Tasks: 2 (limit: 18760)
Memory: 3.8M
CGroup: /system.slice/cups.service
├─1403 /usr/sbin/cupsd -l
└─1421 /usr/lib/cups/notifier/dbus dbus://
Nov 22 11:01:48 host1 systemd[1]: Started CUPS Scheduler.
Frag mehrere Dienste mit einer durch Leerzeichen getrennten Liste ab:
$ systemctl status mariadb.service bluetooth.service lm-sensors.service
Diskussion
In diesem kleinen Teil der Ausgabe(Abbildung 4-2) stecken viele nützliche Informationen.
Abbildung 4-2. systemctl-Statusausgabe für den CUPS-Druckerdienst
Der Punkt neben dem Dienstnamen ist eine schnelle Statusanzeige. Auf den meisten Terminals erscheint er in verschiedenen Farben. Weiß bedeutet, dass der Dienst inaktiv oder deaktiviert ist. Rot bedeutet, dass er fehlgeschlagen ist oder ein Fehler vorliegt. Grün steht für einen aktiven,nachladenden oder aktivierenden Zustand. Der Rest der Informationen in der Ausgabe wird im Folgenden beschrieben:
- Geladen
-
Überprüft, ob die Unit-Datei in den Speicher geladen wurde, zeigt ihren vollständigen Pfad an,der Dienst ist aktiviert (siehe die Diskussion über Zustände inRezept 4.3), und
vendor preset: disabled/enabledgibt an, ob die Installation standardmäßig beim Booten gestartet wird oder nicht. Wenn er deaktiviert ist, wird er standardmäßig nicht beim Booten gestartet. Hier wird nur die Herstellereinstellung angezeigt und nicht, ob der Dienst derzeit aktiviert oder deaktiviert ist. - Aktiv
-
Hier erfährst du, ob der Dienst aktiv oder inaktiv ist und wie lange er sich schon in diesem Zustand befindet.
- Prozess
-
Meldet die PIDs und ihre Befehle und Daemons.
- Haupt-PID
-
Dies ist die Prozessnummer für das cgroup-Slice.
- Aufgaben
-
Meldet, wie viele Aufgaben der Dienst gestartet hat. Aufgaben sind PIDs.
- CGruppe
-
Zeigt an, zu welchem Unit Slice der Dienst gehört und seine PID. Die drei Standard-Unit-Slices sind user.slice, system.slice undmachine.slice.
Linux-Kontrollgruppen (cgroups) sind Gruppen von zusammenhängenden Prozessen und all ihren zukünftigen Kindern. In systemd ist ein Slice eine Unterteilung einer cgroup, und jedes Slice verwaltet eine bestimmte Gruppe von Prozessen. Führe systemctl status aus, um ein Diagramm der cgroup-Hierarchie zu sehen.
Standardmäßig werden Service- und Scope-Units in/lib/systemd/system/system.slice gruppiert.
Benutzersitzungen werden in /lib/systemd/system/user.slice gruppiert.
Virtuelle Maschinen und Container, die bei systemd registriert sind, werden in/lib/systemd/system/machine.slice gruppiert.
Die restlichen Zeilen sind die letzten Protokolleinträge von journalctl, dem systemd Log Manager.
Siehe auch
-
man 1 systemctl
-
man 5 systemd.slice
-
man 1 journalctl
4.5 Dienste starten und stoppen
Lösung
Dies ist ein Auftrag für systemctl. Die folgenden Beispiele verwenden den SSH-Dienst, um die Dienstverwaltung zu demonstrieren.
Starte einen Dienst:
$ sudo systemctl start sshd.service
Einen Dienst anhalten:
$ sudo systemctl stop sshd.service
Stoppe einen Dienst und starte ihn dann neu:
$ sudo systemctl restart sshd.service
Lade die Konfiguration des Dienstes neu. Du hast zum Beispiel eine Änderung ansshd_config vorgenommen und möchtest die neue Konfiguration laden, ohne den Dienst neu zu starten:
$ sudo systemctl reload sshd.service
Diskussion
Alle diese Befehle funktionieren auch mit mehreren Diensten,z.B. mit einem Leerzeichen:
$ sudo systemctl start sshd.service mariadb.service firewalld.service
Wenn du dich für die Befehle interessierst, die systemd im Hintergrund ausführt, um die einzelnen Daemons zu starten, neu zu laden oder zu stoppen, sieh in ihren Unit-Dateien nach. Einige Dienste haben Start-, Reload-, Stop- und andere Anweisungen in ihren Unit-Dateien, wie dieses Beispiel für httpd:
ExecStart=/usr/sbin/httpd/ $OPTIONS -DFOREGROUND
ExecReload=/usr/sbin/httpd $OPTIONS -k graceful
ExecStop=/bin/kill -WINCH ${MAINPID}
Du musst mit diesen Informationen nichts Besonderes machen. Sie sind da, wenn du wissen willst, wie systemctl einen bestimmten Dienst verwaltet.
Siehe auch
-
man 1 systemctl
4.6 Aktivieren und Deaktivieren von Diensten
Lösung
Wenn du einen Dienst aktivierst, wird er beim Booten automatisch gestartet.
Das Deaktivieren eines Dienstes verhindert, dass er beim Booten gestartet wird, aber er kann manuell gestartet und gestoppt werden.
Durch das Maskieren eines Dienstes wird dieser deaktiviert, sodass er nicht mehr gestartet werden kann.
Das folgende Beispiel aktiviert den sshd-Dienst:
$ sudo systemctl enable sshd.service Created symlink /etc/systemd/system/multi-user.target.wants/sshd.service → /usr/lib/systemd/system/sshd.service
Die Ausgabe zeigt, dass die Aktivierung eines Dienstes bedeutet, dass ein Symlink von der Dienstdatei in /lib/systemd/system/ nach /etc/systemd/system/ erstellt wird. Dadurch wird der Dienst nicht gestartet. Du kannst den Dienst mit systemctl start starten oder mit der Option --now den Dienst in einem Befehl aktivieren und starten:
$ sudo systemctl enable --now sshd.service
Dieser Befehl deaktiviert den sshd-Dienst. Er hält den Dienst nicht an, sodass du ihn nach der Deaktivierung manuell anhalten musst:
$ sudo systemctl disable sshd.service Removed /etc/systemd/system/multi-user.target.wants/sshd.service $ sudo systemctl stop sshd.service
Oder du kannst sie mit einem Befehl deaktivieren und stoppen:
$ sudo systemctl disable --now sshd.service
Mit diesem Befehl wird der Dienst mariadb wieder aktiviert und deaktiviert und dann wieder aktiviert. Wenn du die Symlinks für einen Dienst manuell erstellt hast, ist dies nützlich, um sie schnell auf die Standardwerte zurückzusetzen:
$ sudo systemctl reenable mariadb.service Removed /etc/systemd/system/multi-user.target.wants/mariadb.service. Removed /etc/systemd/system/mysqld.service. Removed /etc/systemd/system/mysql.service. Created symlink /etc/systemd/system/mysql.service → /lib/systemd/system/mariadb.service. Created symlink /etc/systemd/system/mysqld.service → /lib/systemd/system/mariadb.service. Created symlink /etc/systemd/system/multi-user.target.wants/mariadb.service → /lib/systemd/system/mariadb.service.
Der folgende Befehl deaktiviert den Bluetooth-Dienst vollständig, indem er ihn maskiert, so dass er überhaupt nicht gestartet werden kann:
$ sudo systemctl mask bluetooth.service Created symlink /etc/systemd/system/bluetooth.service → /dev/null.
Wenn du den Bluetooth-Dienst demaskierst, wird er nicht aktiviert und muss daher manuell gestartet werden:
$ sudo systemctl unmask bluetooth.service Removed /etc/systemd/system/bluetooth.service. $ sudo systemctl start bluetooth.service
Diskussion
Wenn du einen Dienst aktivierst, deaktivierst, maskierst oder demaskierst, bleibt er in seinem aktuellen Zustand, es sei denn, du verwendest die Option --now. Die Option --now funktioniert mitenable, disable und mask, um den Dienst sofort anzuhalten oder zu starten, aber nicht mit unmask.
In der Diskussion in Rezept 4.3 erfährst du mehr darüber, wie systemd Symlinks verwendet, um Dienste zu verwalten.
Siehe auch
-
man 1 systemctl
-
Die Diskussion in Rezept 4.3, um zu erfahren, wie systemd Symlinks verwendet, um Dienste zu verwalten
4.7 Anhalten von störenden Prozessen
Lösung
Das Anhalten eines Prozesses wird als Töten des Prozesses bezeichnet. Auf Linux-Systemen mit systemd solltest du systemctl kill verwenden. Auf Systemen ohne systemd verwendest du den Legacy-Befehlkill.
systemctl kill ist vorzuziehen, weil es alle Prozesse stoppt, die zu einem Dienst gehören, und keine verwaisten Prozesse zurücklässt, oder Prozesse, die den Dienst neu starten und weiter Ärger machen könnten. Probiere es zunächst ohne andere Optionen als den Namen des Dienstes aus und überprüfe dann den Status:
$ sudo systemctl kill mariadb $ systemctl status mariadb ● mariadb.service - MariaDB 10.1.44 database server Loaded: loaded (/lib/systemd/system/mariadb.service; enabled; vendor preset: enabled) Active: inactive (dead) since Sun 2020-06-28 19:57:49 PDT; 6s ago [...]
Der Dienst wurde sauber beendet. Wenn das nicht funktioniert, versuche die nukleare Option:
$ sudo systemctl kill -9 mariadb
Der Legacy-Befehl kill erkennt keine Dienst- oder Befehlsnamen, sondern benötigt die PID des anstößigen Prozesses:
$ sudo kill 1234
Wenn das nicht reicht, wende die nukleare Option an:
$ sudo kill -9 1234
Diskussion
Verwende den Befehl top, um ausufernde Prozesse zu identifizieren. Wenn du ihn ohne Optionen ausführst, werden die Prozesse, die die meisten CPU-Ressourcen verbrauchen, ganz oben aufgelistet. Drücke die Taste q, um top zu beenden.
$ top top - 20:30:13 up 4:24, 6 users, load average: 0.00, 0.03, 0.06 Tasks: 246 total, 1 running, 170 sleeping, 0 stopped, 0 zombie %Cpu(s): 0.4 us, 0.2 sy, 0.0 ni, 99.4 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st KiB Mem : 16071016 total, 7295284 free, 1911276 used, 6864456 buff/cache KiB Swap: 8928604 total, 8928604 free, 0 used. 13505600 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 3504 madmax 20 0 99.844g 177588 88712 S 2.6 1.1 0:08.68 evolution 2081 madmax 20 0 3818636 517756 177744 S 0.7 3.2 5:07.56 firefox 1064 root 20 0 567244 148432 125572 S 0.3 0.9 12:54.75 Xorg 2362 stash 20 0 2997732 230508 145444 S 0.3 1.4 0:40.72 Web Content [...]
kill sendet Signale an Prozesse, und das Standardsignal ist SIGTERM (Signal terminate). SIGTERM ist sanft und ermöglicht ein sauberes Beenden von Prozessen. SIGTERM ist außerdem ignorierbar, d.h. Prozesse müssen es nicht beachten. Signale können durch einen Namen oder eine Nummer identifiziert werden. Die meisten Leute können sich die Nummern leichter merken, deshalb sieht die Standardeinstellung so aus:
$ sudo kill -1 1234
kill -9 ist SIGKILL. SIGKILL stoppt Prozesse sofort und unsauber und versucht auch, alle Kindprozesse zu stoppen.
Das Beenden von Diensten mit systemctl kill ist einfacher als mit kill und zuverlässiger. Du brauchst nur den Namen des Dienstes und musst nicht nach PIDs suchen. Es stellt sicher, dass alle Prozesse, die zu dem Dienst gehören, gestoppt werden, was killnicht gewährleisten kann.
Es gibt eine ganze Reihe von Signalen, die sich im Laufe der Jahre angesammelt haben, und du kannst alles über sie in man 7 signal nachlesen. Meiner Erfahrung nach sind die wichtigsten Signale SIGTERM und SIGKILL, aber das sollte dich nicht davon abhalten, mehr über die anderen zu lernen.
Wenn du dich mit Begriffen wie "töten", "Eltern", "Kinder" und "Waisen" unwohl fühlst, dann geht es mir genauso. Vielleicht wird sich das eines Tages ändern.
Siehe auch
-
man 5 systemd.kill
-
man 1 systemctl
-
Mann 1 töten
-
Mann 7 Signal
4.8 Verwalten von Runleveln mit systemd
Lösung
systemd-Ziele sind ähnlich wie SysV-Runlevels. Dabei handelt es sich um Bootprofile, die dein System mit verschiedenen Optionen starten, z. B. im Mehrbenutzermodus mit grafischem Desktop, im Mehrbenutzermodus ohne grafischen Desktop und im Notfall- und Rettungsmodus, wenn dein aktuelles Ziel nicht bootet. (Weitere Informationen zu Runleveln findest du in der Diskussion).
Der folgende Befehl prüft, ob das System läuft und meldet seinen Zustand:
$ systemctl is-system-running running
Was ist das Standardziel?
$ systemctl get-default graphical.target
Ermittelt den aktuellen Runlevel:
$ runlevel N 5
Starte im Rettungsmodus neu:
$ sudo systemctl rescue
Starte im Notfallmodus neu:
$ sudo systemctl emergency
Starte in den Standardmodus zurück:
$ sudo systemctl reboot
Starte zu einem anderen Ziel, ohne die Standardeinstellungen zu ändern:
$ sudo systemctl isolate multi-user.target
Lege einen anderen Standard-Runlevel fest:
$ sudo systemctl set-default multi-user.target
Liste die Runlevel-Zieldateien und ihre Symlinks auf deinem System auf:
$ ls -l /lib/systemd/system/runlevel*
Liste die Abhängigkeiten in einem Runlevel-Ziel auf:
$ systemctl list-dependencies graphical.target
Diskussion
SysV-Runlevel sind verschiedene Zustände, in die dein System booten kann, z. B. mit einem grafischen Desktop, ohne grafischen Desktop und mit Notfall-Runleveln, die du verwenden kannst, wenn dein Standard-Runlevel Probleme hat und nicht booten kann.
systemd-Ziele entsprechen ungefähr den alten SysV-Runlevels:
-
runlevel0.target, poweroff.target, halt
-
runlevel1.target, rescue.target, Einzelbenutzer-Textmodus, alle lokalen Dateisysteme eingehängt, nur Root-Benutzer, kein Netzwerk
-
runlevel3.target, multi-user.target, Multiuser-Textmodus (keine grafische Umgebung)
-
runlevel5.target, graphical.target, grafischer Mehrbenutzermodus
-
runlevel6.target, reboot.target, reboot
systemctl emergency ist ein spezielles Ziel, das stärker eingeschränkt ist als der Rettungsmodus: keine Dienste, keine anderen Einhängepunkte als das Root-Dateisystem, keine Netzwerke, nur der Root-Benutzer. Es ist das minimalste laufende System für die Fehlersuche bei Problemen. Möglicherweise siehst du auf dem Bildschirm deines GRUB2-Bootloaders Optionen zum Booten in einen Rettungs- oder Notfallmodus.
systemctl is-system-running meldet verschiedene Systemzustände:
-
initialisieren bedeutet, dass das System den Startvorgang noch nicht abgeschlossen hat.
-
starten bedeutet, dass sich das System in der letzten Phase der Inbetriebnahme befindet.
-
läuft, ist voll funktionsfähig und alle Prozesse werden gestartet.
-
degraded bedeutet, dass das System betriebsbereit ist, aber eine oder mehrere systemd-Einheiten fehlgeschlagen sind. Führe systemctl | grep failed aus, um zu sehen, welche Units fehlgeschlagen sind.
-
Wartung bedeutet, dass entweder das Rettungs- oder das Notfallziel aktiv ist.
-
Anhalten bedeutet, dass systemd heruntergefahren wird.
-
offline bedeutet, dass systemd nicht läuft.
-
unbekannt bedeutet, dass es ein Problem gibt, das systemd daran hindert, den betrieblichen Zustand zu bestimmen.
Siehe auch
-
man 1 systemctl
-
man 8 systemd-halt.service
4.9 Diagnose von langsamen Starts
Lösung
Du willst systemd-analyze die Schuld geben. Führe es ohne Optionen aus, um eine Liste der Systemprozesse zu sehen und wie lange sie zum Starten gebraucht haben:
$ systemd-analyze blame
34.590s apt-daily.service
6.782s NetworkManager-wait-online.service
6.181s dev-sda2.device
4.444s systemd-journal-flush.service
3.609s udisks2.service
2.450s snapd.service
[...]
Analysiere nur die Benutzerprozesse:
$ systemd-analyze blame --user
3.991s pulseaudio.service
553ms at-spi-dbus-bus.service
380ms evolution-calendar-factory.service
331ms evolution-addressbook-factory.service
280ms xfce4-notifyd.service
[...]
Diskussion
Es ist nützlich, alle Dienste zu überprüfen, die beim Booten gestartet werden, und vielleicht Dienste zu finden, die nicht beim Booten gestartet werden sollen. Am liebsten deaktiviere ich Bluetooth, weil ich es auf meinen Servern oder PCs nicht benutze, aber viele Linux-Distributionen aktivieren es standardmäßig.
Siehe auch
-
man 1 systemd-analyze
Get Linux Kochbuch, 2. Auflage now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
