wake-up-neo.net

CronTab läuft nicht

Ich habe cronjob für root-Benutzer in der Ubuntu-Umgebung wie folgt eingerichtet, indem ich crontab -e eingebe

  34 11 * * * sh /srv/www/live/CronJobs/daily.sh
  0 08 * * 2 sh /srv/www/live/CronJobs/weekly.sh
  0 08 1 * * sh /srv/www/live/CronJobs/monthly.sh

Aber der Cronjon läuft nicht. Ich habe versucht zu überprüfen, ob der Cronjob läuft 

pgrep cron

und das gibt die Prozess-ID 3033. Der Shell-Scrip ruft Python-Datei auf und wird zum Senden von E-Mails verwendet. Das Ausführen der Python-Datei ist in Ordnung. Es gibt keinen Fehler, aber der Cron läuft nicht. Die Datei daily.sh enthält folgenden Code.

python /srv/www/live/CronJobs/daily.py
python /srv/www/live/CronJobs/notification_email.py
python /srv/www/live/CronJobs/log_kpi.py
24
Roshan Bhandari

WTF?! Mein Cronjob läuft nicht?!

Hier ist eine Checklisten-Anleitung zum Debuggen von nicht ausgeführten Cronjobs:

  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 richtig? Siehe unten.
    • Sie müssen natürlich Schreibzugriff auf die Datei haben, in die Sie die Ausgabe umleiten. Ein eindeutiger Dateiname in /tmp, Der derzeit nicht existiert, sollte immer beschreibbar sein.
  3. Funktioniert der Befehl eigenständig?
    • Überprüfen Sie, ob das Skript einen Fehler aufweist, indem Sie einen Probelauf für die CLI ausführen
    • testen Sie beim Testen Ihres Befehls den Benutzer, dessen Crontab Sie bearbeiten. Dies ist möglicherweise nicht Ihr Login oder Root
  4. Kann cron Ihren Job leiten?
    • Überprüfen Sie /var/log/cron.log Oder /var/log/messages Auf Fehler.
    • Ubuntu: grep CRON /var/log/syslog
    • Redhat: /var/log/cron
  5. Berechtigungen prüfen
    • setze das ausführbare Flag für den Befehl: chmod +x /var/www/app/cron/do-stuff.php
    • wenn Sie die Ausgabe Ihres Befehls in eine Datei umleiten, vergewissern Sie sich, dass Sie zum Schreiben in diese Datei/dieses Verzeichnis berechtigt sind
  6. Pfade prüfen
    • überprüfen Sie die She-Bangs/Hashbangs-Linie
    • verlassen Sie sich nicht auf Umgebungsvariablen wie PATH, da deren Wert unter cron wahrscheinlich nicht mit dem Wert einer interaktiven Sitzung übereinstimmt
  7. Unterdrücke die Ausgabe nicht während des Debuggens
    • häufig wird folgende Unterdrückung verwendet: 30 1 * * * command > /dev/null 2>&1
    • aktivieren Sie die Standardausgabe oder die Standardfehlermeldungsausgabe wieder, indem Sie >/dev/null 2>&1 vollständig entfernen. oder leiten Sie zu einer Datei an einem Ort weiter, an dem Sie über Schreibzugriff verfügen: >>cron.out 2>&1 fügt die Standardausgabe und den Standardfehler an cron.out im Basisverzeichnis des aufrufenden Benutzers an.

