Systemctl ist das wichtigste Werkzeug zur Kontrolle und Steuerung des Linux-Dienstes Systemd – aber nur eines von vielen. Der Funktionsumfang dieser Tools ist so beeindruckend (und anstrengend) wie der generelle Allmachtsanspruch von Systemd. Der primäre Init-Daemon Systemd herrscht über alle weiteren Systemprozesse und hält für den Benutzer eine ganze Palette von Tools bereit, wie die nachfolgende Liste zeigt:

Eine nähere Auseinandersetzung mit systemd und seinen Steuerungsprogrammen ist mittlerweile alles andere als ein Nischenthema, nachdem fast alle namhaften Linux-Distributionen systemd verwenden, unter anderen Arch, Debian, Fedora (und Red Hat Enterprise sowie Cent OS), Mageia, Mandriva, Opensuse (und Suse Enterprise), Siduction, insbesondere aber auch Ubuntu mit sämtlichen Derivaten (wie Mint, Peppermint, Chromium, Netrunner, Bodhi, Elementary, Zorin…). Dieser Init-Prozess systemd ist allerdings ein Kosmos für sich – ein logischer, aber hochkomplexer mit Allmachtsanspruch, und dabei reichlich verkopft. Von den uferlosen Kommandos und Optionen werden selbst professionelle Administratoren kaum 10 Prozent im Alltag benötigen und höchstens fünf Prozent verinnerlichen. Natürlich ist das gesamte Potential ein Fall für das Terminal, wobei Infobefehle in der Regel mit Benutzerrecht arbeiten, Änderungen jedoch „sudo“ erfordern. Grafische Frontends wenigstens für die allerwichtigsten Funktionen sind in Arbeit, aber bislang ist keines über die Beta-Phase hinausgekommen, weswegen wir dazu auch keine Empfehlung abgeben.

Systemd-Werkzeuge: Eine Übersicht

Der einfachste und fast alternativlose Weg, sich über den enormen Toolbestand von systemd zu informieren, ist der Blick in das Gesamtpaket:

dpkg-query -L systemd

Neben systemctl treffen Sie hier auf eine Armee von Hilfsprogrammen. Die man-Pages aller systemd-Werkzeuge könnten mühelos eine komplette LinuxWelt füllen – und dabei ist Vieles noch unzureichend kommentiert. Die nachfolgenden Beispiele beschränken sich auf wenige alltagstaugliche Aufgaben.

networkctl

zeigt zunächst nur die Netzwerksschnittstellen. Wenn Sie dort erfahren, dass der Ethernetadapter „eth0″ oder “ enp2s0″ heisst, dann erfragen Sie mit

networkctl status enp2s0

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

networkctl status enp2s0 --stats

zusätzlich die gesendeten und empfangenen Bytes. Das eher funktionsarme Kommando hostnamectl zeigt ohne Parameter

hostnamectl

den Hostnamen des Rechners sowie auch einige Basisinfos zu System, Kernel und Architektur. Mit dem Befehl

hostnamectl set-hostname bolide

vergeben Sie umstandslos einen neuen Rechnernamen.

Journalctl:  Dieses Tool ist ein sehr präzises Werkzeug, um das Systemprotokoll zu zeigen, zu filtern und zu bearbeiten. Da eine ungefilterte Ausgabe des Journals uferlos ausfällt, eignen sich zur Analyse folgende Filteroptionen: Die Befehle

journalctl --boot

journalctl --since today

bringt nur die Meldungen seit dem letzten Systemstart beziehungsweise die des heutigen Tages. Nach journalctl –list-boots kann auch jede beliebige Boot-ID mit journalctl –boot [ID] abgefragt werden. Ebenfalls systematisch ist die Eingrenzung nach einem Systemdatum

journalctl --since "2020-09-18"

oder zusätzlich nach einem bestimmten Ereignislevel:

journalctl --priority "crit" --since
"2020-09-18"

