Linux-Aufgabenplanung: Vergleich von cron und systemd timer

Linux-Aufgabenplanung: Vergleich von cron und systemd timer

In der Verwaltung von Linux-Systemen ist das Wann einer Aufgabe genauso wichtig wie das Was ausgeführt wird. “Der langjährige Standard ist cron, während systemd-Timer in den meisten aktuellen Distributionen immer beliebter werden. In diesem Beitrag vergleichen wir beide und geben Hinweise, wann welcher Ansatz sinnvoll ist.

1. Warum sollte man cron und systemd timer vergleichen?

Viele Linux-Server haben ähnliche Anforderungen:

• Jeden Tag um 3 Uhr morgens ein Backup starten
• Alle 5 Minuten ein Health‑Check‑Skript ausführen
• Jeden Sonntag Log‑Archive komprimieren und bereinigen
• Nach dem Booten einmalig ein Initialisierungs‑Job ausführen

Traditionell wurden all diese Aufgaben mit cron erledigt, aber da die meisten Distributionen jetzt systemd als Standard‑Init‑System nutzen, sind systemd-Timer-Units eine starke Alternative.

2. Grundlegende Konzepte von cron

2.1 Was ist cron?

cron ist ein alter Unix/Linux‑Scheduler. Er führt Befehle zu festgelegten Zeiten oder Intervallen aus; konfiguriert wird das meist über crontab.

2.2 Wo werden cron‑Einstellungen gespeichert?

• Systemweit: /etc/crontab, /etc/cron.d/
• Benutzerbezogen: per‑User‑crontab über crontab -e

Beispiel: Jeden Tag um 3 Uhr morgens ein Backup‑Skript ausführen:

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

Die Felder bedeuten:

Minute Stunde Tag Monat Wochentag Befehl
0     3     *     *     *     /usr/local/bin/backup.sh

2.3 Vorteile von cron

• Alt, bewährt und zuverlässig
• Einheitliches Konzept auf fast allen Unix/Linux‑Systemen
• Einfache Syntax, viele Beispiele verfügbar
• Auch auf Systemen ohne systemd nutzbar

2.4 Einschränkungen von cron

• Trennung von Service und Scheduler erschwert die Zuordnung
• Status‑ und Log‑Überwachung ist unhandlich (syslog, Mail, etc.)
• Abhängigkeiten (z. B. Netzwerk muss laufen) werden nicht direkt unterstützt
• Relativzeit-Pläne wie „5 Minuten nach dem Boot“ sind umständlich.

3. Grundlegende Konzepte von systemd timer

3.1 Was ist ein systemd timer?

systemd timer ist die Timer‑Unit von systemd. Sie startet einen anderen systemd‑Service unter bestimmten Bedingungen (Zeit, Boot‑Zeit, etc.).

Die Struktur besteht immer aus zwei Einheiten:

• myjob.service – definiert, was ausgeführt wird
• myjob.timer – definiert, wann es ausgeführt wird

3.2 Beispiel: Service + Timer

(1) Service‑Unit: /etc/systemd/system/backup.service

[Unit]
Description=Daily backup job

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

(2) Timer‑Unit: /etc/systemd/system/backup.timer

[Unit]
Description=Run daily backup at 3:00

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

[Install]
WantedBy=timers.target

Aktivierung:

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

3.3 Vorteile von systemd timer

• Klare Zuordnung zu einem Service
• Einfache Log‑Abfrage mit journalctl -u backup.service
• Flexible Trigger‑Bedingungen:
• OnCalendar= – cron‑ähnliche Zeitangaben
• OnBootSec= – X Sekunden nach dem Boot
• OnUnitActiveSec=, OnUnitInactiveSec= – Zeit seit letztem Lauf
• Abhängigkeiten lassen sich mit After=, Requires= etc. definieren
• Vollständige Integration in das systemd‑Ökosystem (systemctl list-timers, systemctl status)

3.4 Nachteile von systemd timer

• Lernkurve höher als bei cron (Service + Timer nötig)
• Abhängig von systemd – nicht auf sehr alten oder non‑systemd Systemen
• Für einfache, einzeilige Aufgaben kann es „übertrieben“ wirken

4. Funktionsvergleich

5. Praxisbeispiele

5.1 Tägliches Backup um 3 Uhr: cron vs timer

cron‑Version

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

systemd‑Timer‑Version

# backup.service
[Unit]
Description=Daily backup job

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

# backup.timer
[Unit]
Description=Run daily backup at 3:00

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

[Install]
WantedBy=timers.target

5.2 Einmalig 5 Minuten nach dem Boot

Bei cron muss man Tricks wie @reboot + sleep oder rc.local einsetzen.

systemd‑Timer‑Implementierung

# init-job.service
[Unit]
Description=Run custom init job after boot

[Service]
Type=oneshot
ExecStart=/usr/local/bin/init-job.sh

# init-job.timer
[Unit]
Description=Run init job 5 minutes after boot

[Timer]
OnBootSec=5min
AccuracySec=1min

[Install]
WantedBy=timers.target

Damit startet init-job.service genau 5 Minuten nach dem Boot.

6. Wann welcher Ansatz wählen?

6.1 Cron bleibt sinnvoll

• Viele bestehende cron‑Jobs laufen bereits zuverlässig
• Nur wenige, sehr einfache Aufgaben
• Nicht systemd‑basierte Umgebungen (Container, BSD, sehr alte OS)

6.2 systemd timer ist die bessere Wahl

• Die meisten Services laufen bereits unter systemd
• Zentrale Log‑ und Statusverwaltung gewünscht
• Relativ‑zeitbasierte Schedules (Boot‑Zeit, Zeit seit letztem Lauf) nötig
• Abhängigkeiten zu anderen Services (z. B. Netzwerk, Datenbank) wichtig
• CI/CD‑Pipelines oder Produktionsumgebungen, die konsistente Observability benötigen

7. Tipps zum Migrieren von cron zu systemd timer

1. Aktuelle cron‑Liste erfassen * crontab -l * /etc/crontab, /etc/cron.d/*
2. Auf Service + Timer aufteilen * Was auszuführen ist → .service * Wann auszuführen ist → .timer
3. Zeit‑Ausdrücke konvertieren * 0 3 * * * → OnCalendar=*-*-* 03:00:00 * */5 * * * * → OnCalendar=*:0/5
4. Testen * systemctl start myjob.service * systemctl start myjob.timer → systemctl list-timers
5. Alte cron‑Einträge deaktivieren * Sobald der Timer stabil läuft, Kommentar setzen oder löschen

8. Fazit: Beide können koexistieren

Kurz gesagt:

• cron ist nach wie vor ein einfacher, portabler Scheduler
• systemd timers bietet Service‑orientierte Verwaltung, Observability und flexible Trigger

Es gibt keine eindeutige „richtige“ Wahl. Für neue, service‑nahe Aufgaben empfiehlt sich systemd timer, während bestehende cron‑Jobs ohne Aufwand weiterlaufen können.