Systemd: So kontrollieren Sie Linux-Dienste

Bei großen Linux-Projekten mahlen die Mühlen langsam: Wir denken an das Fenstersystem Wayland oder an Dateisysteme wie BTRFS. Der primäre Init-Dienst Systemd ist auch so ein Kandidat: Er hat sich zwar aufgrund seiner Performanz seit 2010 durchgesetzt und ist heute fast nur noch durch explizite Systemd-Vermeidungsdistributionen wie Devuan (Debian ohne Systemd) oder Antix zu umgehen.

Andererseits befindet er sich weiter in dynamischer Entwicklung und wird laufend durch neue Komponenten erweitert. Das ganze Geflecht der eigentlichen Systemd-Dienste und der jeweils zugehörigen Kommandotools ist schwer zu überblicken und mindestens anstrengend. Grafische Verwaltungswerkzeuge sind in Arbeit, aber aktuell weder Standard noch bequem installierbar. Es führt derzeit kein Weg vorbei, sich zumindest mit den wichtigsten Systemd-Tools im Terminal anzufreunden.

Keine Frage: Ein normaler Desktopnutzer kommt auch ohne intimes Know-how zur Sitzungs- und Diensteverwaltung durchs Leben. Die Systemd-Tools besitzen aber mittlerweile eine umfassende Reichweite bei der allgemeinen Systemverwaltung. Ihr Einsatz ist ratsam und in vielen Fällen den bisherigen Werkzeugen weit überlegen.

Lesetipp: Die 10 wichtigsten Linux-Befehle für Einsteiger

Systemd und die Kernaufgabe

Die Primäraufgabe eines Linux-Init-Systems ist schnell erklärt: Beim Start der Hardware lädt der Bootloader den Linux-Kernel. Der Kernel startet dann eben diesen Init-Prozess vom Pfad „/sbin/init“, der dann die Prozess-ID „1“ erhält. Die Datei „/sbin/ init“ ist entweder direkt die ausführbare Datei oder – wie bei Systemd – ein Link, hier nach „/lib/systemd/systemd“. Der Init-Prozess lädt dann alle erforderlichen Systemdienste. Was es im Einzelnen zu tun gibt, erfährt Systemd unter „/etc/systemd“.

So weit, so einfach (aus Benutzersicht). Nachdem aber Systemd die volle Kontrolle und Übersicht über alle Dienste hat, ist es die logische Konsequenz, dass es auch deren weitere Verwaltung übernehmen muss. Als wichtigste Benutzerschnittstelle dient hierfür das Tool systemctl, das alle Funktionen zum Beenden und Starten von Linux-Diensten besitzt.

Es geht aber weiter: Auch für das Protokollieren von Systemereignissen ist der allererste Prozess der prädestinierte: Dafür gibt es einen sekundären Systemd-Dienst systemd- journald und hier wiederum als Schnittstelle das Tool journalctl.

So geht es munter weiter: Nachgeordnete Systemd-Dienste wie systemd-networkd, systemd-resolved, systemd-timedated (alle mit „d“ am Ende) bieten jeweils die zugehörigen Terminaltools für den Benutzer wie networkctl, resolvectl, timedatectl (typisch mit „ctl“ am Ende).

Den Großteil des Systemd-Personals können Sie daher mit

