6 Minuten Lesezeit (1142 Worte)

Kurz und gut – Episode #26 Prozesse spontan in systemd integrieren: systemd-run macht es möglich

Dienstag, 27. Oktober 2026

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:

localhost:~ # systemd-run --unit=demoskript /etc/demoskript.sh 

Running as unit: demoskript.service; invocation ID: e800db75c3bf49029c2013bf5d7e6ed3

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:

localhost:~ # cat /etc/demoskript.sh 
#!/bin/sh 
for i in {1..5} ; do 
        echo $(date) 
        sleep 15 
done

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:

localhost:~ # systemctl status demoskript.service 
● demoskript.service - [systemd-run] /etc/demoskript.sh 
     Loaded: loaded (/run/systemd/transient/demoskript.service; transient) 
  Transient: yes 
     Active: active (running) since Thu 2026-10-08 15:35:06 CEST; 30s ago 
 Invocation: eb7c4d0e19fc4118baa368c6fc327753 
   Main PID: 10560 (demoskript.sh) 
      Tasks: 2 (limit: 13953) 
        CPU: 27ms 
     CGroup: /system.slice/demoskript.service 
             ├─10560 /bin/sh /etc/demoskript.sh 
             └─10604 sleep 15 
 
Oct 08 15:35:06 localhost.localdomain systemd[1]: Started [systemd-run] /etc/demoskript.sh. 
Oct 08 15:35:06 localhost.localdomain demoskript.sh[10560]: Thu Oct 8 03:35:06 PM CEST 2026 
Oct 08 15:35:21 localhost.localdomain demoskript.sh[10560]: Thu Oct 8 03:35:21 PM CEST 2026 
Oct 08 15:35:36 localhost.localdomain demoskript.sh[10560]: Thu Oct 8 03:35:36 PM CEST 2026

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

localhost:~ # systemctl status demoskript.service 

Unit demoskript.service could not be found.

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:

localhost:~ # journalctl -u demoskript.service 

Oct 08 15:35:06 localhost.localdomain systemd[1]: Started [systemd-run] /etc/demoskript.sh. 

Oct 08 15:35:06 localhost.localdomain demoskript.sh[10560]: Thu Oct 8 03:35:06 PM CEST 2026 

Oct 08 15:35:21 localhost.localdomain demoskript.sh[10560]: Thu Oct 8 03:35:21 PM CEST 2026 

Oct 08 15:35:36 localhost.localdomain demoskript.sh[10560]: Thu Oct 8 03:35:36 PM CEST 2026 

Oct 08 15:35:51 localhost.localdomain demoskript.sh[10560]: Thu Oct 8 03:35:51 PM CEST 2026 

Oct 08 15:36:06 localhost.localdomain demoskript.sh[10560]: Thu Oct 8 03:36:06 PM CEST 2026 

Oct 08 15:36:21 localhost.localdomain systemd[1]: demoskript.service: Deactivated successfully.

Transiente Timer für zeitgesteuerte Services

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

localhost:~ # systemd-run --unit=demoskript --on-calendar="2026-10-08 16:55:00" /etc/demoskript.sh 

Running timer as unit: demoskript.timer 

Will run service as unit: demoskript.service

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:

localhost:~ # journalctl -u demoskript.service 

Oct 08 16:55:04 localhost.localdomain systemd[1]: Started [systemd-run] /etc/demoskript.sh. 

Oct 08 16:55:04 localhost.localdomain demoskript.sh[15036]: Thu Oct 8 04:55:04 PM CEST 2026 

Oct 08 16:55:19 localhost.localdomain demoskript.sh[15036]: Thu Oct 8 04:55:19 PM CEST 2026 

Oct 08 16:55:34 localhost.localdomain demoskript.sh[15036]: Thu Oct 8 04:55:34 PM CEST 2026 

Oct 08 16:55:49 localhost.localdomain demoskript.sh[15036]: Thu Oct 8 04:55:49 PM CEST 2026 

Oct 08 16:56:04 localhost.localdomain demoskript.sh[15036]: Thu Oct 8 04:56:04 PM CEST 2026 

Oct 08 16:56:19 localhost.localdomain systemd[1]: demoskript.service: Deactivated successfully.

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:

localhost:~ # systemd-run --uid dominic --unit demoskript /etc/demoskript.sh 

Running as unit: demoskript.service; invocation ID: 932098b23dba4a7b96fdac968bb67fee

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:

localhost:~ # systemd-run --unit demoskript  -p MemoryMax=4G -p CPUQuota=60% /etc/demoskript.sh

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:

localhost:~ # systemd-run --unit=demoskript --on-calendar="2026-10-14 11:00:00" -p RuntimeMaxSec=20 /etc/demoskript.sh

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:

localhost:~ # systemd-run --unit=demoskript --on-calendar="2026-10-14 11:00:00" -p RuntimeMaxSec=20 -p Requires=demoapp.service After=demoapp.service /etc/demoskript.sh

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.