Timer in Systemd ersetzen Cronjobs

Systemd-Timer soll bestehende Cronjobs ersetzen

Ältere Versionen von Linux verwenden den Cron-Daemon zur Planung von Aufgaben. Der Cron-Daemon wird jedoch für neue Installationen nicht mehr empfohlen. Stattdessen sollten Sie den systemd-Timer verwenden. Denn Cron stammt aus einer Zeit, in der Linux-Systeme viel einfacher aufgebaut waren. Er funktioniert zwar immer noch, hat aber einige strukturelle Nachteile.

Kein Bezug zum Systemzustand
- Cron weiß nicht, ob das System gerade gebootet wird, im Sleep war oder Dienste noch nicht laufen.
- Jobs gehen einfach verloren, wenn der Rechner zum geplanten Zeitpunkt aus ist.
Schwaches Fehler- und Logging-Handling
- Logs sind verstreut oder minimal.
- Fehler müssen oft per Mail oder eigenen Skripten abgefangen werden.
Kaum Abhängigkeiten
- Cron kann nicht sauber sagen: „Starte diesen Job erst, wenn Dienst X läuft“.
Getrennte Welt
- Cron lebt komplett außerhalb von systemd, das heute das zentrale Init- und Service-System ist.

Das alles kann mit systemd-Timer abgefangen werden. Deshalb soll hier das einfache Aufsetzen und Administrieren von diesen Timern dargestellt werden.

Systemd der Nachfolger des SysVInit-System

Was ist Systemd eigentlich? Und warum ist es so zentral für moderne Linux-Systeme?

Systemd ist das Init-System moderner Linux-Distributionen. In früheren Versionen gab es SysVInit, dem Init-System unter dem Unix-Betriebssystem System V, nach der UNIX-Philosophie „Ein Programm, eine Aufgabe“. Jeder Service wird als eigenständiges Skript gestartet, konfiguriert und gestoppt. Systemd dagegen ist aber ein monolithisches Init-System. Es übernimmt somit nicht nur das Starten von Diensten, sondern auch das Logging (journald), die Timers, die Socket-Aktivierung und vieles mehr. Damit wären wir bereits mitten drin, bei den Hauptaufgaben von systemd:

Systemstart (Bootprozess)
- systemd ist der erste Prozess nach dem Kernel.
- Er startet alle wichtigen Dienste in der richtigen Reihenfolge.
Dienstverwaltung (Service Management)
- Dienste starten, stoppen, neu laden.
- Dienste automatisch neu starten, falls sie abstürzen.
Protokollierung (Logging)
- Mit journalctl lassen sich alle Logs bequem durchsuchen.
- Daraus folgt eine einheitlichere Verwaltung statt verstreuter Logdateien.
Ressourcenverwaltung
- Eine Begrenzung von CPU, RAM oder Netzwerk für bestimmte Dienste ist realisierbar.
Timer und Automatisierung
- systemd kann ähnlich wie Cron zeitgesteuerte Aufgaben übernehmen, allerdings sehr viel flexibler.

Das Einstellen eines Timer mit systemd auf Linux

Wir haben jetzt festgestellt, dass Systemd-Timer optimal dazu geeignet sind, herkömmliche Cron-Jobs zu ersetzen. Also schauen wir uns hier den Aufbau eines Timers genauer an. Zunächst einmal wollen wir eine Liste aller aktiven Timer auf einem Linux-System anzeigen lassen mit dem Befehl

~# systemctl list-timers

Damit wird eine Liste der Timer, einschließlich des Namens des Timers, der nächsten Auslösezeit und der letzten Auslösezeit, geliefert:

NEXT LEFT LAST PASSED UNIT ACTIVATES
Mon 2026-03-02 00:00:00 CET 7h left Sun 2026-03-01 00:00:08 CET 16h ago dpkg-db-backup.timer dpkg-db-backup.service
Mon 2026-03-02 00:00:00 CET 7h left Sun 2026-03-01 00:00:08 CET 16h ago logrotate.timer logrotate.service
Mon 2026-03-02 04:41:29 CET 12h left Sun 2026-03-01 07:39:45 CET 8h ago apt-daily.timer apt-daily.service
Mon 2026-03-02 06:15:02 CET 13h left Sun 2026-03-01 06:18:19 CET 10h ago apt-daily-upgrade.timer apt-daily-upgrade.service
Mon 2026-03-02 08:21:42 CET 15h left Sun 2026-03-01 08:44:15 CET 7h ago man-db.timer man-db.service
Mon 2026-03-02 10:13:29 CET 17h left Sun 2026-03-01 10:13:29 CET 6h ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
Fri 2026-03-06 19:00:00 CET 5 days left Fri 2026-02-27 19:00:02 CET 1 day 21h ago securesnap.timer securesnap.service
Sun 2026-03-08 03:00:00 CET 6 days left Sun 2026-03-01 03:00:17 CET 13h ago backup2storage.timer backup2storage.service

