Cron vs. systemd-Timer: Wann ich zu welchem greife

Jedes Mal, wenn dieses Thema aufkommt, argumentiert jemand, dass systemd-Timer Cron komplett ersetzen sollten. Bei den Fähigkeiten liegen sie nicht falsch, Timer haben besseres Logging, können von anderen Units abhängen und überleben es, wenn der Server zum geplanten Zeitpunkt aus war. Und trotzdem schreibe ich regelmäßig noch Cron-Jobs, weil die Entscheidung eigentlich nicht über Features läuft. Es geht darum, wer das in einem Jahr lesen muss, und wie viel Aufwand der Job tatsächlich verdient.

Wo Cron gewinnt: klein, einfach, jedem bekannt

Ein Cron-Job ist eine Zeile. Jeder, der in den letzten zwanzig Jahren mit Linux zu tun hatte, kann eine Crontab lesen und verstehen, ohne Dokumentation:

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

Für solche Jobs bedeutet das systemd-Äquivalent zwei Dateien, eine .service und eine .timer, plus einen enable-Schritt, für einen Job, der von all dem zusätzlichen Funktionsumfang nichts braucht. Der Mehraufwand ist nicht wirklich eine Frage des Tippens, sondern der nächsten Person, die diesen Job während eines Incidents finden muss. crontab -l oder ein kurzer Blick in /etc/cron.d/ ist das Erste, was die meisten Linux-Admins prüfen. Ein Timer, von dem niemand weiß, dass er existiert, ist ein Job, der effektiv nicht existiert, bis ihn jemand zufällig findet.

Meine Regel: Wenn der Job ein einzelner Befehl ist, nicht auf Fehler reagieren muss und ein verpasster Lauf egal wäre, ist es Cron.

Wo systemd-Timer gewinnen: alles, dem man vertrauen muss

In dem Moment, in dem ein geplanter Job tatsächlich wichtig wird, Backups, Zertifikatserneuerungen, alles, wo ein stiller Fehlschlag zu einem 2-Uhr-Anruf wird, rechtfertigt sich der zusätzliche Aufwand von systemd-Timern.

# /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=Backup jede Nacht ausführen

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

[Install]
WantedBy=timers.target

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

Drei Dinge hier, die Cron nicht von Haus aus liefert. journalctl -u backup.service zeigt die vollständige Ausgabe und den Exit-Status jedes Laufs, ohne dass man in eine Logdatei umleiten und hoffen muss, sie zu rotieren. Persistent=true bedeutet: War der Server um 2 Uhr nachts aus, läuft der Job, sobald er wieder hochkommt, statt einen ganzen Tag stillschweigend auf den nächsten geplanten Zeitpunkt zu warten. Und systemctl status backup.timer sagt einem genau, wann der Job zuletzt lief und wann er das nächste Mal läuft, was bei einem Cron-Job bedeutet, den Zeitplan zu lesen und selbst nachzurechnen.

Die eigentlich entscheidende Frage

Wenn ich einen neuen geplanten Job einrichte, ist die Frage nicht "was ist moderner". Sie lautet: Wenn dieser Job lautlos fehlschlägt, wie lange dauert es, bis es jemand merkt, und ist das relevant?

Wenn die Antwort lautet "eigentlich egal, und falls doch, würde ich es auf einem anderen Weg merken" (ein Tmp-Cleanup, ein Cache-Warmup, eine Log-Rotation, die ohnehin schon durch logrotate abgedeckt ist), reicht Cron völlig, und seine Einfachheit ist ein Feature, keine Einschränkung. Wenn die Antwort lautet "das ist das Einzige, was zwischen uns und Datenverlust steht" oder "ein verpasster Lauf wird zu einem Problem für Kunden", sind die zwei zusätzlichen Dateien und das saubere Logging eines systemd-Timers jedes Mal ihr Geld wert.

Die meisten Server, die ich betreue, haben am Ende beides, eine Handvoll Cron-Einzeiler für Hausmeisterarbeiten und eine kleine Zahl systemd-Timer für die Jobs, denen man tatsächlich vertrauen muss. Diese Mischung ist kein Kompromiss, sie passt den Aufwand des Werkzeugs der Wichtigkeit des Jobs an, und sie sorgt dafür, dass die systemd-Timer auf einer Maschine eine kurze, bedeutsame Liste sind und kein Rauschen, an dem man vorbeiscrollt.