Systemd-Timer vs. Cron: Den richtigen Scheduler wählen

Wenn dein Linux-Server regelmäßig ein Backup, eine Bereinigung, einen Health-Check oder einen Bericht ausführen muss, hast du normalerweise die Wahl zwischen cron und systemd-Timern. Cron ist immer noch einfach und portabel. Systemd-Timer passen besser, wenn sich der Job wie ein verwalteter Dienst verhält und Protokolle, Abhängigkeiten oder Ressourcenkontrollen benötigt.

Die richtige Wahl hängt von der Maschine ab, auf der du läufst, vom Fehlerverhalten des Jobs und davon, wie viel operative Transparenz du benötigst.

Cron-Jobs verstehen

cron ist ein zeitbasierter Job-Scheduler in Unix-ähnlichen Betriebssystemen. Es ermöglicht Benutzern, Befehle oder Skripte zu planen, die regelmäßig zu festgelegten Zeiten, Daten oder Intervallen ausgeführt werden. Der cron-Daemon (crond) läuft im Hintergrund und überprüft die Crontab-Dateien auf geplante Jobs.

Wie Cron funktioniert

Jeder Benutzer kann seine eigene Crontab-Datei haben, die mit dem Befehl crontab verwaltet wird. Systemweite Jobs werden normalerweise in /etc/crontab oder in Dateien innerhalb von /etc/cron.d/ konfiguriert.

Ein Crontab-Eintrag folgt einem bestimmten Format:

* * * * * auszuführender_befehl
│ │ │ │ │
│ │ │ │ └───── Wochentag (0 - 6) (Sonntag=0 oder 7)
│ │ │ └─────── Monat (1 - 12)
│ │ └───────── Tag des Monats (1 - 31)
│ └─────────── Stunde (0 - 23)
└───────────── Minute (0 - 59)

Beispiel: Um ein Backup-Skript jeden Tag um 2:00 Uhr auszuführen:

0 2 * * * /usr/local/bin/backup.sh

Vorteile von Cron

Allgegenwärtig: Verfügbar auf praktisch allen Unix-ähnlichen Systemen.
Einfache Syntax: Das Crontab-Format ist für die grundlegende Planung relativ einfach zu erlernen.
Benutzerspezifische Jobs: Einfach, Jobs für einzelne Benutzer einzurichten.

Nachteile von Cron

Begrenzte Flexibilität: Hauptsächlich auf feste Zeitintervalle basiert. Die Handhabung komplexer Abhängigkeiten oder ereignisgesteuerter Planung ist schwierig.
Kein Abhängigkeitsmanagement: Kann nicht einfach definieren, dass ein Job erst ausgeführt werden soll, nachdem ein anderer Job erfolgreich abgeschlossen wurde.
Keine Ressourcenkontrolle: Bietet wenig bis gar keine Kontrolle über die Ressourcen (CPU, Speicher), die von geplanten Jobs verbraucht werden.
Protokollierung und Überwachung: Verlässt sich oft auf Mail-Ausgabe, Syslog oder explizite Umleitung im Befehl.
Unit-Datei-Integration: Nicht direkt in die Dienstverwaltungsfunktionen von systemd integriert.

Systemd-Timer verstehen

systemd-Timer sind eine fortschrittlichere und flexiblere Möglichkeit, Aufgaben zu planen, die die Leistungsfähigkeit der systemd-Unit-Dateien nutzen. Anstelle eines separaten Daemons werden systemd-Timer als Teil des systemd-Init-Systems selbst verwaltet.

Wie Systemd-Timer funktionieren

systemd-Timer bestehen aus zwei Unit-Dateien:

Service-Unit (.service): Definiert die auszuführende Aufgabe oder den Befehl.
Timer-Unit (.timer): Definiert, wann die entsprechende Service-Unit aktiviert werden soll.

Diese Dateien werden normalerweise in /etc/systemd/system/ oder ~/.config/systemd/user/ abgelegt.

Beispiel: Planung eines Bereinigungsskripts, das täglich um 3:00 Uhr ausgeführt wird.

Erstelle zuerst die Service-Datei (cleanup.service):

# /etc/systemd/system/cleanup.service

[Unit]
Description=Tägliche Bereinigungsaufgabe

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

Erstelle als Nächstes die Timer-Datei (cleanup.timer):

# /etc/systemd/system/cleanup.timer

[Unit]
Description=Bereinigungsaufgabe täglich ausführen

[Timer]
# 25 Minuten nach dem Booten ausführen, dann täglich um 3 Uhr morgens
OnBootSec=25min
OnCalendar=*-*-* 03:00:00
# Alternative: 24 Stunden nach der letzten Ausführung
# OnUnitActiveSec=24h

[Install]
WantedBy=timers.target

Nachdem du diese Dateien erstellt hast, lade systemd neu, aktiviere den Timer für zukünftige Bootvorgänge und starte ihn jetzt:

sudo systemctl daemon-reload
sudo systemctl enable cleanup.timer
sudo systemctl start cleanup.timer

Du kannst den Status des Timers und den Zeitpunkt seiner nächsten Auslösung überprüfen mit:

sudo systemctl status cleanup.timer

Wichtige `systemd`-Timer-Direktiven:

