Kurz gesagt
Für einfache, unkritische Aufgaben ist Cron völlig in Ordnung. Für Jobs, deren Ausfall jemand bemerken muss, etwa Backups, Zertifikatserneuerung oder Nextcloud-Hintergrundjobs, sind systemd-Timer meist die bessere Wahl, weil Status und Logs mit systemctl und journalctl sichtbar sind.
| Kriterium | systemd timers | cron |
|---|---|---|
| Einrichtung | Zwei Units: .service und .timer | Eine Zeile in der crontab |
| Zeitangabe | OnCalendar=, z. B. *-*-* 03:00, oder relativ mit OnBootSec= | Fünf Felder, z. B. 0 3 * * * |
| Logging | Automatisch im Journal, abrufbar mit journalctl -u | Nur per Mail (MAILTO) oder eigene Umleitung |
| Verpasste Läufe | Persistent=true holt sie nach dem Einschalten nach | Gehen verloren (außer mit anacron) |
| Überlappung | Läuft der Service noch, startet der Timer ihn nicht erneut | Möglich, Absicherung z. B. mit flock |
| Umgebung | Definiert in der Unit, reproduzierbar | Minimaler PATH, häufige Fehlerquelle |
| Ressourcen und Sicherheit | CPU-, Speicher- und I/O-Grenzen, Sandboxing per Unit-Optionen | Keine eigenen Mittel |
| Überblick | systemctl list-timers zeigt letzten und nächsten Lauf | crontab -l pro Benutzer, dazu /etc/cron.d |
systemd timers passt, wenn …
- ein Fehlschlag auffallen muss, etwa im Monitoring über fehlgeschlagene Units.
- der Job lange läuft und sich nicht selbst überholen darf.
- der Server nicht dauerhaft läuft und verpasste Läufe nachgeholt werden sollen.
- Sie Ressourcen begrenzen oder den Job mit eingeschränkten Rechten laufen lassen wollen.
cron passt, wenn …
- die Aufgabe kurz, einfach und unkritisch ist.
- Sie Systeme ohne systemd betreuen, etwa Container oder ältere Distributionen.
- die Anwendung eine crontab-Zeile dokumentiert und Sie nah an der Doku bleiben wollen.
- Benutzer eigene Jobs pflegen sollen, ohne Root-Rechte.
Stolpersteine aus dem Betrieb
- Cron: Skript läuft im Terminal, aber nicht per Cron. Fast immer liegt es an
PATHoder fehlenden Variablen. Absolute Pfade verwenden. - Cron: Ein
%in der Befehlszeile wird als Zeilenumbruch interpretiert und muss als\%geschrieben werden, etwa beidate +%F. - systemd: Nach dem Anlegen fehlt
systemctl daemon-reloadundsystemctl enable --now name.timer. Der Timer existiert, läuft aber nie. - systemd:
OnCalendar-Ausdrücke vorher mitsystemd-analyze calendarprüfen, sonst läuft der Job zu anderen Zeiten als gedacht.
Häufige Fragen
Muss ich alle Cronjobs auf Timer umstellen?
Nein. Umstellen lohnt sich bei Jobs, deren Ausfall Folgen hat oder die Sie überwachen wollen. Einfache Aufräumjobs können in Cron bleiben. Wichtig ist, dass jede Aufgabe nur an einer Stelle definiert ist.
Wie sehe ich, ob ein Timer zuletzt erfolgreich war?
systemctl list-timers zeigt den letzten Lauf, systemctl status name.service das Ergebnis und journalctl -u name.service die Ausgabe. Fehlgeschlagene Läufe tauchen auch in systemctl --failed auf.