Cron Kapitel 4: Cronjobs überwachen & Fehler finden

von | Sep. 16, 2025 | Cron

Du hast jetzt deine ersten Cronjobs erstellt. Aber was tun, wenn sie nicht laufen wie geplant?
In diesem Kapitel lernst du, wie du Cronjobs überwachst, Ausgaben protokollierst und Fehler aufspürst.

🔹 Warum Cronjobs manchmal „nicht funktionieren“

Es gibt typische Ursachen, warum ein Cronjob fehlschlägt:

  1. Falsche Zeitangaben – ein kleiner Fehler in der Crontab-Syntax genügt.
  2. Pfadprobleme – Cron nutzt eine minimale Umgebung, d. h. viele Befehle liegen nicht dort, wo du sie erwartest.
  3. Berechtigungen – dein Benutzer hat vielleicht nicht genug Rechte für den Befehl.
  4. Ausgaben verpuffen – Cron zeigt keine Meldungen direkt im Terminal an.

👉 Deshalb ist es wichtig, Cronjobs aktiv zu überwachen.

🔹 Ausgaben in Logdateien schreiben

Standardmäßig werden Ausgaben eines Cronjobs an die lokale Mailbox des Benutzers geschickt (z. B. mail-Befehl).

Da viele Systeme keine Mailkonfiguration haben, ist es besser, Ausgaben in Dateien umzuleiten.

Beispiel:

* * * * * echo "Cronjob läuft" >> /home/user/cron_test.log 2>&1
  • >> → hängt die Ausgabe an eine Datei an.
  • 2>&1 → sorgt dafür, dass auch Fehler (stderr) ins gleiche Log geschrieben werden.

👉 So kannst du jederzeit prüfen, ob dein Job läuft und welche Fehler auftreten.

🔹 Cron-Logs im System prüfen

Cron selbst protokolliert, wann es Jobs startet. Diese Einträge findest du in den System-Logs:

Auf Debian/Ubuntu:

grep CRON /var/log/syslog

Auf CentOS/RHEL:

grep CRON /var/log/cron

Beispielausgabe:

Sep 14 12:00:01 server CRON[1234]: (user) CMD (/home/user/backup.sh)

👉 Hier siehst du: Datum, Benutzer und welcher Befehl gestartet wurde.

🔹 Umgebungsvariablen in Cron

Ein häufiger Fehler: Befehle laufen im Terminal, aber nicht in Cron.
Grund: Cron startet mit einer minimalen Umgebung.

  • Dein PATH ist kürzer als im Terminal.
  • Variablen wie HOME oder USER sind eventuell nicht gesetzt.

Lösung:

Nutze absolute Pfade für Befehle.

0 2 * * * /usr/bin/rsync -a /home/user/ /home/user/Backup/

Falls nötig, setze Variablen in der Crontab selbst:

PATH=/usr/local/bin:/usr/bin:/bin

🔹 Cronjobs simulieren

Um zu testen, ob dein Befehl funktioniert, führe ihn direkt im Terminal aus:

/home/user/backup.sh

Wenn er dort funktioniert, aber im Cron nicht, liegt es fast immer an:

  • Pfadproblemen
  • fehlenden Rechten
  • oder fehlenden Umgebungsvariablen.

🔹 Praktische Tools zur Überwachung

  • crontab -l → zeigt aktuelle Jobs an.
  • systemctl status cron → prüft, ob Cron läuft.
  • journalctl -u cron → Logs unter systemd.
  • Eigene Logfiles (>> logfile) → direkte Kontrolle deiner Jobs.

🔹 Übung

  1. Lege einen Job an, der jede Minute date in /tmp/croncheck.log schreibt.
  2. Warte 5 Minuten und prüfe den Inhalt mit: 
    cat /tmp/croncheck.log
  3. Führe absichtlich einen falschen Befehl aus, z. B.: 
    * * * * * falscherbefehl >> /tmp/error.log 2>&1

    → Sieh dir an, wie Cron den Fehler ins Log schreibt.

  4. Prüfe mit grep CRON /var/log/syslog, ob deine Jobs gestartet wurden.

✅ Zusammenfassung

  • Cronjobs geben keine Meldungen direkt im Terminal aus – du musst Ausgaben umleiten.
  • Logs findest du in /var/log/syslog oder /var/log/cron.
  • Absolute Pfade (/usr/bin/rsync) sind Pflicht, weil Cron nur eine minimale Umgebung lädt.
  • Fehler lassen sich gezielt provozieren und so nachvollziehen.

👉 Im nächsten Kapitel schauen wir uns praktische Cron-Beispiele an – von automatischen Backups über Systempflege bis hin zu Netzwerküberwachung.