Allgemein | Hermann Apfelböck | 5/2025 | 25. Juli 2025

Die Armee der Systemd-Tools

Das im vorigen Artikel erklärte Tool Systemctl ist das Fundament der Kommunikation mit Systemd. Das Init-System bringt aber inzwischen eine ganze Armee weiterer nutzwertiger Tools mit. Diese sind Gegenstand dieses zweiten Beitrags.

Anfang und Ende einer Startanalyse: Systemd-analyze entwickelt sich zum Standard, um Startverzögerungen von Linux-Systemen zu entlarven.

Das im vorigen Artikel erklärte Tool Systemctl ist das Fundament der Kommunikation mit Systemd. Das Init-System bringt aber inzwischen eine ganze Armee weiterer nutzwertiger Tools mit. Diese sind Gegenstand dieses zweiten Beitrags.

Für eine Einleitung ist kein Platz: Wenn Sie sich unter Debian/Ubuntu mit dem Befehl

dpkg-query -L systemd

über den Umfang von Systemd informieren oder mit

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

direkt auf Dateiebene die einschlägigen Werkzeuge besichtigen, dann sehen Sie, dass es viel zu tun gibt (der zweite Befehl ist nicht ganz präzise und liefert auch einige Systemd-unabhängige Tools). Dieser Artikel erklärt die interessantesten Systemd-Tools. Die meisten fußen auf Systemd-eigenen Diensten, die wiederum mit

systemctl -t service | grep -i "systemd-"

abzufragen sind. So ist etwa das Tool Journalctl auf die Arbeit des Dienstes systemd-journald angewiesen.

Die „*CTL“-Verwaltungstools

Die Unterscheidung in Verwaltungsprogramme mit „ctl“ am Ende des Namens und weiteren Hilfsprogrammen mit „systemd-“ am Beginn ist zumindest für die Verwaltungstools à la Systemctl konsistent (bei Systemd-*-Programmen nicht, weil auch einige Dienste so benannt sind). Wir beschreiben die CTL-Tools weder systematisch noch vollständig, sondern nach ihrem vermutlichen Nutzwert für Desktopnutzer.

Journalctl verwaltet auf Basis des Dienstes systemd-journald die Systemprotokolle. Das scheint langweilig, aber nur so lange Systeme problemlos laufen. Wenn nicht, dann sind die präzisen Filteroptionen von Journalctl ein Segen. Die Befehle

journalctl --boot
journalctl –-since today

liefern nur die Meldungen seit dem letzten Systemstart oder des heutigen Tages. Ebenfalls systematisch ist die Eingrenzung nach einem Systemdatum

journalctl --since 2025-07-18

oder ganz kurzfristig für die letzten Minuten:

journalctl --since 15:00

Um harmlose Ereignislevel wegzufiltern, kann die Ausgabe auf ein bestimmtes Ereignislevel (emerg, alert, crit) reduziert werden:

journalctl –-priority crit –-since today

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 „–dmesg“ filtert das Tool ausschließlich die Kernel-Meldungen und ersetzt somit das Tool dmesg:

journalctl --dmesg --since 19:00

Nicht zuletzt kann journalctl den Umfang der Protokollierung begrenzen. Wenn

journalctl --disk-usage 

Gigabyte-Tonnen alter Protokolle meldet, dann können Sie mit

journalctl --vacuum-size 300M
journalctl --vacuum-time 10d

das Journal dauerhaft auf 300 MB reduzieren oder auf die Protokollmenge der letzten zehn Tage kürzen. Besonders auf Desktopsystemen sind monatelange Protokolle kaum erforderlich.

Networkctl zeigt und steuert alle Eigenschaften der Netzwerkadapter und kann die meisten Leistungen externer Netzwerktools wie ip, ifconfig oder vnstat übernehmen. Die nachfolgenden Aufgaben erledigt das Tool weitgehend ohne den (oft inaktiven) Dienst systemd-networkd, aber eventuell mit notorischer Fehlermeldung. Wen diese stört, sollte diesen Basisdienst mit Systemctl starten. Der Befehl

networkctl [list]

zeigt die Schnittstellen. Für einen dort gemeldeten Ethernet-Adapter „enp2s0“ ermittelt dann

networkctl status enp2s0

alle Parameter von der IP- und MAC-Adresse bis zu MTU, Speed und Gatewayadresse (Router). Noch ausführlicher ist diese Variante:

networkctl status enp2s0 --stats

Hier meldet der Befehl auch die am Adapter gesendeten und empfangenen Bytes („Rx Bytes“ und „Tx Bytes“). Mit den Unterbefehlen „up“ und „down“ schaltet das Tool einen Adapter ein oder aus.

