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
Das wichtigste Systemd-Werkzeug ist systemctl zur Verwaltung von Diensten. Es bietet gute Kontrolle über manuelle Änderungen.
IDG
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.
Kleine, aber feine Hilfe: Das Tool systemd-delta verschafft schnellen Durchblick bei geänderten Systemdiensten.
IDG
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.
Systemd für Netzwerkabfragen mit networkctl: Hier wie in vielen anderen Belangen macht eine Systemd-Komponente traditionelle Tools weitgehend überflüssig.
IDG
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.
Journald-Protokolle: journalctl zeigt und filtert Information und Fehler, die Systemd beim Start von Diensten aufgezeichnet hat. Einer der zahlreichen Filter ist „priority“, der mit „0“ und „1“ nur noch ernste Probleme liefert.
IDG
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.
Startanalyse mit Systemd: Der Befehl entwickelt sich zum Standard, um die Ursache von Startverzögerungen zu ermitteln. Man muss ihn aber zu lesen wissen, da manche Dienste absichtlich verzögert starten.
IDG
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
Personal Software