CronJob no se ejecuta

¡¿Qué diablos?! ¡¿Mi cronjob no funciona?!

Aquí hay una guía de lista de verificación para depurar trabajos cron que no se ejecutan:

1. ¿Se está ejecutando el demonio Cron?

• Ejecutar ps ax | grep cron y busca cron.
• Debian:service cron start o service cron restart

1. ¿Funciona cron?

• * * * * * /bin/echo "cron works" >> /tmp/file
• ¿Sintaxis correcta? Ver a continuación.
• Obviamente necesita tener acceso de escritura al archivo al que está redirigiendo la salida. Un nombre de archivo único en /tmp que no existe actualmente debe ser siempre escribible.
• Probablemente también agregue 2>&1 para incluir el error estándar así como la salida estándar, o enviar el error estándar por separado a otro archivo con 2>>/tmp/errors

1. ¿El comando funciona de forma independiente?

• Compruebe si el script tiene un error, realizando una ejecución en seco en la CLI
• Cuando pruebe su comando, pruébelo como el usuario cuyo crontab está editando, que podría no ser su inicio de sesión o root

1. ¿Puede cron ejecutar tu trabajo?

• Marque /var/log/cron.log o /var/log/messages por errores.
• Ubuntu:grep CRON /var/log/syslog
• Redhat:/var/log/cron

1. Comprobar permisos

• Establecer bandera ejecutable en el comando:chmod +x /var/www/app/cron/do-stuff.php
• Si redirige la salida de su comando a un archivo, verifique que tenga permiso para escribir en ese archivo/directorio

1. Comprobar rutas

• Compruebe la línea she-bangs / hashbangs
• No confíe en variables de entorno como PATH , ya que es probable que su valor no sea el mismo en cron que en una sesión interactiva. Consulte Cómo hacer que CRON llame en las RUTAS correctas

1. No suprimir la salida durante la depuración

• Comúnmente utilizada es esta supresión:30 1 * * * command > /dev/null 2>&1
• Vuelva a habilitar la salida estándar o la salida de mensajes de error estándar eliminando >/dev/null 2>&1 en total; o tal vez redirigir a un archivo en una ubicación donde tenga acceso de escritura:>>cron.out 2>&1 agregará la salida estándar y el error estándar a cron.out en el directorio de inicio del usuario que invoca.
• Si no redirige la salida de un cron trabajo, el daemon intentará enviarle cualquier salida o mensaje de error por correo electrónico. Revisa tu bandeja de entrada (tal vez simplemente more $MAIL si no tiene un cliente de correo). Si el correo no está disponible, tal vez busque un archivo llamado dead.letter en su directorio de inicio, o entradas de registro del sistema que indiquen que la salida se descartó. Especialmente en el último caso, probablemente edite el trabajo para agregar la redirección a un archivo, luego espere a que se ejecute el trabajo y examine el archivo de registro en busca de mensajes de error u otros comentarios útiles.
• Si está tratando de averiguar por qué algo falló, los mensajes de error serán visibles en este archivo. Léalo y compréndalo.

¿Todavía no funciona? ¡Ay!

1. Elevar el nivel de depuración de cron

• Debian
  • en /etc/default/cron
  • establecer EXTRA_OPTS="-L 2"
  • service cron restart
  • tail -f /var/log/syslog para ver los scripts ejecutados
• Ubuntu
  • en /etc/rsyslog.d/50-default.conf
  • añadir o comentar la línea cron.* /var/log/cron.log
  • recargar registrador sudo /etc/init.d/rsyslog restart
  • volver a ejecutar cron
  • abrir /var/log/cron.log y busque la salida de error detallada
• Recordatorio:desactive el nivel de registro cuando haya terminado con la depuración

1. Ejecute cron y verifique los archivos de registro nuevamente

Sintaxis de tareas programadas

# 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

Esta sintaxis es solo correcto para el root usuario. Usuario normal crontab la sintaxis no tiene el Usuario campo (los usuarios normales no pueden ejecutar código como cualquier otro usuario);

# 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

Comandos Crontab

1. crontab -l
   • Enumera todas las tareas cron del usuario.
2. crontab -e , para un usuario específico:crontab -e -u agentsmith
   • Inicia la sesión de edición de su archivo crontab.
   • Cuando sale del editor, el crontab modificado se instala automáticamente.
3. crontab -r
   • Elimina su entrada crontab de la cola de impresión cron, pero no del archivo crontab.

Quiero agregar 2 puntos que aprendí:

1. Los archivos de configuración de Cron colocados en /etc/cron.d/ no deben contener un punto (.). De lo contrario, no será leído por cron.
2. Si el usuario que ejecuta su comando no está en /etc/shadow. No se permitirá programar cron.

Referencias:

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

Finalmente encontré la solución. La siguiente es la solución:-

1. Nunca use una ruta relativa en los scripts de python para ejecutarlos a través de crontab. En su lugar, hice algo como esto:-

   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. Nunca suprima el código crontab, en su lugar use el servidor de correo y verifique el correo del usuario. Eso da una idea más clara de lo que está pasando.

Otra razón por la que crontab fallará:Manejo especial del % personaje.

Del archivo del manual:

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.

En mi caso particular, estaba usando date --date="7 days ago" "+%Y-%m-%d" para producir parámetros para mi secuencia de comandos, y estaba fallando en silencio. Finalmente descubrí lo que estaba pasando cuando revisé syslog y vi que mi comando estaba truncado en el % símbolo. Necesitas escapar así:

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

Vea aquí para más detalles:

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