Resolvectl ist das Verwaltungstool auf Basis des Dienstes systemd-resolved und zuständig für die Auflösung von Rechnernamen zu IP-Adressen. Das ältere Tool systemd-resolve ist aus Kompatibilitätsgründen oft 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.

Homectl ist vielversprechend und daher eine Erläuterung wert, obwohl es noch nirgends Standard ist. Aktuelle Distributionen haben nämlich den Basisdienst systemd-homed nicht vorinstalliert. Das gleichnamige Paket ist aber optional nachinstallierbar, wonach homectl verschlüsselte und portable (kopierbare) Home-Verzeichnisse verwalten kann. Systemd-Homes liegen nicht als Verzeichnisse vor, sondern als Images unter „/home“ (theoretisch auch anderswo) und werden bei der Anmeldung des passenden Kontos automatisch in das übliche „/home/[user]“ gemountet. Die Daten kann auch root nicht einsehen. Zum Erstellen eines solchen „Homes“ genügt (Beispiel):

sudo homectl sepp 

Das Konto darf noch nicht existieren: Systemd-Homes können also neben üblichen Homes existieren, aber nicht für ein und dasselbe Systemkonto. Wer ein Systemd-Home mit der Absicht anlegt, dieses später auf andere Systeme zu portieren, sollte dessen Größe mit (Beispiel)

sudo homectl resize sepp 200G

von vornherein sinnvoll dimensionieren, denn homectl erstellt sonst je nach verfügbaren Plattenplatz ein riesiges (leeres) Home-Image, das unnötige Kopiergrößen fordert. Das Benutzerkonto eines solchen Homes wird in aktuellen Distributionen nicht am Anmeldebildschirm auftauchen, muss also dort manuell eingegeben werden. Die weitere Systemnutzung ist dann wie gewohnt.

Das komplette Home liegt als eine einzige Datei „/home/sepp.home“ (Beispiel) vor und kann kopiert und auf ein anderes System übertragen werden. Aus dem Systemd-Konto heraus funktioniert das allerdings nicht: Dieses muss abgemeldet sein und das Konto, das die Kopie erledigt, muss root/sudo-Recht besitzen. Das Zielsystem wiederum muss natürlich systemd-homed installiert haben. Dann genügt dort die Kopie in das Verzeichnis „/home“ und dieser Befehl:

homectl activate

Danach sollte dort die Anmeldung mit dem kopierten Systemd-Konto gelingen.

Hostnamectl ist funktionsarm und zeigt ohne Parameter nur den Hostnamen des Rechners sowie Basisinfos zu System, Kernel und Architektur. Praktisch ist aber dieser Befehl:

hostnamectl set-hostname maxx

Das vergibt umstandslos einen neuen Rechnernamen (hostname).

Loginctl liefert Informationen über die aktuellen Systemanmeldungen:

loginctl [list-sessions]

Mit der hier gelieferten Info der Sessionzahl kann man dann genauer nachfragen (Beispiel):

loginctl session-status 5

Zu den Systemanmeldungen gehört beim Desktopsystem in erster Linie die grafische Oberfläche, zu der es fundamentale Infos wie Anmeldezeit, Benutzerkonto, genutzter Desktop, Displaymanager und Fenstersystem gibt. Anmeldungen auf virtuellen Konsolen oder SSH erscheinen ebenfalls. Über die Befehle

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

kann eine Anmeldung gesperrt oder gewaltsam beendet werden.

Weitere CTL-Verwaltungstools nennen wir nur noch summarisch: Localectl und Timedatectl zeigen die aktuelle Systemsprache sowie Zeit und Zeitzone und können diese auch neu einstellen (Beispiel):

localectl set-locale de_DE.UTF-8

Das Werkzeug Bootctl ist nur aktiv, wenn statt Grub die Bootmethode systemd-boot installiert und verwendet wird. Auf einem Multibootsystem ist von einer Umstellung dringend abzuraten. Systemd-boot ist zwar schneller, aber bislang kaum automatisiert, sodass eine vorherige Multiboot-Umgebung manuell umgestellt werden muss. Systemd-boot vorausgesetzt, zeigt bootctl (ohne Parameter) detailliert alle Infos zum Uefi-Boot, TPM-Chip, Secure Boot und die installierten Systeme inklusive EFI-Datei.

Netzwerkabfragen mit networkctl: Hier wie in vielen anderen Belangen macht ein Systemd-Werkzeug traditionelle Tools weitgehend überflüssig.

