Cron vs. systemd Timers: Wann ich was benutze

Jedes Mal, wenn das Thema aufkommt, argumentiert jemand, dass systemd-Timer Cron komplett ersetzen sollten. Und was die Features angeht, haben sie recht: Timer bieten besseres Logging, sauberes Dependency-Management und können Server-Reboots überleben, um verpasste Jobs nachzuholen. Dennoch schreibe ich weiterhin regelmäßig Cronjobs. Bei dieser Entscheidung geht es nicht um Features, sondern darum, wer den Code in einem Jahr lesen muss und wie viel Overhead der Job wirklich verdient.

Wo Cron gewinnt: klein, simpel, altbekannt

Ein Cronjob ist ein Einzeiler. Jeder, der in den letzten zwanzig Jahren mal ein Linux-System administriert hat, kann eine Crontab lesen und sofort verstehen:

# /etc/cron.d/cleanup-tmp
0 3 * * * root find /tmp -type f -atime +7 -delete

Für solche Jobs benötigt das systemd-Äquivalent zwei Dateien (eine .service und eine .timer) plus einen enable-Schritt. Das ist viel Overhead für etwas so Banales. Das eigentliche Problem ist aber nicht die Tipparbeit, sondern die Auffindbarkeit. Bei einem Zwischenfall prüfen die meisten Linux-Admins als Erstes crontab -l oder schauen in /etc/cron.d/. Ein systemd-Timer, von dem niemand weiß, dass er existiert, ist im Notfall unsichtbar.

Meine Regel: Wenn der Job aus einem einzigen Befehl besteht, kein aufwendiges Error-Handling braucht und es nicht schlimm ist, wenn ein Durchlauf fehlt, dann benutze ich Cron.

Wo systemd-Timer gewinnen: Jobs, denen man vertrauen muss

Sobald ein geplanter Job wichtig wird – Backups, Zertifikatsverlängerungen oder alles, was bei stillem Versagen um 2 Uhr nachts den Pager klingeln lässt –, zahlt sich der Mehraufwand für systemd-Timer sofort aus.

# /etc/systemd/system/backup.service
[Unit]
Description=Nächtliches Datenbank-Backup

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup.sh

# /etc/systemd/system/backup.timer
[Unit]
Description=Führe Backup nächtlich aus

[Timer]
OnCalendar=*-*-* 02:00:00
Persistent=true

[Install]
WantedBy=timers.target

systemctl enable --now backup.timer
journalctl -u backup.service

systemd bietet drei Dinge, die Cron nicht liefert:

1. journalctl -u backup.service zeigt die vollständige Ausgabe und den Exit-Status jedes Durchlaufs. Kein nerviges Umleiten von stdout/stderr in Logdateien, in der Hoffnung, dass logrotate nicht streikt.
2. Persistent=true garantiert, dass der Job beim Hochfahren nachgeholt wird, falls der Server zu seinem geplanten 2-Uhr-Slot offline war.
3. systemctl status backup.timer sagt dir auf die Sekunde genau, wann der Job zuletzt lief und wann der nächste Durchlauf ansteht.

Die alles entscheidende Frage

Wenn ich einen neuen automatisierten Job anlege, ist es mir egal, welches Tool „moderner“ ist. Ich frage mich: Wenn dieser Job stillschweigend fehlschlägt, wie lange dauert es, bis es jemand merkt, und ist es dann ein Problem?

Wenn es eigentlich niemanden stört (z.B. Temp-Cleanup oder Cache-Warmup), ist die Einfachheit von Cron ein großer Vorteil. Wenn es jedoch das Einzige ist, was das Unternehmen vor einem Datenverlust schützt, sind die zwei extra Dateien und das native Logging eines systemd-Timers absolut unverhandelbar.

Die meisten Server, die ich betreue, nutzen beides: ein paar Cron-Einzeiler für unwichtiges Housekeeping und eine kurze, saubere Liste von systemd-Timern für kritische Aufgaben. Das ist kein fauler Kompromiss, sondern einfach das richtige Werkzeug für die richtige Aufgabe.