Aufgabenplaner unter Linux – Wann sollte man Cron verwenden, wann sollte man den Systemd-Timer verwenden?

Vor einiger Zeit habe ich ein automatisches Backup für mehrere Dienste auf dem Heimserver erstellt. Mit cron lief alles reibungslos, bis ich eines Tages eine Aufgabe brauchte, die einmal nach dem Neustart ausgeführt und dann jede Stunde wiederholt wurde, aber nur, wenn das vorherige Ergebnis fehlschlug. Ab diesem Zeitpunkt fühlt sich der cron an wie ein Fahrrad, das auf einem Kühlschrank mitfahren muss: Es kann immer noch laufen, bringt sich aber selbst ins Schwitzen. Schließlich tauchte ich in die Welt von systemd timer ein und stellte fest, dass Linux zwei Zeitnehmer mit ganz unterschiedlichen Charakteren hat.

Cron: Der legendäre klassische Zeitmesser

cron ist der älteste und bekannteste Taskplaner in der Linux-Welt. Es ist wie mit der analogen Wanduhr bei Oma: einfach, nicht viele Funktionen, aber immer zuverlässig und fast jeder kann sie lesen.

Wie es funktioniert, ist leicht zu erraten. Sie schreiben einen Zeitplan in /etc/crontab, /etc/cron.d/ oder crontab -e, und dann prüft der crond-Daemon jede Minute, ob Aufgaben ausgeführt werden müssen. Das Format ist zu einer universellen Sprache unter Systemadministratoren geworden:

# menit jam tanggal bulan hari command
0 3 * * * /usr/local/bin/backup.sh

Die obige Zeile bedeutet: „Führen Sie backup.sh alle 03:00 aus.“ Die ersten fünf Spalten sind Zeitangaben, der Rest sind Befehle. Ganz einfach, oder? Das ist die Hauptstärke von cron: Zero Ceremony. Es besteht keine Notwendigkeit, Unit-Dateien zu erstellen, Sie müssen sich keine Gedanken über Abhängigkeiten machen, und fast alle Distributionen haben es integriert.

Aber mit der Zeit entdeckte ich einige Einschränkungen, die mich zu stören begannen:

• Es gibt keine übersichtliche integrierte Protokollierung. Wenn die Aufgabe fehlschlägt, müssen Sie die Ausgabe selbst in eine Protokolldatei umleiten oder sich auf mail verlassen.
• Auf Ereignissen basierende Aufgaben können nicht ausgeführt werden. Cron erkennt nur die Zeit, keine Bedingungen wie „nachdem Dienst X aktiv ist“ oder „nach dem Neustart“.
• Die Verwaltung vieler Jobs wird chaotisch. Alles ist in einer Crontab-Datei gestapelt, es ist schwer, den Überblick zu behalten, wenn es Dutzende von Zeilen gibt.
• Es gibt keinen integrierten Wiederholungsmechanismus. Wenn der Befehl fehlschlägt, weil das Netzwerk vorübergehend ausgefallen ist, versucht cron es erst zum nächsten geplanten Zeitpunkt erneut.

systemd Timer: Ereignisbasierter moderner Zeitnehmer

Geben Sie systemd timer ein. Es ist kein absoluter Ersatz für cron, sondern eher eine funktionsreichere Alternative. Stellen Sie sich vor, dass cron der Alarm Ihres Telefons ist, während systemd timer ein intelligenter Assistent ist, der weiß, wann Sie schlafen und wann Sie aufwachen, und Aufgaben entsprechend den Umständen um Sie herum anpassen kann.

Der Timer in systemd arbeitet zusammen mit service unit. Sie erstellen zwei Dateien: eine für was getan wurde, eine andere für wann es getan wurde. Ein Beispiel sieht so aus:

# /etc/systemd/system/backup.service
[Unit]
Description=Backup harian server

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

# /etc/systemd/system/backup.timer
[Unit]
Description=Timer backup harian

[Timer]
OnCalendar=daily
Persistent=true

[Install]
WantedBy=timers.target

Dann aktivieren Sie es mit:

sudo systemctl daemon-reload
sudo systemctl enable --now backup.timer

Das Interessante an systemd timer ist seine Flexibilität. Zusätzlich zur Zeit können Sie Aufgaben basierend auf Folgendem auslösen:

• OnBootSec – wird einige Sekunden nach dem Booten ausgeführt.
• OnUnitActiveSec – wird eine bestimmte Zeit lang ausgeführt, nachdem die Einheit zuletzt aktiv war.
• OnFailure – wird ausgeführt, wenn andere Dienste ausfallen.
• OnCalendar – ähnlich wie cron, aber mit ausdrucksstärkerer Syntax.

