Systemd-Timer statt Cron: Warum ich umgestiegen bin

Cron ist überall, aber systemd-Timer bieten Logging, Abhängigkeiten und Fehlerbehandlung out-of-the-box. Ein Umstieg lohnt sich mehr, als man denkt.

Was Cron nicht kann

Ein Cron-Job, der fehlschlägt, schickt im besten Fall eine Mail. Logs landen irgendwo. Abhängigkeiten zu anderen Diensten gibt es nicht. Will man einen Job nur ausführen, wenn das Netzwerk verfügbar ist? Pech gehabt.

Wie es mit systemd aussieht

Zwei Dateien: ein Service und ein Timer.

# /etc/systemd/system/backup.service
[Unit]
Description=Tägliches Backup

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

# /etc/systemd/system/backup.timer
[Unit]
Description=Timer für Backup

[Timer]
OnCalendar=daily
Persistent=true

[Install]
WantedBy=timers.target

Aktivieren mit systemctl enable --now backup.timer. Logs gibt es über journalctl -u backup, und wenn der Rechner zur geplanten Zeit aus war, wird der Job bei nächster Gelegenheit nachgeholt (dank Persistent=true).

Fazit

Cron hat seine Berechtigung für triviale Aufgaben. Sobald aber Logging, Fehlerbehandlung oder Abhängigkeiten ins Spiel kommen, sind systemd-Timer die bessere Wahl.