Funktioniert immer noch nicht? Huch!

  1. Erhöhen Sie das Cron-Debug-Level
    • Debian
      • in /etc/default/cron
      • setze EXTRA_OPTS="-L 2"
      • service cron restart
      • tail -f /var/log/syslog, Um die ausgeführten Skripte anzuzeigen
    • Ubuntu
      • in /etc/rsyslog.d/50-default.conf
      • zeile hinzufügen oder auskommentieren cron.crit /var/log/cron.log
      • logger neu laden Sudo /etc/init.d/rsyslog reload
      • führen Sie Cron erneut aus
      • öffne /var/log/cron.log und suche nach detaillierten Fehlermeldungen
    • Erinnerung: Deaktivieren Sie die Protokollebene, wenn Sie mit dem Debuggen fertig sind
  2. Führen Sie cron aus und überprüfen Sie die Protokolldateien erneut

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 korrekt für den Benutzer root. Regulärer Benutzer crontab hat in der Syntax nicht das Feld Benutzer (reguläre Benutzer dürfen keinen Code wie jeder 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 Cron-Aufgaben des Benutzers auf.
  2. crontab -e Für einen bestimmten Benutzer: crontab -e -u agentsmith
    • Startet die Editiersitzung Ihrer crontab-Datei.
    • Wenn Sie den Editor verlassen, wird die geänderte crontab automatisch installiert.
  3. crontab -r
    • Entfernt Ihren Crontab-Eintrag aus dem Cron-Spooler, jedoch nicht aus der Crontab-Datei.
103
Jens A. Koch

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

  1. Verwenden Sie niemals relativen Pfad in Python-Skripten, um über Crontab ausgeführt zu werden. __ Ich habe stattdessen Folgendes getan: -

    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, sondern verwenden Sie den Mailserver und prüfen Sie die E-Mails für den Benutzer. Das gibt klarere Einblicke in die Zukunft.

6
Roshan Bhandari

Ein weiterer Grund, warum crontab fehlschlägt: Spezielle Behandlung des %-Zeichens.

Aus der man-Datei :

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 erstellen, und es fiel im Hintergrund aus. Ich fand schließlich heraus, was los war, als ich syslog überprüfte und sah, dass mein Befehl am %-Symbol abgeschnitten wurde. Du musst es so entziehen:

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

Weitere Einzelheiten finden Sie hier:

http://www.ducea.com/2008/11/12/gebraucheiner-zeichen-in-crontab-einträge/

3
Luciano

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

  1. Cron-Konfigurationsdateien in /etc/cron.d/ dürfen keinen Punkt (.) Enthalten. Ansonsten wird es nicht von cron gelesen.
  2. Wenn sich der Benutzer, der Ihren Befehl ausführt, nicht in/etc/shadow befindet. Es wird nicht erlaubt, cron einzuplanen.

Refs:

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

Ich habe das gleiche Problem erlebt, wo keine Crons laufen. Wir haben das Problem behoben, indem wir die Berechtigungen und den Besitzer durch .__ geändert haben. Crons hat den Root-Besitzer wie in crontab AND Cronjobs 644 erwähnt

0
Sachin Patil

Ich habe einen anderen Grund gefunden, warum Crontab des Benutzers nicht läuft: Der Hostname ist nicht in der Hosts-Datei vorhanden:

[email protected]:~$ cat /etc/hostname
ubuntu

Nun die hosts-Datei:

[email protected]:~$ cat /etc/hosts
127.0.0.1 localhost

# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts

Dies ist auf einem Ubuntu 14.04.3 LTS. Der Weg zur Behebung dieses Problems ist Hinzufügen des Hostnamens zur Hosts-Datei So sieht es ungefähr so ​​aus:

[email protected]:~$ cat /etc/hosts
127.0.0.1 ubuntu localhost

# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts
0
Javi Romero

Für mich bestand die Lösung darin, dass die Datei cron versuchte, sich in einem verschlüsselten Verzeichnis zu befinden, genauer gesagt in einem Benutzerverzeichnis unter/home /. Obwohl die crontab als root konfiguriert war, konnte das ausgeführte Skript in einem verschlüsselten Benutzerverzeichnis in/home/cron dieses Verzeichnis nur lesen, wenn der Benutzer tatsächlich angemeldet war. Überprüfen Sie, ob das Verzeichnis verschlüsselt ist.

/home/.ecryptfs/<yourusername>

wenn ja, haben Sie ein verschlüsseltes Ausgangsverzeichnis. 

Die Lösung für mich bestand darin, das Skript in ein nicht = verschlüsseltes Verzeichnis zu verschieben, und alles funktionierte einwandfrei.

0
theINtoy