Priority-Level wie hier („crit“) können durch ein Schlüsselwort oder durch eine Kennziffer übergeben: „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 Level 0 und 1.

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.service --since
"2020-08-01"

zeigt alle Meldungen des Apache-Servers ab dem angegebenen Datum.

Nicht zuletzt kann journalctl den Umfang der Systemprotokollierung steuern. Mit

journalctl --disk-usage

fragen Sie die den aktuellen Umfang ab. Befehle wie

journalctl --vacuum-size=300M

journalctl --vacuum-time=30d

können das Journal auf 300 MB reduzieren oder auf die Aufzeichnung der letzten 30 Tage kürzen. Wer dies nicht manuell erledigen will, kann auch die /etc/systemd/journald.conf ändern, um ein solches Limit dauerhaft einzustellen.

Homectl: Dieses hochkomplexe Tool ist ein großes Versprechen, weil es das Home-Verzeichnis portabel macht und etwa auf einem USB-Laufwerk einrichtet:

homectl create linux --real-name="Linux Welt"
--image-path=/dev/disk/by-id/usb-WD_My_Passport_476fff954b2b5c44-0:0

Solche Homes können dann nach Bedarf am System ein- und ausgehängt werden. Alle Probleme bei Dateisystemen und Benutzerrechten sind aber offenbar noch nicht gelöst, sodass homectl derzeit noch auf den allermeisten Distributionen fehlt.

Weitere Beispiele: Ein weiteres systemd-Werkzeug hat gewisse Popularität erreicht, da es Startprobleme, also Verzögerungen des Systemstarts, in aller Präzision offenlegt. Die simpelste Form („time“ kann auch entfallen)

systemd-analyze time

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 mindestens die Option „dump“ über das Informationsbedürfnis normaler Anwender deutlich hinausgeht.

Wer sich über die geltenden Systempfade und ihre Funktion informieren will, ist mit dem einfachen Befehl

systemd-path

bestens beraten. Eine ebenfalls vergleichsweise einfache Funktion erfüllt dieses Kommando (Beispiel):

systemd-cat lsblk

Eigentlich ist systemd-cat ein interner Befehl für systemd-Dienste, um an das Systemjournal zu berichten. Der Benutzer kann dies aber auch manuell tun: Die Befehlsausgabe von lsblk würde hier an das Journal angehängt und kann mit journalctl jederzeit wieder abgefragt werden.

Basis-Kommandos von Systemctl

Systemctl ist aktuell das wichtigste und mächtigste Werkzeug von systemd. Die lehrbuchmäßige Syntax folgt – wie bei allen systemd-Tools – diesem Muster:

systemctl Befehl [--Option]

Einige besonders einfache, aber nützliche Systemkommandos wie

systemctl poweroff 

systemctl suspend

systemctl rescue

benötigen keine weiteren Optionen. Typischer ist folgendes konkrete Beispiel:

systemctl list-units --type=service

Dies liefert eine Übersicht der laufenden und beendeten Dienste. Dieser Befehl ist nicht so weit entfernt vom altgedienten service –status-all, ist aber auch nur ein Vorgeschmack der Möglichkeiten. Der Filter „–type=service“ zeigt schon, dass systemctl eine wesentlich größere Reichweite hat. Weitere „unit“-Klassen sind „socket“, „device“, mount“, „automount“, „swap“, „target“, „path“, „timer“, „snapshot“, „slice“ und „scope“. Das Kommando ohne weitere Filter

systemctl list-units

zeigt alle Systemd-Klassen. Wir müssen uns im Folgenden auf wenige Beispiele zur Dienste-, Target- und Timer-Verwaltung beschränken. Beachten Sie, dass jede einzelne Unit ihre eigene Konfigurationsdatei besitzt, die mit

systemctl edit --full [unit.name]

bearbeitet werden und folglich auch vom Systembenutzer selbst angelegt werden kann.

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

systemctl list-units --type=target --state=loaded

Hier tauchen dann unter anderem „emergency“ oder „rescue“ als inaktive „targets“ auf. Das Kommando

