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. 

📚 Inhaltsverzeichnis

👉 Cron Kapitel 1: Grundlagen von Cron & dem Task-Scheduler 👉 Cron Kapitel 2: Die Crontab verstehen – Aufbau & Syntax 👉 Cron Kapitel 3: Eigene Cronjobs erstellen – erste Automatisierungen 👉 Cron Kapitel 4: Cronjobs überwachen & Fehler finden 👉 Cron Kapitel 5: Praktische Cron-Beispiele für den Alltag 👉 Cron Kapitel 6: Sicherheit & Best Practices für Cronjobs 👉 Cron Kapitel 7: Erweiterungen – anacron & systemd timers 👉 Cron Kapitel 8: Abschlussprojekt – Dein eigenes Cron-Setup