systemd-Timer erstellen: die moderne Cron-Alternative

Wiederkehrende Aufgaben steuert man unter Linux traditionell per Cron. Moderne Systeme bieten mit systemd-Timern aber eine mächtigere Alternative: mit Logging, Abhängigkeiten und flexibler Zeitsteuerung. In dieser Anleitung erstellst du einen systemd-Timer Schritt für Schritt und erfährst, wann er die bessere Wahl gegenüber einem Cronjob ist.

Warum systemd-Timer statt Cron?

systemd-Timer haben gegenüber klassischen Cronjobs einige Vorteile:

  • Logging inklusive: Jeder Lauf landet im Journal und ist per journalctl nachvollziehbar.
  • Verpasste Läufe nachholen: War der Rechner aus, kann der Timer die Aufgabe beim Start nachholen (Persistent=true).
  • Abhängigkeiten: Timer können auf andere Dienste oder das Netzwerk warten.
  • Einfaches Testen: Der zugehörige Dienst lässt sich jederzeit manuell starten.

Schritt 1: Die Service-Unit anlegen

Ein Timer braucht immer einen zugehörigen Dienst, der die eigentliche Arbeit macht. Lege ihn unter /etc/systemd/system/ an:

sudo nano /etc/systemd/system/backup.service
[Unit]
Description=Tägliches Backup-Skript

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

Type=oneshot ist für Aufgaben gedacht, die einmal laufen und sich dann beenden. Das ausgeführte Bash-Skript muss ausführbar sein.


Schritt 2: Die Timer-Unit anlegen

Der Timer trägt denselben Namen wie der Dienst, nur mit der Endung .timer:

sudo nano /etc/systemd/system/backup.timer
[Unit]
Description=Startet das Backup täglich

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

[Install]
WantedBy=timers.target

OnCalendar legt den Zeitpunkt fest – hier täglich um 2 Uhr. Persistent=true holt einen verpassten Lauf nach, falls der Rechner zur geplanten Zeit aus war.


Die OnCalendar-Syntax

Die Zeitangaben sind flexibel. Einige Beispiele:

OnCalendar-WertBedeutung
*-*-* 02:00:00Täglich um 2 Uhr
Mon *-*-* 08:00:00Jeden Montag um 8 Uhr
*-*-01 00:00:00Am 1. jedes Monats
hourlyZu jeder vollen Stunde
*:0/15Alle 15 Minuten

Schritt 3: Timer aktivieren und prüfen

Lade systemd neu, aktiviere und starte den Timer:

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

Alle aktiven Timer und ihre nächste Ausführung zeigt dir:

systemctl list-timers

Den Dienst kannst du zum Testen jederzeit direkt auslösen: sudo systemctl start backup.service. Die Ausgabe findest du dann im Journal – siehe Logs mit journalctl auswerten.


Last verteilen mit RandomizedDelaySec

Laufen auf vielen Servern Timer zur exakt gleichen Uhrzeit, kann das zu Lastspitzen führen – etwa wenn alle gleichzeitig ein Backup starten. Mit RandomizedDelaySec im [Timer]-Abschnitt streust du den Start zufällig über ein Zeitfenster:

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

Mit dem Wert 1800 startet der Timer irgendwann in den 30 Minuten nach 2 Uhr – das entzerrt die Last spürbar.


Häufige Fragen

Muss ich für jeden Timer eine eigene Service-Datei anlegen?

Ja, ein Timer steuert immer eine zugehörige Service-Unit. Beide tragen denselben Namen (z. B. backup.timer und backup.service), sodass systemd sie automatisch verknüpft.

Wann sollte ich lieber bei Cron bleiben?

Für einfache, schnelle Zeitpläne ist ein Cronjob mit einer Zeile schneller eingerichtet. systemd-Timer lohnen sich, sobald du Logging, Nachholen verpasster Läufe oder Abhängigkeiten brauchst.

Wie sehe ich, ob ein Timer korrekt läuft?

systemctl list-timers zeigt die nächste geplante Ausführung, und journalctl -u backup.service zeigt die Protokolle der bisherigen Läufe.


Fazit

systemd-Timer sind die moderne, mächtige Alternative zu Cron: mit integriertem Logging, dem Nachholen verpasster Läufe und flexibler OnCalendar-Syntax. Der Aufbau aus Service- und Timer-Unit ist schnell verstanden. Für anspruchsvolle Automatisierungen sind sie die sauberere Lösung – für schnelle Einzeiler bleibt Cron weiter praktisch.

Siehe auch  Proxmox VE 8 auf 9 upgraden (Debian Trixie)
Nach oben scrollen