Busctl ist ein Tool für das Debugging von D-Bus-Kommunikation (Desktop-Bus) und nur für Anwendungsentwickler relevant. Ähnlich speziell ist Machinectl, das die Installation von systemd-container voraussetzt und dann virtuelle Maschinen (nur KVM) verwaltet.

CTL-VerwaltungstoolsKurzbeschreibungBeispiel
bootctlinformiert und steuert detailliert die systemd-boot-Methodebootctl status
busctlkontrolliert, protokolliert die D-Bus-Aktivität (Desktop-Bus)busctl list
homectlerstellt und verwaltet (portable) Systemd-Homeshomectl create anna
hostnamectlzeigt, ändert Computernamenhostnamectl set-hostname maxx
journalctlzeigt, filtert, löscht, verkleinert das Systemprotokolljournalctl –since=14:00
localectlzeigt, ändert die Systemsprache
localectl set-locale de_DE.UTF-8
loginctlzeigt, aktiviert, beendet Log-ins und Sessionsloginctl list-sessions
networkctlzeigt, ändert, schaltet Netzwerkadapter, IP- und Mac-Adressennetworkctl down enp2s0
resolvectlzeigt IP-Adressen zu Domain- und Hostnamen und umgekehrtresolvectl query fritz.box
systemctlzeigt und ändert alle Systemd-Units (siehe vorigen Artikel)systemctl status ssh.service
timedatectlzeigt, ändert Zeit und Zeitzonetimedatectl status
Systemd-Hilfsprogramme
systemd-analyzeliefert exakte Zeitmessungen des Systemstartssystemd-analyze blame
systemd-catschreibt Output eines Terminalbefehls in das Systemjournalsystemd-cat inxi –sensors
systemd-cgtopzeigt CPU, RAM, I/O von Systemdienstensystemd-cgtop | grep „user“
systemd-deltazeigt Abweichungen der Systemd-Konfigurationsdateien
vom Standard
systemd-delta –type=masked
systemd-mountzeigt eingebundene Datenträger und bindet sie ein systemd-mount –list
systemd-umounthängt eingebundene Datenträger aussystemd-umount /srv/boss
systemd-pathdetaillierte und kommentierte Systempfadesystemd-path
systemd-runstartet interaktiv (temporäre) Dienste, Timer oder Scopessystemd-run –scope –unit=ff.scope /usr/bin/firefox
systemd-tmpfileslöscht und erstellt temporäre Dateiensystemd-tmpfiles –clean
Nicht intuitiv, aber spannend: Systemd-homed und sein Tool homectl erstellen verschlüsselte Home-Container, die bei der Benutzeranmeldung (mit Systemd-Konto) entsperrt und geladen werden.

Die „Systemd-*“-Hilfsprogramme

Diese Tools haben nicht annähernd den Funktionsumfang der größeren CTL-Verwaltungsprogramme. Kennen sollte man sie trotzdem: Besonders die zuerst genannten sind auf jedem Linux-Desktop nützlich.

Systemd-analyze hat gewisse Popularität erreicht, da es Startprobleme und Verzögerungen des Systemstarts offenlegt. Da Systemd die Startzeiten des Systems selbst protokolliert, bietet das Tool die präziseste Kontrolle. 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. Die Ausgabe als SVG-Diagramm kann mit jedem Browser gelesen werden.

Das Tool legt aber auch Fehler offen. Nach

