Wer sich mit der Administration von modernen Linux-Betriebssystemen beschäftigt, der kommt um den systemd-Dienst nicht herum. Viele Applikationen werden vom systemd-Dienst gestartet, gestoppt und überwacht. Im Gegensatz zum älteren SysV-Dienst lassen sich Abhängigkeiten zu anderen Applikationen definieren und Timer für ein zeitgesteuertes oder zyklisches Starten/Stoppen erstellen. Doch systemd-run kann noch mehr: In diesem Blogbeitrag wird gezeigt, wie man ad-hoc flüchtige (transiente) systemd-Dienste erzeugen kann. 

Aller Anfang ist leicht

Am besten lässt sich die Funktionsweise von systemd-run an folgendem Minimalbeispiel zeigen, in dem das Skript demoskript.sh gestartet wird: 

Anhand der Ausgabe wird ersichtlich, dass um das demoskript.sh ein systemd-Skript gebaut wurde. Sofern man den Parameter --unit nicht nutzt, erhält der entstandene Service einen automatisch generierten Namen. Im Allgemeinen ist es jedoch sinnvoll, stets einen sprechenden Namen zu wählen, um Services leichter wiederzufinden.

Nur der Vollständigkeit halber soll gezeigt werden, was das Demoskript macht:

Im Rahmen dieses Blogartikels sollte der Inhalt des Demoskripts genügen. In der Praxis kann man hier durchaus sinnvolle Skripte erstellen, die zum Beispiel Backups oder andere Jobs starten. 

Der transiente Service

Einen kurzen Moment später lässt sich der Service natürlich auch mit dem wohl am häufigsten genutzten Kommando unter systemd anzeigen: 

Wird der Status nach über einer Minute erneut aufgerufen, erscheint folgende Fehlermeldung: 

Das liegt daran, dass es sich um einen „transienten“ Service handelt, der automatisch wieder verschwindet, wenn das Skript beendet wurde. Jedoch lassen sich die Ausgaben, die ins Journal übermittelt wurden, weiterhin betrachten und nachträglich in Ruhe analysieren: 

Transiente Timer für zeitgesteuerte Services

Besonders interessant wird es, wenn man den Service zeitgesteuert ausführen kann: 

In diesem Fall wird neben der temporären Service Unit auch eine Timer Unit erstellt. In diesem Fall ähnelt das Verhalten dem eines at-Jobs. Wen systemd-Timer interessieren, der wird in diesem Blogbeitrag fündig „Automatisierte Ausführung von Aufgaben zu einer festen Zeit – Timer in Systemd“. Eine Übersicht, welche Timer auf dem System existieren, erhält man mit systemctl list-timers.

Ein Blick ins Journal bestätigt uns die korrekte Ausführung ab 16:55 Uhr am 08.10.2026:

Ein echter Vorteil besteht darin, dass es sich hierbei um eine einmalige Aktion handelt. Würde man einen cronjob oder einen echten systemd-Timer erstellen, müsste man nach der Aktion die betroffenen Konfigurationsdateien wieder entfernen. Vergisst man dies, entstehen schnell Altlasten. 

systemd-run kann noch mehr

An dieser Stelle ist die Funktionalität eines klassischen at-Jobs nachgestellt: das einmalige und zeitgesteuerte Starten von Diensten. Aber systemd-run kann noch viel mehr. Auf einiges davon wird nun im Folgenden eingegangen. 

Aufruf mit bestimmten User

Soll der Aufruf unter einem bestimmten User erfolgen, so lässt sich dies einfach realisieren: 

Hier wird ebenfalls eine transiente Unit erstellt und sämtliche Prozesse und Umgebungen, die sich aus der Unit-Beschreibung ergeben, gehören dem User „dominic“. 

Limits festlegen

Ein besonders interessantes Feature von systemd-run ist die Möglichkeit, CPU- und RAM-Limits für einen transienten Service zu konfigurieren. Der Aufruf gestaltet sich wie folgt: 

Dieser Aufruf erstellt einen transienten Service, dessen cgroup auf maximal 4 GB Hauptspeicher und maximal 60 % nutzbare CPU-Zeit eines Kerns beschränkt ist. Wird bei letzterem ein Wert > 100 % gesetzt, wird (sofern vorhanden) die CPU-Zeit eines anderen Kerns anteilig mitgenutzt. Sollte einer der beiden Werte zur Laufzeit des transienten Services überschritten werden, werden sämtliche Prozesse beendet und der transiente Service gelangt in den Status „failed“. 

Laufzeit beschränken

Möchte man erreichen, dass ein Prozess nach dem Start nach einer bestimmten Dauer beendet wird, lässt sich dies ebenfalls einfach implementieren. Insbesondere in Verbindung mit der Timer-Komponente lassen sich so z. B. Tracing-Verfahren für die Überwachung von Anwendungen in einem bestimmten Zeitraum sinnvoll realisieren: 

Wenn das Zeitlimit erreicht ist, wechselt die Unit in den Status „failed“. Wen dies stört, der kann mit --collect direkt nach Beendigung eine failed Unit aufräumen lassen. Die Einträge im Journal bleiben selbstverständlich erhalten. 

Abhängigkeiten definieren

Wie bei regulären Systemd-Units lassen sich auch sämtliche Möglichkeiten nutzen, Abhängigkeiten zu definieren: 

Im obigen Beispiel wird der Service demoapp.service zuerst gestartet (falls dieser noch nicht läuft), danach erst der Service demoskript.service.

Fazit

Mit Hilfe von systemd-run lassen sich Prozesse, die spontan gestartet werden sollen, nahtlos in das Systemd-Ökosystem integrieren, ohne auf die Vorzüge von herkömmlichen Systemd-Services zu verzichten. Damit ist es möglich, Timer zu nutzen, Ressourcen zu beschränken, Abhängigkeiten zu definieren und vieles mehr.

Als Folge lassen sich sämtliche Ausgaben der Prozesse auch nach Beendigung im Journal betrachten. Dies ist insbesondere relevant für Administrationsaufgaben und Automatisierungen, die zu späterem Zeitpunkt noch detailliert nachvollzogen werden können.

Quellen

Seminarempfehlungen