ls /usr/bin/systemd*
ls /usr/bin/*ctl

besichtigen. Das ist viel genug, dennoch dürfen Sie davon ausgehen, dass Ihre Distribution eine Auswahl trifft und längst nicht alles installiert hat.

Systemctl: Zentrales Tool von Systemd

Systemctl ist das wichtigste Systemd-Werkzeug. Die Syntax folgt – wie bei allen Systemd-Tools – diesem Muster:

systemctl Befehl [--Option]

Einige einfache Systemkommandos wie

systemctl poweroff
systemctl suspend
systemctl rescue

benötigen keine weiteren Optionen, allerdings vorangestelltes „sudo“ wie alle Befehle, die nicht nur einen Status auflisten. Folgendes Beispiel

systemctl list-units --type=service

liefert eine Übersicht über alle laufenden und beendeten Dienste.

Ob hilfreich oder am Ende doch eher verwirrend, liefern folgende Kurzvarianten genau dasselbe Resultat:

systemctl --type=service
systemctl -t service

Dieser Befehl ist nicht weit entfernt vom altgedienten service –status-all, ist aber auch nur ein Vorgeschmack der Möglichkeiten, denn systemctl hat eine wesentlich größere Reichweite. Weitere Unit-Klassen sind „socket“, „device“, mount“, „automount“, „swap“, „target“, „path“, „timer“, „snapshot“, „slice“ und „scope“. Das Kommando ohne weitere Filter

systemctl list-units

oder noch einfacher nur

systemctl

zeigt alle Systemd-Klassen. Für alle Belange der alltäglichen Systemverwaltung werden die Unit-Klassen „service“ und „target“ vorerst genügen. Beachten Sie, dass jede einzelne Unit ihre eigene Konfigurationsdatei besitzt, die mit (Beispiel SSH)

systemctl edit --full ssh.service

bearbeitet werden und folglich auch vom Systembenutzer selbst angelegt werden kann. Beispiele dafür werden Sie in den nachfolgenden Beiträgen finden.

Service-Units: Die wichtigsten Befehle zur Diensteverwaltung lauten wie folgt (hier wieder am Beispiel SSH):

systemctl status ssh.service
systemctl stop ssh.service
systemctl start ssh.service
systemctl restart ssh.service

Diese Kommandos funktionieren auch ohne explizite Unit-Bezeichnung:

systemctl stop ssh

„stop“ und „start,“ oder einfacher „restart“ sind alltägliche Aktionen, wenn ein Dienst wie Apache, SSH oder Samba eine manuelle Konfigurationsänderung neu einlesen soll. Zum dauerhaften Abschalten eines Dienstes gibt es die folgenden Kommandos:

systemctl disable ssh
systemctl mask ssh

„disable“ deaktiviert einen Dienst, verhindert jedoch nicht, dass diesen ein anderer Systemdienst unter der Haube wieder neu aktiviert. Erst der „mask“-Befehl macht auch dieses unmöglich und deaktiviert einen Dienst nachhaltig. Gegebenenfalls kann

systemctl unmask ssh

den Dienst später wieder aktivieren. Diverse Dienste zeigen als Status den Eintrag „static“. Diese lassen sich weder stoppen noch deaktivieren.

Ein Eingriff in Systemdienste, vor allem aber das Abschalten von Diensten ist stets heikel, aber systemctl kann diese nicht nur erledigen, sondern bietet auch gute Kontrolle darüber, was auf dem System verändert wurde. Eine hervorragend lesbare Übersicht mit farbigen Markierungen („disabled“ rot, „enabled“ grün) liefert der folgende Befehl, der nicht die Dienste, sondern die darunterliegenden Konfigurationsdateien abfragt:

systemctl list-unit-files -t service

Zusätzlich zur Farbmarkierung erscheint in der rechten Spalte die Distributionsvorgabe („Vendor Preset“). Somit erkennt man sofort, was am System manuell geändert wurde. Noch umstandsloser filtert die geänderte Konfiguration ein spezielles Systemd-Extratool:

systemd-delta

Dies liefert ausschließlich die vom Systembenutzer geänderten Dienste.

Target-Units: Um alle „targets“ aufzulisten, ist dieser Befehl geeignet:

systemctl --type=target --all

Hier erscheinen dann unter anderem „emergency“, „graphical“, „multi-user“, „rescue“ oder „shutdown“. Systemd-Targets sind eine Neuinterpretation der älteren Runlevels, insofern jedes „target“ seine spezielle Ausstattung von Systemdiensten erhält. Ein prominentes Beispiel ist der Wechsel vom Desktop- zum Serverbetrieb ohne grafische Oberfläche.

Der Befehl

systemctl set-default multi-user.target

schaltet die Oberfläche und die dafür nötigen Dienste ab. Umgekehrt kann

systemctl set-default graphical.target

den Desktop bei Bedarf wieder einschalten. Eine weitere Option ist das „Isolieren“ einer Target-Unit. Das bedeutet nicht weniger als das Abschalten aller Dienste, die für das jeweilige Target nicht benötigt werden, und das fällt natürlich umso dramatischer aus, je reduzierter ein Target ist. Daher gibt es diverse Targets, die solches „Isolieren“ erst gar nicht erlauben. Das Kommando

systemctl isolate rescue

ist eine gravierende Aktion, da sie ohne Umschweife in die Wiederherstellungskonsole führt. Dies beendet nicht nur den grafischen Desktop, sondern auch alle Möglichkeiten einer Remoteanmeldung mit SSH oder VNC.

Linux: Die nützlichsten Hotkeys im Überblick

Weitere Systemd-Werkzeuge

Die nachfolgenden Beispiele beschränken sich auf alltagstaugliche Aufgaben.

1. networkctl

kann (statt ip oder ifconfig) Eigenschaften der Netzwerkadapter anzeigen und steuern. Der Befehl

networkctl

zeigt zunächst nur die Netzwerksschnittstellen. Wenn Sie dort erfahren, dass der Ethernet-Adapter „eth0“ oder „ enp2s0“ heißt, dann erfragen Sie mit

networkctl status enp2s0

alle Parameter von der IP- und MAC-Adresse bis zu MTU, Speed und Gatewayadresse (Router) oder noch ausführlicher mit

networkctl status enp2s0 --stats

die gesendeten und empfangenen Bytes.

2. resolvectl

ist das Kommandotool für den Dienst systemd-resolved und zuständig für die Auflösung von Rechnernamen zu IP-Adressen. Das ältere Tool systemd-resolve (ohne „d“ am Ende) ist aus Kompatibilitätsgründen ebenfalls noch vorhanden, sollte aber vermieden werden, wenn resolvectl vorliegt. Die beiden Varianten machen genau dasselbe, unterscheiden sich aber in der Handhabung. Resolvectl macht diverse Netzwerktools überflüssig:

resolvectl query 192.168.178.1
resolvectl query fritz.box
resolvectl query wikipedia.de

Diese Kommandos liefern den Domain- oder Hostnamen einer IP-Adresse oder umgekehrt die IP-Adresse eines Domain- oder Hostnamens.

3. hostnamectl

Das unscheinbare Kommando zeigt ohne Parameter

hostnamectl

den Hostnamen des Rechners sowie Basisinfos zu System, Kernel und Architektur. Der Befehl

hostnamectl set-hostname mint21

vergibt umstandslos und ohne lästigen Eingriff in Konfigurationsdateien einen neuen Rechnernamen.

4. journalctl

Der Systemd-Dienst journald ist gemeinsam mit seinem Tool journalctl ein präzises Protokollwerkzeug. Da eine ungefilterte Ausgabe des Journals uferlos ausfällt, empfehlen sich Filteroptionen: Die Befehle

journalctl --boot
journalctl --since today

bringen nur die Meldungen seit dem letzten Systemstart beziehungsweise des heutigen Tages. Ebenfalls systematisch ist die Eingrenzung nach Datum oder Zeitangabe

journalctl --since 2022-09-18
journalctl --since 19:00

oder zusätzlich nach einem bestimmten Ereignislevel:

journalctl --priority crit --since 2022-09-18

Priority-Level können durch ein Schlüsselwort oder durch eine Kennziffer übergeben werden: „emerg“ (0), „alert“ (1), „crit“ (2), „err“ (3), „warning“ (4), „notice“ (5), „info“ (6), „debug“ (7). Ein Level kumuliert immer alle Meldungen der niedrigeren Stufen, das heißt: „crit“ (2) präsentiert auch die noch ernsteren Levels 0 und 1.

Mit Schalter „-k“ oder „–dmesg“ filtert das Tool ausschließlich die Kernel-Meldungen und ersetzt somit das Tool dmesg:

journalctl -k --since 19:00

Wer genau weiß, wo er ein Problem zu suchen hat, kann auch gleich nach dem betreffenden Dienst („unit“) eingrenzen. Die Protokollausgabe von

journalctl --unit apache2 --since 2022-09-18

zeigt alle Meldungen des Apache-Servers ab dem angegebenen Datum. Nicht zuletzt kann journalctl den Umfang der Protokollierung begrenzen. Wenn journalctl –diskusage Gigabyte-Tonnen alter Protokolle meldet, können Sie mit

journalctl --vacuum-size=200M
journalctl --vacuum-time=20d

das Journal auf 200 MB reduzieren oder immer auf die Menge der letzten 20 Tage kürzen. Gerade auf Desktopsystemen sind meistens keine monatelangen Protokolle erforderlich.

5. loginctl

Das Tool liefert Informationen über die aktuellen Systemanmeldungen:

sudo loginctl list-sessions

Mit der hier gelieferten Info der Session-ID kann man dann genauer nachfragen:

sudo loginctl session-status 2

Über die Befehle

sudo loginctl lock-session [ID]
sudo loginctl kill-session [ID]

kann eine Anmeldung gesperrt oder gewaltsam beendet werden.

6. systemd-analyze

Dieses Systemd-Werkzeug hat gewisse Popularität erreicht, da es Startprobleme, also Verzögerungen des Systemstarts, präzise offenlegt. Die simpelste Form

systemd-analyze

zeigt nur eine knappe Angabe zur Dauer des Systemstarts, differenziert aber bereits Bios/Firmware, Bootloader, Kernel und Benutzerkonto.

Die Befehle

systemd-analyze blame
systemd-analyze plot > start.svg
systemd-analyze dump > dump.txt

bringen in unterschiedlicher Darstellung die millisekundengenaue Abfolge des Systemstarts, wobei die Option „blame“ für normale Anwender genügen sollte.

7. systemd-path

Wer sich über die geltenden Systempfade und ihre Funktion informieren will, ist mit folgendem einfachen Befehl bestens beraten:

systemd-path

8. systemd-cat

Dieses Tool scheint marginal, kann aber für systematische Systemnotizen ganz nützlich sein. Eigentlich ist Systemdcat ein interner Befehl für Systemd-Dienste, um an das Journal zu berichten. Der Benutzer kann das aber auch manuell tun:

systemd-cat cat /etc/fstab

Hier wird der aktuelle Inhalt der Datei „fstab“ an das Journal angehängt und kann später mit journalctl jederzeit wieder abgefragt werden.

Troubleshooting: Die 20 häufigsten Linux-Probleme lösen