CronJob läuft nicht

WTF?! Mein Cronjob läuft nicht?!

Hier ist eine Checkliste zum Debuggen von Cronjobs, die nicht ausgeführt werden:

1. Läuft der Cron-Daemon?

• Führen Sie ps ax | grep cron aus und suchen Sie nach cron.
• Debian:service cron start oder service cron restart

2. Funktioniert cron?

• * * * * * /bin/echo "cron works" >> /tmp/file
• Syntax korrekt? Siehe unten.
• Sie müssen offensichtlich Schreibzugriff auf die Datei haben, in die Sie die Ausgabe umleiten. Ein eindeutiger Dateiname in /tmp die derzeit nicht existiert, sollte immer beschreibbar sein.
• Wahrscheinlich auch 2>&1 hinzufügen um sowohl Standardfehler als auch Standardausgabe einzuschließen oder Standardfehler separat in eine andere Datei mit 2>>/tmp/errors auszugeben

3. Funktioniert der Befehl eigenständig?

• Überprüfen Sie, ob das Skript einen Fehler aufweist, indem Sie einen Probelauf auf der CLI durchführen
• Wenn Sie Ihren Befehl testen, testen Sie als der Benutzer, dessen Crontab Sie bearbeiten, was möglicherweise nicht Ihr Login oder Root ist

4. Kann Cron Ihren Job ausführen?

• Prüfen Sie /var/log/cron.log oder /var/log/messages für Fehler.
• Ubuntu:grep CRON /var/log/syslog
• Redhat:/var/log/cron

5. Berechtigungen prüfen

• Ausführbares Flag für den Befehl setzen:chmod +x /var/www/app/cron/do-stuff.php
• Wenn Sie die Ausgabe Ihres Befehls in eine Datei umleiten, vergewissern Sie sich, dass Sie berechtigt sind, in diese Datei/dieses Verzeichnis zu schreiben

6. Pfade prüfen

• Überprüfen Sie die She-Bangs / Hashbangs-Linie
• Verlassen Sie sich nicht auf Umgebungsvariablen wie PATH , da ihr Wert unter Cron wahrscheinlich nicht derselbe ist wie unter einer interaktiven Sitzung. Siehe CRON dazu bringen, die richtigen PATHs aufzurufen

7. Ausgabe beim Debuggen nicht unterdrücken

• Gebräuchlich ist diese Unterdrückung:30 1 * * * command > /dev/null 2>&1
• Aktivieren Sie die Standardausgabe oder die Ausgabe von Standardfehlermeldungen erneut, indem Sie >/dev/null 2>&1 entfernen insgesamt; oder vielleicht zu einer Datei an einem Ort umleiten, an dem Sie Schreibzugriff haben:>>cron.out 2>&1 wird Standardausgabe und Standardfehler an cron.out anhängen im Home-Verzeichnis des aufrufenden Benutzers.
• Wenn Sie die Ausgabe von cron nicht umleiten job, versucht der Daemon, Ihnen alle Ausgabe- oder Fehlermeldungen per E-Mail zuzusenden. Überprüfen Sie Ihren Posteingang (vielleicht einfach more $MAIL wenn Sie keinen E-Mail-Client haben). Wenn Mail nicht verfügbar ist, suchen Sie vielleicht nach einer Datei mit dem Namen dead.letter in Ihrem Home-Verzeichnis oder Systemprotokolleinträge, die besagen, dass die Ausgabe verworfen wurde. Bearbeiten Sie insbesondere im letzteren Fall wahrscheinlich den Job, um eine Umleitung zu einer Datei hinzuzufügen, warten Sie dann, bis der Job ausgeführt wird, und untersuchen Sie die Protokolldatei auf Fehlermeldungen oder andere nützliche Rückmeldungen.
• Wenn Sie versuchen herauszufinden, warum etwas fehlgeschlagen ist, werden die Fehlermeldungen in dieser Datei angezeigt. Lesen und verstehen.

Funktioniert immer noch nicht? Huch!

1. Cron-Debug-Level erhöhen

• Debian
  • in /etc/default/cron
  • setzen Sie EXTRA_OPTS="-L 2"
  • service cron restart
  • tail -f /var/log/syslog um die ausgeführten Skripte zu sehen
