CronJob non in esecuzione

CAZZO?! Il mio cronjob non funziona?!

Ecco una guida alla lista di controllo per eseguire il debug di cronjob non in esecuzione:

1. Il demone Cron è in esecuzione?

• Esegui ps ax | grep cron e cerca cron.
• Debian:service cron start o service cron restart

2. Cron funziona?

• * * * * * /bin/echo "cron works" >> /tmp/file
• Sintassi corretta? Vedi sotto.
• Ovviamente devi avere accesso in scrittura al file a cui stai reindirizzando l'output. Un nome file univoco in /tmp che attualmente non esiste dovrebbe essere sempre scrivibile.
• Probabilmente aggiungi anche 2>&1 per includere l'errore standard così come l'output standard, o inviare separatamente l'errore standard a un altro file con 2>>/tmp/errors

3. Il comando funziona da solo?

• Controlla se lo script ha un errore, eseguendo un test sulla CLI
• Quando provi il tuo comando, prova come l'utente di cui stai modificando il crontab, che potrebbe non essere il tuo login o root

4. Cron può eseguire il tuo lavoro?

• Controlla /var/log/cron.log o /var/log/messages per errori.
• Ubuntu:grep CRON /var/log/syslog
• Cappello rosso:/var/log/cron

5. Controlla le autorizzazioni

• Imposta flag eseguibile sul comando:chmod +x /var/www/app/cron/do-stuff.php
• Se reindirizzi l'output del tuo comando su un file, verifica di avere il permesso di scrivere su quel file/directory

6. Controlla percorsi

• Controlla la linea she-bang/hashbang
• Non fare affidamento su variabili d'ambiente come PATH , poiché il loro valore probabilmente non sarà lo stesso in cron come in una sessione interattiva. Vedi Come fare in modo che CRON chiami nei PATH corretti

7. Non sopprimere l'output durante il debug

• Comunemente usata è questa soppressione:30 1 * * * command > /dev/null 2>&1
• Riattiva l'output standard o l'output del messaggio di errore standard rimuovendo >/dev/null 2>&1 del tutto; o forse reindirizzare a un file in una posizione in cui hai accesso in scrittura:>>cron.out 2>&1 aggiungerà l'output standard e l'errore standard a cron.out nella home directory dell'utente che lo ha richiamato.
• Se non reindirizzi l'output da un cron job, il demone proverà a inviarti qualsiasi output o messaggio di errore tramite e-mail. Controlla la tua casella di posta (forse semplicemente more $MAIL se non hai un client di posta). Se la posta non è disponibile, forse cerca un file chiamato dead.letter nella tua home directory o voci del registro di sistema che dicono che l'output è stato scartato. Soprattutto in quest'ultimo caso, probabilmente modifica il lavoro per aggiungere il reindirizzamento a un file, quindi attendi l'esecuzione del lavoro ed esamina il file di registro per i messaggi di errore o altri feedback utili.
• Se stai cercando di capire perché qualcosa non è riuscito, i messaggi di errore saranno visibili in questo file. Leggilo e capiscilo.

Continui a non funzionare? Oddio!

1. Aumenta il livello di debug di cron

• Debian
  • in /etc/default/cron
  • imposta EXTRA_OPTS="-L 2"
  • service cron restart
  • tail -f /var/log/syslog per vedere gli script eseguiti
• Ubuntu
  • in /etc/rsyslog.d/50-default.conf
  • aggiungi o commenta la riga cron.* /var/log/cron.log
  • ricarica il logger sudo /etc/init.d/rsyslog restart
  • riesegui cron
  • apri /var/log/cron.log e cerca l'output dettagliato degli errori
• Promemoria:disattiva il livello di registro, quando hai finito con il debug

2. Esegui cron e controlla nuovamente i file di registro

Sintassi Cronjob

# 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

Questa sintassi è solo corretto per root utente. Utente normale crontab la sintassi non ha l'Utente campo (gli utenti normali non sono autorizzati a eseguire il codice come qualsiasi altro utente);

# 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

Comandi Crontab

1. crontab -l
   • Elenca tutte le attività cron dell'utente.
2. crontab -e , per un utente specifico:crontab -e -u agentsmith
   • Avvia la sessione di modifica del tuo file crontab.
   • Quando esci dall'editor, il crontab modificato viene installato automaticamente.
3. crontab -r
   • Rimuove la tua voce crontab dallo spooler cron, ma non dal file crontab.

Voglio aggiungere 2 punti che ho imparato:

1. I file di configurazione di Cron inseriti in /etc/cron.d/ non devono contenere un punto (.). Altrimenti, non verrà letto da cron.
2. Se l'utente che esegue il tuo comando non è in /etc/shadow. Non sarà consentito pianificare cron.

Rif:

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

Finalmente ho trovato la soluzione. Di seguito è la soluzione:-

1. Non usare mai il percorso relativo negli script Python da eseguire tramite crontab. Invece ho fatto qualcosa del genere:-

   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. Non sopprimere mai il codice crontab invece usa il server di posta e controlla la posta per l'utente. Ciò fornisce informazioni più chiare su ciò che sta accadendo.

Un altro motivo per cui crontab fallirà:gestione speciale del % carattere.

Dal file manuale:

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.

Nel mio caso particolare, stavo usando date --date="7 days ago" "+%Y-%m-%d" per produrre parametri per il mio script, e stava fallendo silenziosamente. Alla fine ho scoperto cosa stava succedendo quando ho controllato syslog e ho visto che il mio comando era stato troncato al % simbolo. Devi scappare in questo modo:

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

Vedi qui per maggiori dettagli:

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