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?
- Schritt 1: Die Service-Unit anlegen
- Schritt 2: Die Timer-Unit anlegen
- Die OnCalendar-Syntax
- Schritt 3: Timer aktivieren und prüfen
- Last verteilen mit RandomizedDelaySec
- Häufige Fragen
- Muss ich für jeden Timer eine eigene Service-Datei anlegen?
- Wann sollte ich lieber bei Cron bleiben?
- Wie sehe ich, ob ein Timer korrekt läuft?
- Fazit
Warum systemd-Timer statt Cron?
systemd-Timer haben gegenüber klassischen Cronjobs einige Vorteile:
- Logging inklusive: Jeder Lauf landet im Journal und ist per
journalctlnachvollziehbar. - 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.shType=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.targetOnCalendar 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-Wert | Bedeutung |
|---|---|
*-*-* 02:00:00 | Täglich um 2 Uhr |
Mon *-*-* 08:00:00 | Jeden Montag um 8 Uhr |
*-*-01 00:00:00 | Am 1. jedes Monats |
hourly | Zu jeder vollen Stunde |
*:0/15 | Alle 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.timerAlle aktiven Timer und ihre nächste Ausführung zeigt dir:
systemctl list-timersDen 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=trueMit 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.