systemd-analyze verify /etc/systemd/system/*.service

erscheinen abgeschaltete Dienste („masked“) sowie Konfigurationsfehler in „Override“-Anpassungen.

Systemd-run ist das Werkzeug, um temporär beliebige Programme zu laden, die dann innerhalb der Systemd-Verwaltung laufen und deren Steuerung gehorchen. Ein Beispiel, um ein grafisches Programm als Scope-Unit anzulegen, hat bereits der vorherige Beitrag gezeigt:

systemd-run --scope --unit=ff.scope /usr/bin/firefox

Danach ist der Prozess über die Optionen von Systemctl steuerbar. Es geht aber auch direkter, sofern es sich um ein Script oder um ein Hintergrundprogramm handelt: Dann kann vorab einfach die gewünschte Eigenschaft definiert werden:

systemd-run --property=CPUQuota=5% /usr/bin/updatedb

Das bedeutet, dass die Indexaktualisierung für das Suchprogramm Locate nur minimale Systemlast (5 Prozent) erzeugen soll. Terminalprogramme mit sichtbarer Ausgabe benötigen ein Pseudoterminal („–pty“):

systemd-run --pty --property=MemoryMax=2M htop
Beispiel für systemd-run: Das ist vor allem für größere Terminalroutinen (hier rsync) eine coole Methode, den Ressourcenbedarf zu steuern.

Systemd-mount kann bekannte Werkzeuge wie lsblk und blkid, im Prinzip auch mount weitgehend ersetzen. Der Befehl

systemd-mount -list

zeigt alle Datenträger inklusive UUID, Label, Dateisystem. Die Mountpfade zeigt es allerdings nur, wenn Laufwerke mit systemd-mount eingehängt wurden. Für aktives Mounten mit systemd-mount gibt es zahlreiche Optionen ähnlich dem klassischen mount, wobei aber auch einfachste Varianten funktionieren:

systemd-mount /dev/sdb1 /mnt/usb4TB

Für das Aushängen muss dann der Befehl systemd-umount

systemd-umount /mnt/usb4TB

genutzt werden, weil das klassische
umount die so eingehängten Datenträger nicht kennt.

Systemd-cgtop ist der Prozessmonitor von Systemd, der den Verbrauch von Systemd-Control-Groups zusammenfasst, also den Ressourcenverbrauch von „User“- und „System“-Units. Einzelne Anwendungsprogramme erscheinen hier nicht. Die Sortierung nach CPU, RAM, IO-Last lässt sich per Parameter ebenso steuern wie das Updateintervall. Ohne Parameter gestartet

systemd-cgtop

sortiert das Tool nach CPU-Last. Relevant ist solche Kontrolle praktisch nur auf Linux-Servern, wo die Lastverteilung zugunsten eines Serverdienstes optimiert werden soll. Wie das mit „systemctl set-property“ oder durch Editieren von Unit-Dateien erfolgt, ist im vorangehenden Beitrag skizziert.

Systemd-delta ist hauptsächlich für Admins relevant, die tief in der Systemd-Konfiguration stecken und eigene Units erstellt oder Anpassungen vorgenommen haben. Der Befehl

systemd-delta

liefert einen detaillierten Überblick über abgeschaltete Units („masked“), originale Zustände („equivalent“) und sämtliche Konfigurationsänderungen („overridden“) . Die Anzeige abgeschalteter Units kann auch für normale Desktopnutzer relevant sein, die zwar keine Dienste geändert, aber mit systemctl mask […] abgeschaltet haben.

Weitere Systemd-Hilfsprogramme sind ganz unscheinbare kleine Systemtools wie Systemd-path. Der einfache Befehl

systemd-path

kennt keine weiteren Schalter und liefert eine detaillierte Übersicht über allgemeine Systemordner und spezielle Systemd-Pfade. Ein weiteres Minitool Systemd-cat kann für Systemnotizen nützlich sein. Eigentlich ist systemd-cat 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. Hierbei kann man sogar mit Schalter „-p“ Priority-Levels (0 bis 7) mitgeben. Ebenfalls eher marginal ist Systemd-tmpfiles, das mit dem Schalter „-clean“ einige temporäre Dateien beseitigt.

Kleiner, feiner Helfer: Systemd-delta verschafft Durchblick bei geänderten Systemdiensten.

Grafische Hilfen für Systemd

Für Systemd gibt es kaum grafische Unterstützung, weil Entwickler solcher Werkzeuge der dynamischen Systemd-Entwicklung kaum nachkommen und sehr tief in der Materie stecken müssen. So ist etwa die Gnome-Erweiterung „Systemd Manager“ nicht mehr kompatibel mit aktuellen Gnome-Versionen. Das Terminaltool chkservice, das immerhin eine quasi-grafische Steuerung aller Units anbietet, beschränkt sich derzeit auf die Anzeige und verweigert die prinzipiell vorgesehenen Abschaltoptionen.

Aktuell ist nur das Administrationswerkzeug Cockpit (gleichnamiger Paketname) zu empfehlen, das allerdings kein Desktop- oder Terminalprogramm ist, sondern ein Webserver-Dienst, der standardmäßig über Port 9090 (also [IP-Adresse]:9090) im Browser genutzt wird. Cockpit bietet unter „Dienste“ eine Verwaltung von Systemd-Units. Der Punkt „Dienste“ ist nicht ganz logisch, denn er führt zu „Dienste“, „Ziele“ (targets), „Sockets“, „Timer“ und „Pfade“ (paths). Alle diese Systemd-Units sind hier aufgelistet, gut kontrollierbar (inklusive Beziehungen) und grundlegend zu steuern (Stop, Start, Mask). Eingriffe in die Unit-Dateien und somit Änderungen an den Eigenschaften sind aber nicht möglich.

Cockpit zeigt Systemd-Units: Der Cockpit-Webserver ist aktuell eine der ganz wenigen grafischen Hilfen, um Systemd-Dienste per Klick starten und beenden zu können.