Darüber hinaus stellt systemd journalctl direkt für die Protokollierung bereit. Sie müssen sich keine Gedanken mehr über manuelle Protokolldateien machen, geben Sie einfach Folgendes ein:

sudo journalctl -u backup.service -e

Direkter Vergleich: Cron vs. systemd Timer

Um es klarer zu machen, habe ich eine Vergleichstabelle basierend auf meinen Erfahrungen mit beiden auf dem Heimserver erstellt:

Wann ist es am besten, bei Cron zu bleiben?

Auch wenn es so klingt, als ob Cron veraltet ist, gibt es viele Situationen, in denen Cron immer noch die beste Wahl ist:

• Schnelles, temporäres Skript. Wenn Sie dies nur „drei Tage lang jede Stunde ausführen“ müssen, ist die Verwendung von crontab -e schneller als die Erstellung von zwei Unit-Dateien.
• Server ohne Systemd. Einige Minimaldistributionen wie Alpine oder bestimmte Container verwenden Systemd nicht.
• Zusammenarbeit mit verschiedenen Benutzern. Crons pro Benutzer sind für Server, die von vielen Personen verwaltet werden, recht intuitiv.
• Aufgaben, die keine komplizierte Protokollierung erfordern. Eine einfache Sicherung beispielsweise auf einem externen USB-Stick erfolgt einfach in einer eigenen Protokolldatei.

Wann sollte zum systemd-Timer gewechselt werden?

Andererseits beginnen systemd-Timer zu übernehmen, wenn Ihre Aufgaben komplexer werden:

• Sie benötigen einen automatischen Wiederholungsversuch. Beispielsweise schlägt die Synchronisierung mit dem Cloud-Speicher manchmal aufgrund von Zeitüberschreitungen fehl.
• Aufgaben müssen ausgeführt werden, nachdem bestimmte Dienste aktiv sind. Beispielsweise das Leeren des Caches nach dem Neuladen von Nginx.
• Sie möchten eine konsistente Protokollierung. Alle Protokolle an einem Ort über journalctl.
• Job steht in engem Zusammenhang mit Diensten, die von systemd verwaltet werden. Beispiel: Datenbanksicherung, die zuvor warten musste, bis MariaDB aktiv wurde.

Praktisches Beispiel: Wiederholbare automatische Sicherung

Stellen Sie sich vor, Sie haben ein Backup-Skript, das Daten über rsync an einen Remote-Server sendet. Manchmal ist das Netzwerk etwas wackelig und Backups schlagen fehl. Mit Cron müssen Sie auf den nächsten Zeitplan warten. Mit dem Systemd-Timer können Sie Wiederholungen hinzufügen:

# /etc/systemd/system/daily-backup.service
[Unit]
Description=Daily backup with retry

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup.sh
Restart=on-failure
RestartSec=5min

# /etc/systemd/system/daily-backup.timer
[Unit]
Description=Run daily backup at 2 AM

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

[Install]
WantedBy=timers.target

Wenn backup.sh bei dieser Konfiguration mit einem Fehlercode beendet wird, versucht systemd es alle 5 Minuten erneut. Viel eleganter als das Erstellen eines Wrapper-Bash-Skripts.

Also, was ist besser?

Die kurze Antwort: keine ist absolut besser. Cron und systemd timer sind zwei Tools für zwei unterschiedliche Anforderungen, obwohl ihre Hauptfunktion beide darin besteht, geplante Aufgaben auszuführen.

Wenn ich aus persönlicher Erfahrung schlussfolgern darf: Verwenden Sie cron für schnelle und temporäre Aufgaben, verwenden Sie systemd timer für Aufgaben, die Zuverlässigkeit und Integration mit anderen Diensten erfordern. Auf meinem eigenen Heimserver gibt es immer noch mehrere Crontab-Zeilen, die seit Jahren nicht geändert werden mussten, während ich neue Aufgaben dazu tendiere, systemd timer zu leiten, weil es einfacher zu überwachen ist.

Am wichtigsten ist es zu verstehen, wann ein Werkzeug lästig wird. Wenn Sie das Gefühl haben, dass Ihr Cron-Setup langsam mit Wrapper-Skripten, manuellen Protokollen und Hack-Wiederholungsversuchen gefüllt wird, ist das ein Zeichen dafür, dass es an der Zeit ist, den Systemd-Timer auszuprobieren.

Kommen Sie mit cron besser zurecht oder haben Sie mit der Migration auf systemd timer begonnen? Schreiben Sie in die Kommentarspalte, wenn Sie interessante Erfahrungen zum Taskplaner unter Linux haben. Wenn dieser Artikel nützlich ist, zögern Sie nicht, ihn zu teilen.