• Ubuntu
  • in /etc/rsyslog.d/50-default.conf
  • Zeile cron.* /var/log/cron.log hinzufügen oder auskommentieren
  • Logger neu laden sudo /etc/init.d/rsyslog restart
  • cron erneut ausführen
  • öffne /var/log/cron.log und suchen Sie nach einer detaillierten Fehlerausgabe
• Erinnerung:Loglevel deaktivieren, wenn Sie mit dem Debuggen fertig sind

2. Cron ausführen und Protokolldateien erneut prüfen

Cronjob-Syntax

# Minute  Hour  Day of Month      Month         Day of Week    User Command    
# (0-59) (0-23)   (1-31)    (1-12 or Jan-Dec) (0-6 or Sun-Sat)  
         
    0       2       *             *                *          root /usr/bin/find

Diese Syntax ist nur richtig für root Benutzer. Normaler Benutzer crontab Syntax hat nicht den Benutzer Feld (normale Benutzer dürfen Code nicht wie andere Benutzer ausführen);

# Minute  Hour  Day of Month      Month         Day of Week    Command    
# (0-59) (0-23)   (1-31)    (1-12 or Jan-Dec) (0-6 or Sun-Sat)  
         
    0       2       *             *                *          /usr/bin/find

Crontab-Befehle

1. crontab -l
   • Listet alle Crontasks des Benutzers auf.
2. crontab -e , für einen bestimmten Benutzer:crontab -e -u agentsmith
   • Startet die Bearbeitungssitzung Ihrer Crontab-Datei.
   • Beim Verlassen des Editors wird die modifizierte Crontab automatisch installiert.
3. crontab -r
   • Entfernt Ihren Crontab-Eintrag aus dem Cron-Spooler, aber nicht aus der Crontab-Datei.

Ich möchte 2 Punkte hinzufügen, die ich gelernt habe:

1. Cron-Konfigurationsdateien in /etc/cron.d/ sollten keinen Punkt (.) enthalten. Andernfalls wird es von cron nicht gelesen.
2. Wenn der Benutzer, der Ihren Befehl ausführt, nicht in /etc/shadow. Cron darf nicht geplant werden.

Referenzen:

1. http://manpages.ubuntu.com/manpages/xenial/en/man8/cron.8.html
2. https://help.ubuntu.com/community/CronHowto

Endlich habe ich die Lösung gefunden. Folgendes ist die Lösung:-

1. Verwenden Sie niemals einen relativen Pfad in Python-Skripten, die über crontab ausgeführt werden sollen. Ich habe stattdessen so etwas gemacht:-

   import os
   import sys
   import time, datetime
   
   CLASS_PATH = '/srv/www/live/mainapp/classes'
   SETTINGS_PATH = '/srv/www/live/foodtrade'
   sys.path.insert(0, CLASS_PATH)
   sys.path.insert(1,SETTINGS_PATH)
   
   import other_py_files
   

2. Unterdrücken Sie niemals den Crontab-Code, verwenden Sie stattdessen den Mailserver und prüfen Sie die E-Mails für den Benutzer. Das gibt klarere Einblicke in das, was vor sich geht.

Ein weiterer Grund, warum crontab fehlschlagen wird:Sonderbehandlung von % Zeichen.

Aus der Handbuchdatei:

The entire command portion of the line, up to a newline or a
"%" character, will be executed by /bin/sh or by the shell specified
in the SHELL variable of the cronfile.  A "%" character in the
command, unless escaped with a backslash (\), will be changed into
newline characters, and all data after the first % will be sent to
the command as standard input.

In meinem speziellen Fall habe ich date --date="7 days ago" "+%Y-%m-%d" verwendet um Parameter für mein Skript zu erzeugen, und es schlug stillschweigend fehl. Ich fand schließlich heraus, was los war, als ich syslog überprüfte und sah, dass mein Befehl bei % abgeschnitten wurde Symbol. Sie müssen es folgendermaßen entkommen:

date --date="7 days ago" "+\%Y-\%m-\%d"

Weitere Einzelheiten finden Sie hier:

http://www.ducea.com/2008/11/12/using-the-character-in-crontab-entries/