OnCalendar=: Gibt eine Kalenderereigniszeit an (ähnlich der Cron-Syntax, aber leistungsfähiger).
- *-*-* 03:00:00: Täglich um 3 Uhr morgens.
- Mon..Fri *-*-* 09:00:00: An Wochentagen um 9 Uhr morgens.
- hourly: Jede Stunde.
- daily: Einmal am Tag.
- weekly: Einmal pro Woche.
- monthly: Einmal im Monat.
- yearly: Einmal im Jahr.
OnBootSec=: Löst eine bestimmte Zeit nach dem Systemstart aus.
OnUnitActiveSec=: Löst eine bestimmte Zeit nach der letzten Aktivierung der entsprechenden Unit (des Dienstes) aus.
OnUnitInactiveSec=: Löst eine bestimmte Zeit aus, nachdem die entsprechende Unit (der Dienst) inaktiv geworden ist.
AccuracySec=: Wie genau der Timer sein muss. Niedrigere Werte können mehr Strom verbrauchen.
Persistent=: Bei Kalender-Timern weist true systemd an, aufzuholen, wenn eine geplante Ausführung verpasst wurde, während der Timer inaktiv war, z. B. wenn die Maschine ausgeschaltet war.

Vorteile von Systemd-Timern

Integration mit systemd: Nahtlose Integration in die Dienstverwaltung, Protokollierung (journalctl), Ressourcenkontrolle und das Abhängigkeitsmanagement von systemd.
Flexibilität: Unterstützt verschiedene Planungsoptionen über feste Intervalle hinaus, einschließlich Kalenderereignissen, relativen Zeiten nach dem Booten und relativen Zeiten nach der vorherigen Aktivierung.
Abhängigkeitsmanagement: Kann Abhängigkeiten von anderen systemd-Units definieren (z. B. Netzwerkverfügbarkeit).
Ressourcenkontrolle: Kann die cgroups von systemd zur Ressourcenbegrenzung (CPU, Speicher) nutzen.
Protokollierung: Integriert mit journald für eine umfassende und zentralisierte Protokollierung.
Fehlerbehandlung: Kann Service-Unit-Verhalten wie Restart=, OnFailure= und Abhängigkeitsreihenfolge verwenden, wo diese Muster zum Job passen.
Zustandsbewusstsein: Kann nachverfolgen, wann ein Job hätte ausgeführt werden sollen, und ihn beim Systemstart ausführen, wenn Persistent=true gesetzt ist.

Nachteile von Systemd-Timern

Steilere Lernkurve: Die Syntax und die Konzepte der systemd-Unit-Dateien können für Anfänger komplexer sein als cron.
Systemd-Abhängigkeit: Erfordert ein System, das systemd ausführt (die meisten modernen Linux-Distributionen tun dies).

Systemd-Timer vs. Cron: Wichtige Unterschiede zusammengefasst

Merkmal	Cron-Jobs	Systemd-Timer
Verwaltung	`crontab`-Befehl, Systemdateien	`systemctl`-Befehl, Unit-Dateien
Planung	Feste Minute, Stunde, Tag, Monat, Wochentag	Kalenderereignisse, relative Zeiten, bootbasiert
Integration	Eigenständiger Daemon	Integriert mit `systemd`
Protokollierung	Mail, Skript-Umleitung	`journald`
Abhängigkeiten	Keine	`systemd`-Unit-Abhängigkeiten
Ressourcenkontrolle	Keine	`systemd`-cgroups
Fehlerbehandlung	Einfach	Service-Unit-Fehlerbehandlung
Zustandsverfolgung	Eingeschränkt	`Persistent=`-Option
Komplexität	Einfacher für grundlegende Aufgaben	Leistungsfähiger, steilere Lernkurve

Wann welcher Scheduler gewählt werden sollte

Wähle Cron, wenn:

Du dich auf einem sehr alten oder minimalistischen System befindest, das kein systemd verwendet.
Du eine sehr einfache, einmalige Aufgabe mit einem festen, wiederkehrenden Zeitplan planen musst und Einfachheit über erweiterte Funktionen stellst.
Du eine schnelle Planung für einen Befehl benötigst, der bereits seine eigene Protokollierung und Fehlerbehandlung übernimmt.

Wähle Systemd-Timer, wenn:

Du dich auf einer modernen Linux-Distribution befindest, die systemd verwendet.
Du mehr Kontrolle darüber benötigst, wann ein Job läuft (z. B. relativ zum Booten, relativ zum letzten Lauf, nachdem das Netzwerk verfügbar ist).
Du eine bessere Protokollierung, Überwachung und Fehlerbehandlung benötigst.
Du die Jobausführung mit den leistungsstarken Dienstverwaltungsfunktionen von systemd verwalten möchtest, einschließlich Ressourcenkontrolle und Abhängigkeitsmanagement.
Du bereits andere Dienste mit systemd verwaltest und einen konsistenten Ansatz für die Planung wünschst.
Deine Aufgaben Abhängigkeiten von anderen Systemdiensten oder Ereignissen haben.

Praktische Faustregel

Verwende Cron, wenn der Job ein kurzer, offensichtlicher Befehl ist und Portabilität wichtig ist. Verwende einen systemd-Timer, wenn der Job Teil eines Dienstes ist, journalctl-Protokolle benötigt, auf das Netzwerk warten soll oder von Ressourcenbeschränkungen und Abhängigkeitsreihenfolge profitiert.

Ein nächtliches Backup ist ein gutes Beispiel. Auf einem kleinen Legacy-Server reicht möglicherweise 0 2 * * * /usr/local/bin/backup.sh. Auf einem systemd-basierten Produktionshost bietet eine backup.service plus backup.timer einen klareren Status, Protokolle, Boot-Nachholung mit Persistent=true und einen saubereren Weg, später Abhängigkeiten hinzuzufügen.