In den meisten aktuellen Linux-Distributionen arbeitet Systemd als primärer Prozess mit der PID „1“ als Boss aller nachfolgenden Systemdienste. Dieser Heftschwerpunkt erläutert Werkzeuge und Techniken dieses Init-Prozesses mit umfassendem Anspruch.

Der Init-Daemon Systemd

Die Reichweite des Systemd-Konzepts und die damit einhergehenden Chancen einer Standardisierung von Linux-Systemen sind unbestritten. Systemd hat aber Vorgänger wie Sysvinit und Upstart als Init-Daemon insbesondere deshalb abgelöst, weil er durch Parallelisierung der frühen Startprozesse für schnellere Bootzeiten sorgt. Die Aufgabe des Init-Prozesses ist schnell erklärt: Beim Start der Hardware lädt der Bootloader den Linux-Kernel. Der Kernel startet dann den Init-Prozess aus dem Pfad /sbin/init, der die Prozess-ID „1“ erhält. Welches Init-System bei einer Linux-Distribution aktiv ist, erfahren Sie daher am einfachsten durch eine Frage nach Prozess „1“:

cat /proc/1/comm

Die Ausgabe wird in der Regel „systemd“ lauten. Dieser Init-Prozess lädt dann alle erforderlichen Systemdienste, Dateisysteme, Timer. Nachdem Systemd die volle Kontrolle und Übersicht hat, ist es die logische Konsequenz, dass es deren Verwaltung übernehmen muss. Und das macht Systemd umfassend und gründlich. Als wichtigste Benutzerschnittstelle dient das Tool Systemctl, um das es in diesem ersten Artikel ausschließlich gehen soll. Es öffnet nämlich den Zugang zum kompletten Systemd-Kosmos mit seinen diversen Unit-Klassen.

Systemctl und die Systemd-Units

Systemctl wird oft als „Dienste-Manager“ bezeichnet. Das ist zwar wahrscheinlich der häufigste Einsatzzweck, unterschlägt aber, dass Systemctl sämtliche Systemd-Units verwaltet. Dienste, also die Klasse „Service“, ist nur eine dieser Klassen (siehe Tabelle “ Systemd: Die Unit-Klassen“). Das Kommando

systemctl

ohne weitere Filter ist eine Abkürzung für

systemctl list-units

und zeigt alle aktuell aktiven Systemd-Units. In der Regel wird man die Liste zwecks besserer Übersicht auf eine bestimmte Unit-Klasse wie „service“ filtern. Ob hilfreich oder am Ende doch eher verwirrend, liefern alle folgenden Syntaxvarianten exakt dasselbe Resultat:

systemctl list-units --type=service
systemctl --type=service
systemctl -t service

Das Ergebnis ist die Prozessliste aller aktuell geladenen Systemdienste.

Eine anders geartete Abfrage richtet sich an die Systemd-Konfigurationsdateien. Der Befehl

systemctl list-unit-files -t service

liefert sämtliche Dienstekonfigurationen aus, die auf dem System vorliegen. Das ist vor allem relevant, um eine schnelle Übersicht über Änderungen aller Art zu ermitteln. Abgeschaltete oder ganz deaktivierte Units erscheinen hier nämlich mit roter Signalfarbe als „disabled“ oder „masked“. Wenn man will, kann man nach solchen Units mit

systemctl list-unit-files -t service –-state=disabled

oder „—state=masked“ noch zielgenauer fahnden.

Unit-„Properties“ anzeigen und steuern

Systemctl kann Units nicht nur anzeigen, starten und stoppen (siehe unten), sondern auch im Detail verändern und umkonfigurieren. Der Unterbefehl „show“ von systemctl (Beispiel)

systemctl show ssh.service

zeigt alle Eigenschaften der angesprochenen Unit – zumeist ziemlich viele, sodass sich oft eine Sortierung (sort) oder ein Grep-Filter empfiehlt:

systemctl show ssh.service | grep -i "cpu"

Der aktive Befehl (Beispiel)

systemctl set-property ssh.service CPUWeight=20

kann dann die Eigenschaften interaktiv und für die laufende Sitzung ändern. Ein weiteres Beispiel für Ressourcensteuerung ist unten im Abschnitt „Die Slice-Units“ skizziert. Neben der dort gezeigten CPU-Begrenzung mit „CPUQuota=20%“ gibt es weitere interessante Eigenschaften wie „MemoryMax=500M“ (Limitierung von Services oder Slices) oder „IOWeight=500“ (Standard ist „100“, Maximum ist „1000“ – relevant etwa für die Webserver-Optimierung).

„Property“-Änderungen dauerhaft speichern: Eingriffe mit systemctl set-property gelten sofort, allerdings nur bis zum nächsten Neustart des Dienstes oder des Systems (transient). Dauerhafte Einstellungen benötigen ein korrigierendes „Drop-In-File“. Diese Dateien haben den Vorteil, dass die Originale unter /usr/lib/systemd/system/ stets unverändert bleiben (wichtig bei Systemupdates). Erfreulicherweise muss man sich um den korrekten Namen und Speicherort solcher Dateien nicht kümmern, weil systemctl das nach (Beispiel)

