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.

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-Verwaltungstools | Kurzbeschreibung | Beispiel |
|---|---|---|
| bootctl | informiert und steuert detailliert die systemd-boot-Methode | bootctl status |
| busctl | kontrolliert, protokolliert die D-Bus-Aktivität (Desktop-Bus) | busctl list |
| homectl | erstellt und verwaltet (portable) Systemd-Homes | homectl create anna |
| hostnamectl | zeigt, ändert Computernamen | hostnamectl set-hostname maxx |
| journalctl | zeigt, filtert, löscht, verkleinert das Systemprotokoll | journalctl –since=14:00 |
| localectl | zeigt, ändert die Systemsprache | localectl set-locale de_DE.UTF-8 |
| loginctl | zeigt, aktiviert, beendet Log-ins und Sessions | loginctl list-sessions |
| networkctl | zeigt, ändert, schaltet Netzwerkadapter, IP- und Mac-Adressen | networkctl down enp2s0 |
| resolvectl | zeigt IP-Adressen zu Domain- und Hostnamen und umgekehrt | resolvectl query fritz.box |
| systemctl | zeigt und ändert alle Systemd-Units (siehe vorigen Artikel) | systemctl status ssh.service |
| timedatectl | zeigt, ändert Zeit und Zeitzone | timedatectl status |
| Systemd-Hilfsprogramme | ||
| systemd-analyze | liefert exakte Zeitmessungen des Systemstarts | systemd-analyze blame |
| systemd-cat | schreibt Output eines Terminalbefehls in das Systemjournal | systemd-cat inxi –sensors |
| systemd-cgtop | zeigt CPU, RAM, I/O von Systemdiensten | systemd-cgtop | grep „user“ |
| systemd-delta | zeigt Abweichungen der Systemd-Konfigurationsdateien vom Standard | systemd-delta –type=masked |
| systemd-mount | zeigt eingebundene Datenträger und bindet sie ein | systemd-mount –list |
| systemd-umount | hängt eingebundene Datenträger aus | systemd-umount /srv/boss |
| systemd-path | detaillierte und kommentierte Systempfade | systemd-path |
| systemd-run | startet interaktiv (temporäre) Dienste, Timer oder Scopes | systemd-run –scope –unit=ff.scope /usr/bin/firefox |
| systemd-tmpfiles | löscht und erstellt temporäre Dateien | systemd-tmpfiles –clean |

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

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.

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.