systemctl isolate rescue.target

ist eine gravierende Aktion, da sie ohne Umschweife in die Wiederherstellungskonsole führt und „isolate“ alles beendet, was für das angeforderte „target“-Ziel nicht benötigt wird. Ein weiterer praxisnaher Einsatz von systemd-„targets“ ist der Wechsel vom Desktop- zum Serverbetrieb. Wenn ein Desktop läuft (multi-user.target), aber auf einem Server unnötig ist, dann schaltet

systemctl set-default multi-user.target

die Oberfläche ab und spart damit viel Ressourcen. Der Befehl

systemctl set-default graphical.target

kann den Desktop wieder einschalten.

Service-Units: Die wichtigsten Befehle zur Diensteverwaltung lauten wie folgt:

systemctl status [name].service

systemctl stop [name].service

systemctl start [name].service

systemctl restart [name].service

Diese Kommandos, angewandt etwa konkret auf den Dienst ssh.service, sind weitgehend selbsterklärend. „stop“ und „start,“ oder einfacher „restart“ sind häufig erforderlich, wenn der betreffende Dienst eine Konfigurationsänderung neu einlesen und berücksichtigen soll. Zum nachhaltigen Beenden eines Dienstes ist diese Abfolge einzuhalten:

systemctl stop [name].service

systemctl disable [name].service

systemctl mask [name].service

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

systemctl unmask [name].service

den Dienst wieder zugänglich machen.

Diverse Dienste zeigen als Status den Eintrag „static“. Diese lassen sich weder stoppen noch deaktivieren. In dieser LinuxWelt finden Sie im Special „Linux in Tabellen“ auch eine Tabelle mit den typischen Linux-Diensten: Die knappe Übersicht informiert, welche Dienste eventuell entbehrlich sind.

Eingriffe in die Systemdienste sind immer heikel, aber systemctl kann diese nicht nur erledigen, sondern bietet auch gute Kontrolle. Eine hervorragend lesbare Übersicht mit farbigen Markierungen („disabled“ rot, „enabled“ grün) zeigt dieser Befehl, der nicht die Dienste, sondern die darunterliegenden Konfigurationsdateien abfragt:

systemctl list-unit-files --type=service

Zusätzlich zur Farbmarkierung erscheint in der rechten Spalte die Distributionsvorgabe („Vendor Preset“). Somit erkennt man sofort, was am System nachträglich geändert wurde.

Timer-Units: Systemd ist auf dem Weg, zahlreiche alte Zöpfe abzuschneiden. Dienste, Netzwerk, Geräte, Umgebungsvariablen, Mount-Aktionen sind ebenso betroffen wie die alten Cronjobs, denn systemd kann auch zeitgesteuerte Aufgaben übernehmen („timer“). Ganz trivial ist das allerdings nicht, denn damit steckt man mitten in der systemd-Verwaltung. Der Aufbau einer Timer-Unit sieht etwa so aus:

• [Unit]
• Description=Backup
• [Timer]
• OnCalendar=10:00
• [Install]
• WantedBy=basic.target

Die Zeitsteuerung geschieht im Abschnitt “Timer”. Die Beispieleinträge bedeuten, dass der Job „Mein Backup“ täglich um 10 Uhr ausgeführt wird, und die Install-Sektion stellt mit „basic.target“ klar, dass der Job immer ausgeführt werden soll. Nun muss aber unter /etc/systemd/system für jede Timer-Unit (etwa fstrim.timer) eine gleichlautende Service-Unit existieren (fstrim.service). Diese Datei enthält dann als „ExecStart=…“ das Kommando oder Script, das periodisch ausgeführt werden sollen. Diese Datei könnte dann so aussehen:

• [Unit]
• Description=Backup
• [Service]
• ExecStart=/home/lw/backup.sh

Um einen so definierten Timer interaktiv zu laden, hilft wieder systemctl:

systemctl start backup.timer

Der weitere Befehl

systemctl enable backup.timer

aktiviert die neue Timer-Unit dauerhaft.