Cron-Fehlerbehebung: Warum Ihre Jobs nicht laufen

Bevor Sie in komplexes Debugging eintauchen, überprüfen Sie die Grundlagen. Viele Cron-Probleme stammen von einfachen Übersehen, die leicht zu überprüfen sind.

Bestätigen Sie zuerst, dass Ihre Crontab tatsächlich gespeichert wurde. Nach der Bearbeitung mit "crontab -e" überprüfen Sie sie mit "crontab -l", um Ihre Crontab aufzulisten. Wenn Ihre Einträge nicht erscheinen, wurden sie nicht gespeichert. Häufige Ursachen: Editor ohne Speichern geschlossen, falsches Benutzerkonto (Crontab ist pro Benutzer) oder Syntaxfehler, die dazu führen, dass die Crontab abgelehnt wird.

Überprüfen Sie, dass der Cron-Daemon läuft. Auf den meisten Linux-Systemen verwenden Sie "systemctl status cron" oder "systemctl status crond" (der Daemon-Name variiert je nach Distribution). Wenn Cron nicht läuft, können Ihre Jobs nicht ausgeführt werden. Starten Sie ihn mit "systemctl start cron" oder "service cron start".

Überprüfen Sie, dass Ihre Cron-Syntax gültig ist. Verwenden Sie unseren Crontab-Generator, um Ihren Ausdruck zu validieren und zu sehen, wann er laufen würde. Ein einfacher Tippfehler wie "0 0 * * 8" (es gibt keinen Tag 8) oder "60 0 * * *" (Minute 60 existiert nicht) verursacht stillschweigende Fehler. Der Cron-Daemon meldet Syntaxfehler oft nicht klar.

Überprüfen Sie Systemprotokolle auf Cron-Ausführung. Auf systemd-Systemen verwenden Sie "journalctl -u cron" oder "journalctl -u crond". Auf älteren Systemen überprüfen Sie /var/log/syslog oder /var/log/cron. Diese Protokolle zeigen, wann Cron Jobs startet, selbst wenn der Job selbst fehlschlägt. Wenn Sie nicht sehen, dass Ihr Job startet, liegt das Problem bei der Cron-Planung. Wenn Sie sehen, dass er startet, aber fehlschlägt, liegt das Problem bei Ihrem Befehl.

Bestätigen Sie, dass Sie die richtige Crontab des Benutzers bearbeiten. Cron-Jobs laufen als der Benutzer, dem die Crontab gehört. Wenn Sie Root-Berechtigungen benötigen, verwenden Sie "sudo crontab -e", um die Crontab von Root zu bearbeiten, nicht die Crontab Ihres Benutzers. "crontab -e" als regulärer Benutzer auszuführen und dann zu versuchen, Befehle auszuführen, die Root-Privilegien erfordern, wird mit Berechtigungsfehlern fehlschlagen.

Stellen Sie sicher, dass Ihr Befehl existiert und ausführbar ist. Führen Sie von einem Terminal aus den genauen Befehl aus Ihrer Crontab manuell aus. Wenn er interaktiv fehlschlägt, wird er definitiv in Cron fehlschlagen. Wenn er interaktiv erfolgreich ist, aber in Cron fehlschlägt, liegt das Problem wahrscheinlich bei Umgebungsunterschieden (als nächstes behandelt).

Cron-Job-Fehler sind schwer zu debuggen ohne Ausgabe. Standardmäßig sendet Cron Befehlsausgabe und Fehler per E-Mail an den Benutzer, aber die meisten modernen Systeme haben keine lokale E-Mail konfiguriert, also verschwindet diese Ausgabe. Explizite Protokollierung löst dies.

Leiten Sie stdout und stderr in eine Protokolldatei um: "0 2 * * * /path/to/script.sh > /var/log/myjob.log 2>&1". Das "> /var/log/myjob.log" leitet Standardausgabe (stdout) in die Datei um. Das "2>&1" leitet Standardfehler (stderr) dorthin um, wohin stdout geht (die Protokolldatei). Jetzt geht alle Ausgabe, einschließlich Fehlermeldungen, in eine Datei, die Sie untersuchen können, wenn Ihr Job fehlschlägt.

Anhängen statt Überschreiben, um eine Historie aufzubauen: "0 2 * * * /path/to/script.sh >> /var/log/myjob.log 2>&1". Das ">>" hängt an die Datei an, anstatt sie zu ersetzen. Jeder Lauf fügt zum Protokoll hinzu und erstellt eine Historie. Achten Sie auf Protokolldatei-Wachstum - implementieren Sie Log-Rotation oder periodisches Aufräumen.

Fügen Sie Zeitstempel hinzu, um Läufe zu unterscheiden: In Ihrem Skript verwenden Sie "date", um auszugeben, wann es läuft. Oder verwenden Sie eine Protokollierungsbibliothek, die Einträge automatisch mit Zeitstempeln versieht. Ohne Zeitstempel ist es schwer zu sagen, welche Protokolleinträge von welcher Ausführung stammen.

Log-Rotation verhindert unbegrenztes Wachstum. Verwenden Sie logrotate, um alte Protokolle automatisch zu archivieren, zu komprimieren und zu löschen. Erstellen Sie /etc/logrotate.d/myjob mit Konfiguration, um Ihre Cron-Job-Protokolle wöchentlich oder wenn sie eine bestimmte Größe erreichen zu rotieren.

Für kritische Jobs erwägen Sie sowohl Protokollierung in eine Datei als auch Alarmierung bei Fehler. Erfassen Sie Ausgabe in ein Protokoll und überprüfen Sie dann den Exit-Code: "0 2 * * * /path/to/script.sh >> /var/log/myjob.log 2>&1 || echo 'Job fehlgeschlagen' | mail -s 'Cron-Fehler' [email protected]". Das "||" bedeutet "oder" - wenn das Skript fehlschlägt (Exit-Code ungleich Null), senden Sie eine E-Mail.

Trennen Sie stdout und stderr, wenn Sie normale Ausgabe von Fehlern unterscheiden müssen: "0 2 * * * /path/to/script.sh >> /var/log/myjob.out 2>> /var/log/myjob.err". Jetzt geht normale Ausgabe nach .out und Fehler nach .err.

Zum Testen verwenden Sie ein kurzes Intervall (alle 2 Minuten) und überprüfen Sie Protokolle häufig: "*/2 * * * * /path/to/script.sh >> /tmp/test.log 2>&1". Sobald es funktioniert, ändern Sie auf den Produktionszeitplan und verschieben Sie Protokolle an den richtigen Ort.

Denken Sie daran, dass Cron ohne Umleitung versucht, Ausgabe per E-Mail zu senden. Wenn Ihr System lokal E-Mail generiert (überprüfen Sie /var/mail/benutzername), könnten Sie Ausgabe dort finden. Aber explizite Protokollierung ist zuverlässiger als sich auf lokale E-Mail zu verlassen.