sudo systemctl edit user.slice

selbst am besten weiß. Vorbereitend ist es aber immer zu empfehlen, vorher die gewünschte Änderung mit systemctl set-property interaktiv zu testen. Dabei werden nämlich falsch geschriebene Properties oder ungültige Werteangaben automatisch abgelehnt. Korrekte, interaktiv angeforderte Änderungen erscheinen hingegen am Ende der Datei, die man danach mit systemctl edit öffnet. Die Property-Angabe am Dateiende kann man aber nicht einfach (und naheliegend) durch Entfernen des Kommentarzeichens (#) aktiv schalten. Sie muss vielmehr nach oben in Zeile 3 oder 4 kopiert werden – vor die Zeile „Edits below […] will be discarded“.

Nach dem Speichern der Datei, die dann /etc/systemd/system/[name].d/override.conf lauten wird, kann die Aktion mit

sudo systemctl daemon-reload
sudo systemctl restart [Name].service

permanent gesetzt werden – dies zumindest für Service- oder Timer-Units. Für andere Units ist ein Neustart erforderlich.

Die Unit-Klasse „Service“

An der Verwaltung mit Systemdiensten kommt kein Linux-Nutzer vorbei, der zumindest den einen oder anderen Netzwerkdienst wie SSH oder Apache laufen hat. Die wichtigsten Befehle lauten wie folgt (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 an sich dauerhaft, verhindert aber nicht, dass diesen ein anderer Systemdienst unter der Haube neu aktiviert. Erst der „mask“-Befehl macht auch dieses unmöglich und deaktiviert einen Dienst nachhaltig. Dies kann bei Bedarf nur der Systemadministrator (also Sie) mit

systemctl unmask ssh
systemctl start ssh

wieder rückgängig machen.

Ein Eingriff in Systemdienste, vor allem aber das Abschalten von Diensten ist stets heikel, aber systemctl kann das nicht nur erledigen, sondern bietet auch gute Kontrolle darüber, was auf dem System verändert wurde. Eine gut 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 als „Preset“ oder „Vendor Preset“. Somit erkennt man die Vorgaben der Distribution und was am System manuell geändert wurde. Beachten Sie bei dieser Ausgabe der Unit-Dateien auch den Status-Eintrag „static“. Die damit ausgezeichneten Dienste sind systemrelevant und lassen sich nicht deaktivieren.

Die Unit-Klasse „Target“

Systemd-Targets sind keine aktiven Prozesse, sondern definierte Sammlungen von Device-, Service-, Mount-, Path- und Timer-Units, die dann in der Summe einen bestimmten Systemzustand erzielen. Dieser Zustand kann maximal (graphical.target) oder minimal ausfallen (etwa rescue.target). Solche Unit-Kombinationen kann man mit einem einzigen Kommando neu definieren oder ab dem nächsten Systemstart als Standard vorgeben.

Um alle vordefinierten Targets aufzulisten, ist dieser Befehl geeignet:

systemctl -t target

Hier erscheinen dann unter anderem „basic“, „emergency“, „graphical“, „multi-user“, „rescue“ oder „shutdown“. Welche Unit-Sammlung ein Target konkret enthält, ist auf Dateiebene (/lib/systemd/system) schwer zu ermitteln, weil Target-Konfigurationsdateien nur die speziellen Units des Targets direkt auflisten und ansonsten auf integrierte Targets verweisen. Der Befehl

systemctl list-dependencies basic.target

macht das anschaulicher.

Der praktische Einsatz dieser Targets sieht so aus, dass man mit einem einzigen „isolate“-Befehl alles abschalten kann, was nicht in der Unit-Sammlung des angesprochenen Targets enthalten ist. Der am Desktop gestartete Befehl

sudo systemctl isolate rescue.target

führt sofort in die Wiederherstellungskonsole. Was immer am System läuft oder noch nicht gespeichert ist, wird weggeschossen. Zurück zur Anmeldung geht’s mit Strg-D (Abbruch der Konsole) oder mit diesem Befehl:

sudo systemctl isolate graphical.target

Die Aktion „isolate“ ist nicht für jedes Target erlaubt. Verantwortlich dafür ist die Eigenschaft „AllowIsolate“ der Target-Unit.

Dauerhaftes Umschalten: Was der Unterbefehl „isolate“ interaktiv ausführt, kann „set-default“ ab dem nächsten Systemstart dauerhaft als Standard setzen. Dafür kommen aber nur zwei Targets ernsthaft in Betracht – das umfangreichste „graphical.target“ und das Target „multi-user.target“ für Server ohne Desktop. Der Wechsel dieser beiden Targets ist vor allem für Platinenrechner interessant. Dort ist es typisch, dass der Desktop zwar zur ersten Einrichtung willkommen, danach aber überflüssig ist. Wer nur noch die Serverdienste braucht (Samba, SSH, Apache), kann mit

sudo systemctl set-default multi-user.target

die Oberfläche abschalten. Mit

sudo systemctl set-default graphical.target

ist der Desktop bei Bedarf wieder zu aktivieren.

Achtung: Anders als bei „isolate“ ist Systemd beim Setzen des Default-Targets indifferent. Wenn Sie mit

sudo systemctl set-default rescue.target

die Wiederherstellungskonsole zum Systemstandard machen, sehen Sie den Desktop erst mal nicht wieder, solange Sie auf der Notfallkonsole nicht wieder das „graphical.target“ als Standard setzen. Auch destruktive Aktionen sind nicht untersagt. Nach

sudo systemctl set-default basic.target

geht gar nichts mehr. Aber da das Grub-Menü über „Erweiterte Optionen“ und den „Recovery Mode“ das rescue.target einschalten kann, gibt es von hier über die root-Konsole und

systemctl set-default graphical.target

wieder einen Weg zurück.

Die Unit-Klasse „Slice“

Slices sind Sammlungen aktiver Prozesse, die zu einer Verwaltungseinheit gebündelt werden (auf der Basis von Linux-Control-Groups). Das klingt verkopft, eröffnet aber in der Praxis großes Optimierungspotential. Die Nachfrage mit

systemctl -t slice

wird eine Reihe von Slice-Units anzeigen, unter anderem je eine Slice („Scheibe“) für jedes Benutzerkonto. Die Eigenschaften sind dann wie auch sonst mit

systemctl show user-1000.slice

zu erfragen. Daher können Ressourcenlimits auf Slice-Ebene gesetzt werden, die alle darin enthaltenen Prozesse begrenzen:

sudo systemctl set-property user-1000.slice CPUQuota=20%

Der Befehl muss tatsächlich so lauten, obwohl die Eigenschaft eigentlich „CPUQuotaPerSecUSec“ heißt. Auf einem Serversystem mit bescheidener Hardware könnte man daher nicht nur einen einzelnen Benutzer, sondern die komplette User-Scheibe mit

sudo systemctl set-property user.slice CPUQuota=20%

deutlich limitieren, um die Systemdienste zu priorisieren.

Die Unit-Klasse „Scope“

Die Klasse der Scopes („Erweiterungen“) ist technisch interessant, aber für die meisten Nutzer wahrscheinlich zu akademisch. Es geht darum, beliebige externe Programme (etwa Browser oder Bildbearbeitung) in die Systemd-Verwaltung zu integrieren. Das ist nur interaktiv und temporär während einer Sitzung möglich und benötigt den Befehl systemd-run. Der gehört eigentlich in den nachfolgenden Beitrag („Die Armee der Systemd-Tools“), ist aber hier notwendig, um die Scope-Klasse zu erklären. Nachdem eine temporäre Scope-Unit mit

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

erstellt ist, lassen sich

systemctl show ff.scope

die Eigenschaften wie bei Systemd-Prozessen abfragen und mit

systemctl set-property ff.scope MemoryLimit=400M

auch nach Bedarf steuern.

Weitere Units: Timer, Path & mehr

Systemd kennt eine Reihe weiterer Unit-Klassen wie Device, Mount, Path, Timer, Snapshot, Socket. Praxisrelevante Optionen dazu kommen im dritten Beitrag dieses Specials noch zu Wort. Dieser Artikel zeigt Beispiele, wie man eigene Dienste anlegt und wie die dafür nötigen Konfigurationsdateien strukturiert sind. Für Anwender kaum ergiebig sind die Klassen Device, Snapshot und Swap. Für Swap (Auslagerungsdatei) bleibt Systemctl auf die übliche „status“-Abfrage mit

systemctl status swapfile.swap

beschränkt, die Pfad und aktuelle/maximale Größe der Datei anzeigt, ferner kann mit

sudo systemctl stop swapfile.swap

das Swapping interaktiv abgeschaltet, mit „start“ wieder aktiviert werden. Weitere Zugriffe mit „enable“ und „disable“ (dauerhaft abschalten) funktionieren auf vielen Systemen nicht.

Die Unit-Klasse Snapshot fehlt bei der Mehrzahl der Distributionen. Es handelt sich um eine interne Systemd-Sicherungsfunktion (etwa sudo systemctl snapshot 2025_Juni), die den aktuellen Systemd-Zustand speichert und später mit „isolate“ restaurieren kann.

Systemd: Die Unit-Klassen
Automount (*.automount)	dynamische Dateisystem-Mounts
Device (*.device)	Vermittlungsschicht zwischen Hardware und Systemd
Mount (*.mount)	statische Dateisystem-Mounts
Path (*.path)	Ordnerüberwachung
Scope (*.scope)	Anwendungsprogramme als Systemd-Prozesse
Service (*.service)	Systemdienste (snapd, ssh, gdm, apache2 etc.)
Snapshot (*.snapshot)	Systemd-Sicherungsfunktion (fehlt meistens)
Slice (*.slice)	Ressourcensteuerung für Prozessgruppen (user, system)
Socket (*.socket)	Netzwerküberwachung und Service-Starts bei Ereignis
Swap (swapfile.swap)	Kontrolle und Steuerung der Auslagerungsdatei
Target (*target)	Unit-Sammlungen für definierte Systemzustände
Timer (*.timer)	Zeitsteuerung für Dienste und Autostarts
Pfade der Unit-Scripts
/etc/systemd/system/	benutzerdefinierte Units oder Anpassungen (priorisiert)
/lib/systemd/system/	Systemstandards
/usr/lib/systemd/system/	Systemstandards

Systemctl: Wichtige Kommandos
Listen und Kontrolle	Erklärung
systemctl [list-units]	Liste aller geladenen Units
systemctl [list-units] -all	Liste aller geladenen Units (auch inaktive)
systemctl -t service	Liste geladener Units einer bestimmten Klasse
systemctl -t service –all	Liste geladener Units einer bestimmten Klasse (auch inaktive)
systemctl list-dependencies ssh.service	alle Abhängigkeiten einer Unit anzeigen
systemctl list-unit-files	keine Prozessliste: Liste der Systemd-Konfigurationsdateien
systemctl list-unit-files -t service	keine Prozessliste: Konfigurationsdateien einer bestimmten Klasse
Unit-Steuerung (am Beispiel SSH)
systemctl status ssh.service	Statusabfrage
systemctl start ssh.service	Dienst starten
systemctl stop ssh.service	Dienst anhalten
systemctl restart ssh.service	Dienst-Neustart nach Konfigurationsänderung
systemctl disable ssh.service	Dienst deaktivieren
systemctl enable ssh.service	Dienst aktivieren
systemctl mask ssh.service	Dienst endgültig verbergen
systemctl unmask ssh.service	verborgenen Dienst wieder aktivieren
Unit-Änderungen (am Beispiel user.slice)
systemctl show user.slice	Eigenschaften einer Unit auflisten
systemctl set-property user.slice CPUQuota=50%	Eigenschaft einer Unit interaktiv (sofort) ändern
systemctl edit user.slice	Eigenschaft einer Unit dauerhaft ändern
systemctl revert user.slice	Änderungen an einer Unit wieder löschen
systemctl preset user.slice	Unit-Konfiguration auf Distributionsstandard setzen
systemctl preset-all (VORSICHT!)	komplettes Zurücksetzen auf Distributionsstandard
Spezielle Befehle für Targets
systemctl -t target	Liste aktiver Target-Units
systemctl get-default	Standard-Target ermitteln
systemctl set-default graphical.target	Standard-Target setzen
systemctl isolate rescue (VORSICHT!)	interaktiv (sofort) Target wechseln
Generelle Systemkommandos
systemctl daemon-reload	Neustart von systemd (nach Änderungen)
systemctl poweroff | reboot | suspend	System-Targets zum Beenden
systemctl rescue | emergency | default	System-Targets für (oder nach) Reparaturen

Die Armee der Systemd-Tools

Das im vorigen Artikel erklärte Systemctl ist das Fundament der Kommunikation mit Systemd. Das Init-System bringt aber inzwischen eine ganze Armee weiterer nutzwertiger Tools mit. 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 Systemd-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 Desktop-Nutzer.

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 zahlreichen und 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

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

journalctl --unit apache2 --since today

zeigt alle Meldungen des Apache-Servers ab dem angegebenen Datum. 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 10 Tage kürzen. Besonders auf Desktop-Systemen sind keine monatelangen Protokolle 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 Ethernetadapter „enp2s0“ ermittelt dann

networkctl status enp2s0

alle Parameter von der IP- und MAC-Adresse bis zu MTU, Speed und Gateway-Adresse (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

hostnamectl

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 Session-Zahl 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 beziehungsweise 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 Boot-Methode systemd-boot installiert und verwendet wird. Auf einem laufenden 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.

Die „Systemd-*“-Hilfsprogramme

Die nachfolgenden 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 Terminalsuchprogramm Locate nur minimale Systemlast (5 Prozent) erzeugen soll. Terminalprogramme mit sichtbarer Ausgabe benötigen ein Pseudo-Terminal („–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 Mount-Pfade 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 Update-Intervall. 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 zeigt abgeschaltete Units („masked“), originale Zustände („equivalent“) und sämtliche Konfigurationsänderungen („overridden“) im Detail. Die Anzeige abgeschalteter Units kann auch für normale Desktop-Nutzer relevant sein, die zwar keine Dienste geändert, aber mit systemctl mask […] abgeschaltet haben.

Weitere systemd-Hilfsprogramme sind ganz unscheinbare kleine Systemtool 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 Mini-Tool 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 beseitig.

Systemd-Units erstellen

Das Anlegen von einfacheren Timer-, Service- oder Mount-Units unter Systemd ist keine Geheimwissenschaft, braucht aber Übung und nicht selten korrigierende Detailrecherche. Systemd fordert Präzision und ist nicht auskunftsfreudig, wenn etwas nicht funktioniert. Wer aber die Prinzipien einmal beherrscht, wird durch zahlreiche Zeitoptionen, neue Möglichkeiten der Systemautomatisierung und minutiöse Details der Prozesssteuerung belohnt.

Jede Menge Anschauungsmaterial
Bevor man den ersten eigenen Timer oder Service baut, ist der Blick in vorhandene und funktionierende Beispiele nützlich. Der erste Artikel (ab Seite 40) hat nur gezeigt, wie systemctl edit […] Detailänderungen erledigen kann. Wer eine Unit-Datei nur lesen will, verwendet (Beispiel)

systemctl cat samba.service

und der Befehl

sudo systemctl edit --full samba.service

erlaubt Änderungen an der Originaldatei (statt eine zusätzliche Override-Anweisung anzulegen).

Die Durchsicht einiger Dateien mit systemctl cat ist für Einsteiger zwiespältig: Unit-Dateien sind kurz und mit ihrer Sektions-Struktur gut lesbar. Andererseits finden Sie in jeder Datei andere und neue Anweisungsdirektiven, deren Bedeutung und Relevanz sich nicht erschließt. Es ist keine schlechte Idee, mit Timer-Units zu starten. Erstens sind zeitgesteuerte Jobs ein häufiges Anliegen, zweitens sind die Unit-Dateien für Timer recht leicht nachvollziehbar: Die Sektions-Struktur „[Unit]“ (so beginnt jede Unit-Datei), „[Timer]“ (das ist der Unit-Typ und kann auch Service, Mount, Automount lauten) und „[Install]“ ist zuverlässig, und die ganze Datei enthält oft nur eine Handvoll relevanter Anweisungen. Unter „[Install]“ steht bei (System-) Timern immer:

[Install]
WantedBy=timers.target

Da oben unter „[Unit]“ nur die Zeile „Description=“ notwendig, aber beliebig zu füllen ist, geht es letztlich nur noch um die Zeitangaben unter „[Timer]“.

Timer: So einfach wie möglich

Der sicherste Weg, eigene Unit-Datei anzulegen, ist dieser Aufruf (Beispiel)

sudo systemctl edit --full --force auto-off.timer

Dann müssen Sie sich nicht um den richtigen Ort kümmern, und Systemctl öffnet eine temporäre Datei.#auto-off.timer[Hex-Ziffer], die nach dem Speichern /etc/systemd/system/auto-off.timer heißen wird. Hier tragen Sie die drei Sektionen „[Unit]“ mit beliebiger „Description“, „[Timer]“ und „[Install]“ mit der Standardanweisung „WantedBy=timers.target“ ein. Die Zeitangabe unter „[Timer]“ erledigen Sie mit der Anweisung „OnCalendar=“. Es gibt viele absolute und relative Zeitangaben, die Systemd-Timer akzeptieren. In diesem Beispiel tragen wir

OnCalendar=*-*-* 23:00:00

ein. Das bedeutet „jedes Jahr, jeden Monat, jeden Tag“ um 23 Uhr. Das ist schon alles, denn Systemd vermischt nichts: Was zu diesem Zeitpunkt konkret geschehen soll, muss in einer anderen Unit-Klasse definiert werden – als Service. Die Beziehung zwischen Timer und Service ist in den beiden Unit-Dateien nicht definiert. Sie entsteht schlicht dadurch, dass der Dateiname der Service-Unit exakt identisch sein muss mit jenem der Timer-Unit (hier „auto-off“) – daher:

sudo systemctl edit --full --force auto-off.service

In diese Datei muss nur der Titel „[Unit]“ mit der zweiten Zeile „Description=“ (Inhalt beliebig), darunter die Sektion „[Service]“ mit der Anweisung „ExecStart=“. Das ist der Befehl, der zu dem Zeitpunkt ausgeführt werden soll, die im Timer definiert ist. Dieses Beispiel fordert mit

ExecStart=/usr/sbin/rtcwake -m off -s 28800

einen Shutdown des Systems, das acht Stunden später wieder starten soll (28800 Sekunden). Da der Shutdown um 23 Uhr erfolgt, läuft das System um 7 Uhr wieder an.

Das Beispiel mit Rtcwake ist vielleicht nicht das einfachst mögliche, alle Systemd-betreffenden Anweisungen sind aber auf das absolute Minimum reduziert, was ein funktionierender Timer benötigt. Sie müssen nach dem Speichern von Timer- und Service-Unit den Timer lediglich noch scharf schalten. Dies ist nur einmal zur Ersteinrichtung erforderlich:

sudo systemctl daemon-reload
sudo systemctl enable auto-off.timer
sudo systemctl start auto-off.timer

Um die Service-Unit müssen Sie sich nicht kümmern, das erledigt der Timer zur gegebenen Zeit. Die beiden neuen Units werden nach

systemctl status auto-off.timer
systemctl status auto-off.service

für den Service melden, dass er aktuell „tot“ ist, aber „Triggered“ vom Timer. Der Timer hingegen meldet sich als „aktiv“ und zeigt eine Frist, wann er den Service starten wird.

Timer: Elaborierte Optionen und User-Kontext

Systemd-Timer kennen neben festen „OnCalendar=“-Zeiten zahlreiche relative Angaben wie „OnBootSec=10m“ (Beispiel für einen Timer, der 10 Minuten nach Anmeldung zuschlägt). Für periodische Wiederholungen gibt es vereinfachte Angaben wie „hourly“, „daily“, „weekly“ (also etwa „OnCalendar=daily“). Sehr hilfreich ist ferner, dass man mehrere „OnCalendar=“-Zeilen untereinander setzen. Und noch ein entscheidender Vorteil gegenüber Cron: Die Anweisung

Persistent=true

unterhalb der Sektion „[Timer]“ erledigt das, wofür neben Cron noch der Hilfsdienst Anacron arbeiten muss: Sie sorgt dafür, dass ein Termin nachgeholt wird, falls der Rechner zum geplanten Timer-Zeitpunkt nicht eingeschaltet war.

Das folgende Beispiel geht auf weitere Timer-Details nicht näher ein, führt aber ein bislang vernachlässigtes Großthema ein. Die Aufgabe des Beispiel-Timers scheint einfach: Ein Systemd-Timer soll an jedem Monatsbeginn durch ein „notify-send“ an die Erledigung der Umsatzsteuervoranmeldung erinnern. Notify-send ist ein grafisches Tool und muss daher im Benutzerkontext laufen (theoretisch kann auch ein System-Timer plus Service grafische Programme starten, aber das ist knifflig und unzuverlässig).

Systemd-Timer und Dienste können auch mit Benutzerrecht angelegt und genutzt werden. Es funktionieren alle erläuterten Systemctl-Kommandos, hier aber ohne „sudo“ und mit dem Schalter „–user“. Beim Erstellen überlässt man die Wahl des richtigen Pfades am besten wieder Systemctl:

systemctl --user edit --full --force ustva.timer

Wie bei einer System-Unit erfolgt die Erstellung (oder Nachbearbeitung) der Init-Datei mit einer temporären Datei, hier im User-Pfad ~/.config/systemd/user. Als die ersten beiden Zeilen stehen wieder das obligatorische „[Unit]“ und eine „Description“. Unter „[Timer]“ könnte nun etwa

[Timer]
OnCalendar=*-*-01 10:00:00
Persistent=true

folgen, um den Timer am ersten Tag jeden Monats um 10:00 auszulösen. Die „Persistent“-Zeile sorgt dafür, dass der Timer nachgeholt wird, falls der Rechner an diesem Ersten des Monats nicht läuft. Um die Flexibilität der Timer-Units zu zeigen, ändern wir den Zeitplan insofern, dass der Timer nur noch quartalsweise zuschlagen soll (Januar, April, Juli, Oktober). Das sind für kleine Solo-Selbständige die üblichen Termine für die Umsatzsteuer. Das ist ganz einfach mit diesen vier Zeilen erledigt:

OnCalendar=*-01-01 10:00:00
OnCalendar=*-04-01 10:00:00
OnCalendar=*-07-01 10:00:00
OnCalendar=*-10-01 10:00:00

In der letzten Sektion „[Install]“ ist bei Units, die im Benutzerkontext laufen, diese Anweisung erforderlich:

[Install]
WantedBy=default.target

Das ist ein wichtiger Unterschied zu System-Timern (immer timers.target).

Nun ist noch die zugehörige, gleichnamige Dienst-Unit zu erstellen:

systemctl --user edit --full --force ustva.service

In die Service-Datei kommt folgender Inhalt:

[Unit]
Description=Umsatzsteuer-Voranmeldung
Wants=graphical.target
After=graphical.target
[Service]
ExecStart=/usr/bin/notify-send "Umsatzsteuer bis 10. des Monats erledigen!"

Da ein grafisches Programm ausgelöst wird, ist in der Unit-Sektion das „graphical.target“ als benötigt (Wants) und gestartet (After) angegeben.

Path-Unit für Auto-Backup

Path-Units von Systemd können Ordner überwachen und Aufgaben automatisch auslösen, sobald sich Ordnerinhalte ändern. Die Kombination von Path-Unit und gleichnamiger Service-Unit ist ganz ähnlich wie bei Timer und Service, nur dass hier der Auslöse-Trigger kein zeitlicher, sondern eine Änderung im Dateisystem ist. Path-Units sollten gut überlegt sein, weil allzu umfangreiche Aktionen in frequentierten Ordern hohe und vielleicht unnötige Systemlast erzeugen. Bei Systemd muss man sich aber immerhin keine Gedanken machen, dass ein Service mehrfach läuft: Dies verhindert Systemd automatisch. Unser Beispiel zeigt, wie sich mit einer Path-Unit mehrere wichtige Ordner so überwachen lassen, dass bei allen Änderungen automatisch ein Rsync-Backup ausgelöst wird.

Der erste Schritt ist wieder das Erzeugen der Unit-Datei, hier mit

sudo systemctl edit --full --force auto-sync.path

für die Path-Klasse. „[Unit]“-Header und „Description“ oben sind problemlos, unter „[Install]“ binden wir die Unit an das multi-user.target:

WantedBy=multi-user.target

Das liegt bei der hier genutzten Serverplatine nahe, genügt aber auch bei einem Desktopsystem, weil der Vorgang keine grafischen Ressourcen benötigt. Wesentlich sind die Pfadangaben nach „PathChanged=“. Wie die Abbildung zeigt, sind diverse solche Einträge möglich und oft sinnvoll, weil Path-Units keine Unterverzeichnisse berücksichtigen. „PathChanged“ reagiert auf alle Datenänderungen im angegebenen Pfad.

Notwendig – und im Vergleich zu Timer-Units etwas irritierend – ist in der Sektion „[Path]“ die explizite Angabe der zugehörigen Service-Datei (mit gleichem Namen):

Unit=auto-sync.service

Nach Speichern der Path-Unit legen Sie mit

sudo systemctl edit --full --force auto-sync.service

die Service-Datei an. Unser Beispiel sichert per SSH auf ein anderes Gerät im Netzwerk und erfordert daher ein geladenes „network.target“, was in der ersten Sektion unter „[Unit]“ vermerkt wird. Die entscheidende Anweisung unter „[Service]“ ist wie üblich „Exec-Start=“. Die beiden weiteren Anweisungen sind optional, aber sinnvoll: Sie begrenzen die Systemlast der Aktion („CPUQuota“) und stellen mit „ExecCondition=“ eine Bedingung:

ExecCondition=/usr/bin/ping -c 1 192.168.0.110

Wenn der Rechner mit der genannten IP nicht erreichbar ist, stoppt der Service sofort. „ExecCondition“ ist sehr flexibel, insofern es den Exitcode ($?) eines beliebigen Bash-Tools auswertet. Nur bei Exitcode „0“ startet der Dienst.

Nach dem Speichern der beiden Unit-Dateien folgt wieder die übliche Einrichtung:

sudo systemctl daemon-reload
sudo systemctl enable auto-sync.path
sudo systemctl start auto-sync.path

Die Service-Unit wird nicht aktiviert. Das erledigt künftig die Path-Unit automatisch, sobald sich in den hinterlegten Pfaden etwas ändert.

Automount: Wozu ist das gut?

Die Datei /etc/fstab scheint eine Altlast, nachdem Systemd deren Laufwerkeinträge schon seit vielen Jahren in seine eigenen Mount-Units übersetzt (systemd-fstab-generator). Da aber von der Umstellung der systemkritischen Verzeichnisse Root (/) und Boot (/boot) auf Systemd-Mount-Units nach wie vor abgeraten wird, behält die fstab vorerst weiter ihr Existenzrecht. Damit bringt es keinen Vorteil, Datenlaufwerke aus der fstab zu nehmen und explizit als Systemd-Mount umzuwandeln.

Gute Motive für Mount- und Automount-Units gibt es aber für mobile USB-Datenträger. An das Automount von grafischen Systemen unter /media/[User] kann man sich sicher gewöhnen, aber vielleicht will man den Mountpunkt selbst bestimmen? Noch überzeugender ist ein Mount-Automount-Gespann auf einem (Platinen-) Server ohne Desktop: Wer hier alle paar Wochen mal ein bestimmtes USB-Gerät anschließen will, kommt an einem manuellen Einhängen nicht vorbei. Das kann Systemd deutlich vereinfachen.

Eine Automount-Unit benötigt immer eine zugehörige Mount-Unit mit demselben Namen. Automount ist – ähnlich wie Timer und Path – ein wartender Trigger, der beim Eintreten des Ereignisses die eigentliche Mount-Unit auslöst. Das Ereignis ist in diesem Fall der Zutritt in das Mount-Verzeichnis – ob per Klick im Dateimanager oder per Terminalbefehl (cd, ls, mc…), spielt dabei keine Rolle.

Eine erste wichtige Vorbereitung ist der Mount-Pfad. Der sollte sprechend, aber nicht lang und kompliziert sein (Leerzeichen besser vermeiden), weil die Unit-Dateinamen den Pfad exakt wiedergeben müssen. Für einen Mountpfad /srv/Archiv wäre dann die Unit-Namen srv-Archiv.mount und srv-Archiv.automount zutreffend. Im Zweifel liefert Systemd sogar das Mini-Tool

systemd-escape "/srv/Archiv/"

mit, um für einen Pfad den korrekten Unit-Namen zu ermitteln. Ist der Mountpfad angelegt, kann der Automount-Trigger erstellt werden (hier im System-Kontext):

sudo systemctl edit --full --force srv-Archiv.automount

Die wenigen Zeilen können Sie der Abbildung entnehmen. Entscheidend ist die Pfadangabe nach „Where=“, den die Unit künftig überwacht. Die Option „TimeOutIdleSec=“ ist optional, aber ressourcensparend. Unter „[Install]“ wird die Unit an das multi-user.target gebunden, was auch am grafischen Desktop ausreicht. Danach erstellt der Befehl

sudo systemctl edit --full --force srv-Archiv.mount

die zugehörige Mount-Unit. Die Angabe „Where=“ muss erneut den gewünschten Mountpfad definieren, während „What=“ die Hardware bezeichnet: Besser als etwa „/dev/sdb1“ ist die eindeutige UUID, die man vorher mit lsblk -f ermittelt. Der Rest ist nicht viel anders als beim Mount-Befehl oder in fstab. Auf grafischen Systemen ist bei den „Options=“  der zusätzliche Eintrag „x-gvfs-show“ keine schlechte Idee, weil der Dateimanager Systemd-Automounts nur dann in der Navigation anzeigt. Die Mount-Unit erhält keine „[Install]“-Sektion, da sie ausschließlich von der komplementären Automount-Unit gestartet wird.

Nach dem Speichern der Dateien müssen Sie den Automount-Trigger noch scharf schalten. Daher folgt abschließend die übliche Ersteinrichtung der Unit:

sudo systemctl daemon-reload
sudo systemctl enable srv-Archiv.automount
sudo systemctl start srv-Archiv.automount

Um die Mount-Unit müssen Sie sich nicht weiter kümmern.

Was passiert künftig, wenn Sie das USB-Laufwerk anschließen? Gar nichts – denn Automount ist keine Hardware-Erkennung, sondern eine Ordnerüberwachung. Erst sobald der Mount-Pfad betreten, wird die Mount-Unit ausgelöst und – mit leichter Verzögerung – stehen die Inhalte des Datenträgers zur Verfügung. Sehr praktisch! Noch ein Hinweis: Wenn Sie mit dem Tool

systemd-unmount /srv/Archiv/

das Laufwerk auswerfen, wertet Systemd dies als Ansage, dass Sie die Automount-Unit nicht mehr brauchen und deaktiviert sie.

((303_4_Automount.png))

SYSTEMD–Unit-Dateien	DIE WICHTIGSTEN REGELN
[Unit]	SEKTION 1 (notwendige und statische Startzeile „[Unit]“)
Description=	notwendig, aber Inhalt beliebig
Requires= | After= | Wants=	optionale Target-Angaben, falls die Unit z. B. „network.target“ oder „graphical“ benötigt
[Service] | [Timer] | [Path] | Mount]	SEKTION 2: Angabe der Unit-Klasse
[Service]
ExecStart=	notwendig: zu startendes Programm
Type=	optional, Standard „simple“ genügt oft
WorkingDirectory=	optional, aber oft nützlich, um Shellscript zu ersparen
Restart=	optional: z. B. „on-failure“, um den Dienst nach Fehler neu zu starten
ExecCondition=	optional: Shell-Befehl wie ping o. test, der Errorcode liefert (Dienst startet nur bei $?=0)
User= | Group=	optional: höhere Sicherheit, weil der Systemdienst dann nur in diesem Konto laufen darf
[Timer]
OnCalendar=	notwendig ist mindestens eine Zeitangabe, z. B. „–-* 15:00:00″ oder „hourly“
OnBootSec=	alternative relative Zeitangabe – etwa „20m“ (20 Minuten nach Anmeldung)
Persistent=	optional: „true“ holt den Timer nach, falls der Rechner zur geplanten Zeit nicht lief
[Path]
PathChanged=	notwendig ist mindestens eine Pfadangabe, „PathChanged“ reagiert auf alle Änderungen
PathExistsGlob=	erlaubt Filter nach Dateinamen oder Extensionen – etwa „/srv/data/*.pdf“
[Mount]
What=	notwendig: Gerätekennung wie „/dev/sda1“ oder „UUID=[…]“
Where=	notwendig: Mountordner im Dateisystem
Type=	optional, aber zu empfehlen: Dateisystem wie „ext4“ oder „ntfs“
Options=	optional, aber oft notwendig – etwa „username=sepp,password=sepp“
[Automount]
Where=	notwendig: muss exakt der Where-Zeile in der zugehörigen Mount-Unit entsprechen
TimeOutIdleSec=	optional: Abschaltzeit, falls kein Zugriff stattfindet – etwa „600“ (10 Minuten)
[Install]	SEKTION 3: Unit installieren (an Target binden)
WantedBy=	Target-Klasse wie multi-user.target oder timers.target
	Das angegebene Target erhält einen Symlink zu dieser Unit und startet es mit.
	Sektion 3 entfällt bei Mount-Units und Services, die von Timer- oder Path-Units gestartet werden