Wo werden Cron-Fehler protokolliert?

Question

Wenn ich cronJobs falsch einrichte, scheinen sie stillschweigend fehlzuschlagen. Wo finde ich ein Fehlerprotokoll, um herauszufinden, was schiefgelaufen ist?

Answer 1

Wie andere bereits erwähnt haben, cronwird Ihnen die Ausgabe aller ausgeführten Programme per E-Mail zugesendet (sofern eine Ausgabe vorhanden ist). Wenn Sie also keine Ausgabe erhalten, gibt es grundsätzlich drei Möglichkeiten:

1. crondkonnte nicht einmal eine Shell zum Ausführen eines Programms oder zum Senden einer E-Mail starten
2. crondBeim Versenden der Ausgabe per E-Mail gab es Probleme, oder die E-Mail ist verloren gegangen.
3. das Programm hat keine Ausgabe erzeugt (auch keine Fehlermeldungen)

Fall 1 ist sehr unwahrscheinlich, aber es sollte etwas in die Cron-Protokolle geschrieben worden sein. Cron hat eine eigene reservierte Syslog-Funktion, daher sollten Sie einen Blick darauf werfen /etc/syslog.conf(oder in die entsprechende Datei in Ihrer Distribution), um zu sehen, wohin Nachrichten dieser Funktion crongesendet werden. Beliebte Ziele sind /var/log/cron, /var/log/messagesund /var/log/syslog.

Im zweiten Fall sollten Sie die Protokolle des Mailer-Daemons überprüfen: Nachrichten vom Cron-Daemon erscheinen normalerweise als von root@yourhost. Sie können eine Zeile in der Crontab-Datei verwenden, MAILTO=...damit Cron E-Mails an eine bestimmte Adresse sendet, was das Durchsuchen der Protokolle des Mailer-Daemons erleichtern sollte. Beispiel:

[email protected]
00 15 * * *  echo "Just testing if crond sends email"

Im Fall 3. können Sie testen, ob das Programm tatsächlich ausgeführt wurde, indem Sie einen weiteren Befehl anhängen, dessen Wirkung Sie leicht überprüfen können: zum Beispiel

00 15 * * * /a/command; touch /tmp/a_command_has_run

Sie können also überprüfen, ob crondtatsächlich etwas ausgeführt wurde, indem Sie sich die Mtime von ansehen /tmp/a_command_has_run.

Answer 2

Sie können die Jobausgabe jederzeit explizit an eine Protokolldatei senden:

0 8 * * * /usr/local/bin/myjob > /var/log/myjob.log 2>&1

Beachten Sie, dass dies das zuvor erwähnte Mail-Verhalten außer Kraft setzt, da crond selbst keine Ausgabe vom Job erhält. Wenn Sie dieses Verhalten beibehalten möchten, sollten Sie sich tee(1) ansehen.

Answer 3

Wenn Sie die E-Mails nicht sehen, spammen Sie möglicherweise root@IhrUnternehmen mit den Fehlern zu, was für die Personen, die dieses Konto zur Überwachung verwenden, ziemlich ärgerlich sein kann. Versuchen Sie stattdessen, die Ausgabe an Syslog zu senden:

*/5 * * * * yourcronjob 2>&1 | /usr/bin/logger -t yourtag

Warten Sie dann, bis der Cronjob ausgeführt wird, und suchen Sie in /var/log/messages (oder auf einigen Systemen in /var/log/user.log) nach dem Fehler.

Dies funktioniert hervorragend für Fehlermeldungen, die nur 1-2 Zeilen lang sind, wie z. B. „yourcronjob: Befehl nicht gefunden“. Es nutzt auch Ihre vorhandene Syslog-Infrastruktur (Logrotation, zentrales Syslogging, Splunk usw.). Es reduziert auch E-Mail-Spam an Root.

Wenn Ihr Cronjob Hunderte von Ausgabezeilen generiert, ist dies möglicherweise keine gute Lösung.

Answer 4

Die Standardkonfiguration von Cron sendet Ihnen eine E-Mail mit der Ausgabe Ihres Programms. Wenn dies fehlschlägt, können Sie versuchen, Ihr fehlerhaftes Programm in ein Shell-Skript einzubinden, das sicherstellt, dass das Programm nicht fehlschlägt. Außerdem können Sie die Ausgabe protokollieren.

Dies ist eine konfigurierbare Einstellung bei einigen Cron-Implementierungen.