Aufbau eines Timers

Generell braucht man, wie bei allen Aspekten ausserhalb des Home-Verzeichnisse, um einen Timer einzustellen, den Root-Benutzer mittels “su -” oder einen Benutzer mit sudo-Berechtigungen.

Wir erstellen für das Backup-Script “Securesnap” statt eines Cronjobs eben einen Systemd-Timer mit

~# vi /etc/systemd/system/securesnap.timer

mit folgendem Inhalt

[Unit]
Description=Timer for Securesnap Backup
[Timer]
OnCalendar=Fri 19:00
Persistent=true
Unit=securesnap.service
[Install]
WantedBy=timers.target

Dabei sind die drei Blöcke "Unit", "Timer" und "Install" obligatorisch. Interessant sind OnCalendar zur Zeitangabe der Durchführung, Persistent, Unit im Timer-Block und WantedBy im Install-Block.

Mit Unit im Timer-Block wird der dazugehörige Service explizit zugeordnet, wobei das eigentlich durch die äquivalenten Namen für .timer und .service erreicht wird, sofern explizit systemctl start securesnap.timer direkt benutzt würde. Und Persistent=true sorgt dafür, verpasste Jobs beim nächsten Start nachzuholen. Etwas, das bei regelmäßigen Jobs auf Servern keinen Sinn macht. Denn Server laufen nahezu dauerhaft und wenn die Intervalle moderat sind, kann man diesen Parameter getrost vernachlässigen.
Dagegen wird WantedBy=timers.target benötigt, damit der Timer beim Boot aktiviert wird.

Aufbau des dazugehörigen Service

Wie soeben bei der Timer-Definition ersichtlich wurde, macht dieser ohne den passenden Service keinen Sinn. Der äquivalente Service zu diesem Beispiel-Timer wäre dieser Service /etc/systemd/system/securesnap.service:

[Unit]
Description=Weekly System Backup with Securesnap
[Service]
Type=oneshot
ExecStart=/usr/local/bin/securesnap.sh
[Install]
WantedBy=multi-user.target

Da es sich um einen einmaligen Job nach dem jeweiligen Triggern durch den Timer handelt, ist der Parameter Type=oneshot sehr wichtig. Denn hier wartet Systemd darauf, dass der Prozess fertig ist, erst dann wird der Service beendet.

Aktivierung und Starten eines Timers

Sehr wichtig ist das Neuladen der Systemd-Konfigurationen, wir haben diese ja mit dem Erstellen eines neuen Timers und Services verändert. Davon weiß Systemd erst nach Durchführung dieses Befehles.

~# systemctl daemon-reload

Das Starten des Timers erfolgt aus diese Weise:

~# systemctl start securesnap.timer

Und damit der Timer beim Boot aktiviert wird, ist dieser Befehl notwendig:

~# systemctl enable securesnap.timer

Überwachung des Timer

Mit folgenden Befehl kann gezielt der betreffende Timer angezeigt werden:

~# systemctl list-timers securesnap.timer

NEXT LEFT LAST PASSED UNIT ACTIVATES
Fri 2026-03-06 19:00:00 CET 5 days left Fri 2026-02-27 19:00:02 CET 1 day 22h ago securesnap.timer securesnap.service

Und die Logs des Service werden mit diesem Befahl angezeigt:

~# journalctl -u securesnap.service

OnCalendar im Timer-Block

OnCalendar ist eine Option im Timer-Block einer Timer-Unit-Datei, die angibt, wann der Timer ausgelöst werden soll. Die Syntax für OnCalendar lautet wie folgt:

OnCalendar=*-*-* 02:00:00

als Beispiel für "Jeden Tag um 2 Uhr".

Sehr nützlich ist systemd-analyze calendar als Analysetool in der Bash, um die richtige Syntax für die Timer-Option OnCalendar korrekt übernehmen zu können und zu sehen, ob die gewünschte Zeitspanne auch funktioniert.

Das sieht zum Beispiel so aus:

~# systemd-analyze calendar "Fri 19:00"
Original form: Fri 19:00
Normalized form: Fri *-*-* 19:00:00
Next elapse: Fri 2026-02-27 19:00:00 CET
(in UTC): Fri 2026-02-27 18:00:00 UTC
From now: 3 days left

Beides, Original form und Normalized form, kann man direkt so in den Timer übernehmen.

Insgesamt bietet die Option OnCalendar eine flexible und leistungsstarke Möglichkeit, Aufgaben in Linux mithilfe von systemd-Timern zu planen. Durch das Verständnis der Syntax und die Verwendung der entsprechenden Kalenderausdrücke können Sie Ihr System automatisieren und Zeit und Aufwand sparen.