Du willst wiederkehrende Jobs zuverlässig planen und leichter prüfen? Dann ist ein systemd Timer die passende Cron Alternative. Statt verstreuter Crontabs nutzt du Units, die sauber in systemd eingebunden sind. So behältst du Linux zeitgesteuerte Aufgaben, Logs und Abhängigkeiten an einem Ort im Griff.
Ein Timer startet zu festen Zeiten eine Service-Unit. Das macht Wartung und Debugging einfacher. Du arbeitest mit OnCalendar für gut lesbare Zeitangaben und kontrollierst alles mit systemctl. Für die Auswertung nutzt du journalctl und profitierst davon, dass timers.target Timer beim Booten lädt.
In diesem Artikel lernst du Schritt für Schritt, wie du systemd timer statt cron verwenden kannst. Du siehst konkrete Dateien unter /etc/systemd/system/, bekommst klare Shell-Beispiele und verstehst, wie du Timer sicher startest, aktivierst und überwachst. Kurz: Du bringst deine Automatisierung auf einen modernen, stabilen Stand.
Die Wichtigstens Befehle in Kürze:
# Service-Datei anlegen (z. B. /etc/systemd/system/backup.service)
sudo tee /etc/systemd/system/backup.service
[Unit]
Description=Backup Job (Daily)
[Service]
Type=oneshot
ExecStart=/usr/bin/rsync -a /home/ /backup/
# Timer-Datei anlegen (z. B. /etc/systemd/system/backup.timer)
sudo tee /etc/systemd/system/backup.timer
[Unit]
Description=Daily Backup Timer
[Timer]
OnCalendar=*-*-* 02:00:00
Persistent=true
Unit=backup.service
[Install]
WantedBy=timers.target
# Systemd neu laden, damit neue Units erkannt werden
sudo systemctl daemon-reload
# Timer starten und beim Boot aktivieren
sudo systemctl start backup.timer
sudo systemctl enable backup.timer
# Aktive Timer anzeigen (NEXT, LAST, ACTIVATES)
systemctl list-timers
systemctl list-timers | less
# Einzelnen Timer-Status prüfen
systemctl status backup.timer
# Zugehörigen Service-Status prüfen
systemctl status backup.service
# Logs des Service anzeigen (komplett oder live)
journalctl -u backup.service
journalctl -u backup.service -f
# Fehleranalyse: Letzte Ausführung prüfen
journalctl -u backup.service | tail -n 20
# Timer deaktivieren oder löschen
sudo systemctl stop backup.timer
sudo systemctl disable backup.timer
sudo rm /etc/systemd/system/backup.{service,timer}
sudo systemctl daemon-reload
# Beispiel: Reminder-Service stündlich ausführen
sudo tee /etc/systemd/system/reminder.service
[Unit]
Description=Hourly Reminder
[Service]
Type=oneshot
ExecStart=/usr/bin/echo "$(date) Reminder läuft" >> /home/user/reminder.log
sudo tee /etc/systemd/system/reminder.timer
[Unit]
Description=Hourly Reminder Timer
[Timer]
OnCalendar=hourly
Persistent=true
Unit=reminder.service
[Install]
WantedBy=timers.target
sudo systemctl daemon-reload
sudo systemctl enable --now reminder.timer
# Reminder prüfen
systemctl list-timers | grep reminder
journalctl -u reminder.service | tail -n 5
tail -n 5 /home/user/reminder.logWarum systemd-Timer die modernere Alternative zu Cron sind
Wenn du Tasks planst, zählt Cron vs systemd heute mehr denn je. systemd-Timer greifen direkt in den Service-Manager ein und sind damit eine echte Cron Alternative Linux. Du profitierst von konsistenter Verwaltung, klarer Trennung von Zuständigkeiten und sauberem Startverhalten beim Booten über timers.target.
Vorteile: Zuverlässigkeit, Logging, Integration in systemd
Systemd-Timer starten Jobs zuverlässig, auch nach Reboots. Durch systemd Logging landen Ausgaben nicht verstreut, sondern zentral im Journal. Mit journalctl Timer und den Unit-Logs siehst du Ursachen, Laufzeit und Exit-Codes an einer Stelle.
Die Integration ist nahtlos: Timer gehören zum Abhängigkeitsbaum, werden über Targets geladen und verhalten sich wie andere Units. Mit systemctl list-timers prüfst du NEXT, LAST und ACTIVATES ohne Zusatztools.
Timer- und Service-Kopplung: .timer aktiviert .service
Ein .timer ruft immer eine .service-Unit auf. Das sorgt für klare Grenzen: Die .service-Datei definiert die Ausführung, etwa Type=oneshot und ExecStart, der Timer nur das Wann. So bleiben Updates, Reloads und Restart-Strategien nachvollziehbar und robust.
Praxisfreundlich ist auch die Fehleranalyse: Mit journalctl -u name.service siehst du alle Läufe des Jobs, statt einzelne Cron-Mails zu sammeln. Diese Kopplung erleichtert Reviews und Audits erheblich.
Bessere Lesbarkeit durch OnCalendar statt Cron-Syntax
Die OnCalendar Syntax ist deutlich lesbarer als kryptische Cron-Zeilen. Angaben wie OnCalendar=Mon 08:00, hourly oder *-*-* 02:00:00 erklären sich selbst. Für schnelle Tests helfen kurze Intervalle, die du mit klaren Zeitmustern definierst.
Damit gewinnst du Wartbarkeit: Neue Teammitglieder verstehen Regeln ohne Nachschlagen, und du vermeidest Tippfehler. Das macht den Alltag mit journalctl Timer und systemd Logging leichter und stärkt den Fall Cron vs systemd zugunsten moderner Tools.
Grundlagen: Was ist ein systemd Timer und wie funktioniert er?
Ein Timer in systemd startet Dienste zu festen Zeiten, ohne dass du Cron brauchst. Die systemd Pfade und die klare Struktur helfen dir, Jobs sauber zu trennen. Du arbeitest dabei mit einer systemd .timer Unit, die eine passende systemd .service Datei auslöst.
Die .timer-Unit: Aufbau und Beziehung zu .service
Der Name passt zusammen: backup.timer aktiviert backup.service. So bleibt der Zweck sofort erkennbar. Für kurze Aufgaben nutzt du im Service meist Type=oneshot, damit der Job startet, läuft und wieder endet. Der Timer bleibt aktiv und kümmert sich nur um den Startzeitpunkt.
Wichtige Direktiven: OnCalendar, Persistent, WantedBy
Die Zeit legst du mit OnCalendar fest. Lesbare OnCalendar Beispiele wie Mon 08:00, hourly oder *-*-* 02:00:00 machen den Plan transparent. Mit Persistent=true holt der Timer verpasste Läufe nach, wenn der Rechner zur geplanten Zeit aus war.
Damit der Timer beim Boot startet, setzt du im Install-Abschnitt WantedBy=timers.target. So wird die systemd .timer Unit sauber in den Boot-Prozess eingebunden und bleibt unabhängig von Benutzer-Sessions.
Beispielpfade: /etc/systemd/system/*.timer und *.service
Systemweite Units liegen unter /etc/systemd/system. Typisch sind Dateien wie /etc/systemd/system/backup.timer und /etc/systemd/system/backup.service. Diese systemd Pfade sind klar getrennt, leicht versionierbar und lassen sich bei Bedarf schnell anpassen.
systemd timer statt cron verwenden
Wenn du systemd timer statt cron verwenden willst, halte dich an einen klaren Ablauf: Lege zuerst eine .service-Unit für die eigentliche Aufgabe an und koppel sie mit einer .timer-Unit. Beide Dateien teilen sich denselben Basisnamen, damit der systemctl timer die zugehörige Service-Datei automatisch startet. Das hilft dir, Cron ersetzen ohne Brüche umzusetzen und die crontab Migration sauber zu halten.
Der Vorteil beim OnCalendar Umstieg liegt in der Lesbarkeit und in stabilen Abläufen. OnCalendar=Mon 08:00 spricht für sich und ersetzt fragile Cron-Ausdrücke. Mit Persistent=true holt der Timer verpasste Läufe nach, etwa nach einem Reboot. Deine Logs bleiben über journalctl -u klar nachvollziehbar, während systemctl list-timers dir die nächsten Termine zeigt.
Nach dem Erstellen der Units lädst du den Manager neu und aktivierst den Timer sofort. Prüfe Ausgaben bequem mit systemctl list-timers | less, wenn sie lang werden. Für Syntaxdetails helfen die Handbuchseiten zu systemd.timer und systemd.time, und für sauberes Arbeiten beachtest du Pfade sowie Berechtigungen unter /etc/systemd/system. So gelingt die Crontab Migration schlank, und du kannst dauerhaft systemd timer statt cron verwenden.
Praxisbeispiel: Tägliches Backup mit Timer und Service einrichten
Du richtest ein tägliches Backup mit systemd ein, damit dein inkrementelles Backup Linux planbar und robust läuft. Der Ablauf koppelt Service und Timer, nutzt OnCalendar täglich und profitiert von einem Persistent Timer, der verpasste Läufe nachholt.
Service-Datei anlegen: /etc/systemd/system/backup.service
Die Unit führt den Kopiervorgang aus und bleibt schlank. Type=oneshot passt, weil der Job genau einmal pro Trigger läuft. Setze absolute Pfade und achte auf Berechtigungen unter /home und /etc, damit backup.service konsistent arbeitet.
Timer-Datei anlegen: /etc/systemd/system/backup.timer
Der Timer plant die Ausführung um 02:00 Uhr. OnCalendar täglich ist leicht lesbar, und ein Persistent Timer sorgt dafür, dass nach einem Ausfall der nächste Start den Run nachzieht. Über timers.target bindest du die Planung zuverlässig an den Boot-Prozess.
Shell-Befehle: daemon-reload, start, enable
Nach Änderungen lädst du Units neu, startest den Zeitgeber und schaltest ihn für den Boot ein. Mit systemctl enable timer bleibt backup.timer dauerhaft aktiv, während du den Status mit systemctl list-timers und die Ausgaben von backup.service im Journal prüfst.
Beispiel: rsync für inkrementelle Backups
Mit rsync Backup systemd nutzt du bewährte Tools effizient. Der Basisaufruf mit -a bewahrt Rechte und Zeiten. Optional verlinkst du eine aktuelle Generation und schreibst Datumsordner, um ein echtes inkrementelles Backup Linux zu erhalten, ohne die Übersicht zu verlieren.
OnCalendar im Detail: flexible Zeitangaben für wiederkehrende Tasks
Mit OnCalendar steuerst du Abläufe präzise und gut lesbar. Die systemd.time Syntax erlaubt dir klare Angaben für tägliche, wöchentliche und stündliche Abläufe, ohne kryptische Muster. So entstehen OnCalendar Beispiele, die du später leicht wartest und schnell verstehst, auch im Cron Syntax Vergleich.
Täglich, wöchentlich, stündlich: Beispiele für OnCalendar
Für einen täglichen Lauf um 02:00 nutzt du OnCalendar=*-*-* 02:00:00. Ein wöchentlicher Timer am Montag um 08:00 sieht so aus: OnCalendar=Mon 08:00. Einfache stündliche Timer erreichst du mit OnCalendar=hourly. Diese OnCalendar Beispiele zeigen, wie die systemd.time Syntax klare, kurze Patterns bereitstellt.
Testen mit kurzen Intervallen (jede Minute)
Zum Überprüfen eignet sich ein jede Minute Timer mit OnCalendar=*:*:0/60. Schreibe Ausgaben mit >> in eine Logdatei und nutze absolute Pfade, damit der Test stabil läuft. Für Details hilft dir man systemd.time oder eine Ansicht mit man systemd.time | less, wenn die Ausgabe lang ist.
Lesbare Patterns vs. Cron-Ausdrücke
Die OnCalendar Beispiele setzen auf Wörter wie Mon oder hourly und wirken dadurch sofort verständlich. Im Cron Syntax Vergleich entfallen Sternreihen und Positionsrätsel; die systemd.time Syntax spricht Klartext. So bleibt ein wöchentlicher Timer, ein stündlicher Timer oder ein jede Minute Timer auch nach Monaten noch intuitiv.
Überwachen und Debuggen: Timer-Status und Logs prüfen
Wenn ein automatischer Task hakt, hilft dir ein klarer Blick auf Status und Protokolle. Für sauberes systemd Monitoring schaust du zuerst auf die Timer-Liste und danach in die journalctl Service Logs. So erkennst du schnell, ob die Ausführung planmäßig lief und wo Timer Debugging ansetzen muss.
Aktive Timer listen: systemctl list-timers
Mit systemctl list-timers siehst du auf einen Blick, welche Units aktiv sind und wann sie laufen. Die Spalten NEXT, LEFT, LAST und PASSED zeigen dir nächste Ausführung, verbleibende Zeit, letzte Ausführung und verstrichene Dauer. UNIT und ACTIVATES verraten, welcher .timer welche .service startet, etwa backup.timer aktiviert backup.service. Für lange Listen hilft die Paginierung mit systemctl list-timers | less.
Journal-Logs anzeigen: journalctl -u
Die journalctl Service Logs geben dir die ganze Ausführungsgeschichte einer Unit. Mit journalctl -u backup.service liest du Start, Ende und eventuelle Fehler. Für Live-Ansicht nutzt du journalctl -u backup.service -f und verfolgst den Lauf in Echtzeit. Das beschleunigt Timer Debugging, weil du Ursachen sofort siehst und Änderungen gezielt prüfen kannst.
Letzte und nächste Ausführung interpretieren
Vergleiche die Felder NEXT LAST PASSED mit deiner OnCalendar-Angabe. Weichen Zeiten ab, gab es oft Downtime oder eine geänderte Planung. Mit Persistent=true holt der Timer verpasste Läufe nach; das erkennst du an dicht aufeinander folgenden Einträgen in den Logs. Läuft gar nichts, prüfe den Enable-Status des Timers und lade Änderungen mit einem erneuten Daemon-Reload.
Für Detailoptionen helfen dir die Handbuchseiten von systemd.timer, journalctl und systemctl sowie die Kurzinfos per –help. So baust du eine verlässliche Routine für systemd Monitoring auf und behältst Status, Historie und nächste Ausführung sicher im Blick.
Übung: Reminder-Service stündlich ausführen und verpasste Läufe nachholen
In dieser systemd Übung richtest du einen kleinen Reminder ein, der jede Stunde läuft und eine Zeile in /home/user/reminder.log schreibt. Du legst dazu einen Service mit dem Namen reminder.service an und koppelst ihn mit einem hourly Timer über reminder.timer. So nutzt du systemd timer statt cron verwenden und bekommst zugleich sauberes Logging sowie eine klare Trennung von Ausführung und Zeitplan.
Der Service arbeitet als Type=oneshot und ruft /usr/bin/echo mit einem Zeitstempel auf. Der Timer nutzt OnCalendar=hourly und setzt Persistent=true. Dieses Persistent Timer Beispiel sorgt dafür, dass verpasste Läufe nachgeholt werden, wenn der Rechner zwischenzeitlich aus war. Nach einem daemon-reload aktivierst du reminder.timer sofort, damit der Plan greift und der nächste Stundentakt nicht verpasst wird.
Zur Kontrolle listest du aktive Einträge mit systemctl list-timers und filterst bei Bedarf nach reminder. Die Ausführung selbst prüfst du mit journalctl -u reminder.service, bei großen Ausgaben bequem mit less. Der Inhalt der Logdatei zeigt sich mit tail -n 5 /home/user/reminder.log. Achte auf absolute Pfade, korrekte Rechte im Zielverzeichnis und die Umleitung mit >>, damit die Datei fortlaufend wächst.
Damit hast du die Kernelemente im Griff: OnCalendar=hourly korrekt verwenden, verpasste Starts durch Persistent=true aufholen und den Zustand mit Logs und Statusmeldungen schnell bewerten. Genau so spielst du die Stärken von systemd timer statt cron verwenden aus und überträgst das Muster von reminder.service und reminder.timer auf eigene Aufgaben.
