CronJob no se está ejecutando

Solución:

¡¿WTF ?! ¡¿Mi cronjob no funciona ?!

Aquí hay una guía de lista de verificación para depurar sin ejecutar cronjobs:

1. ¿Se está ejecutando el demonio Cron?

• Correr ps ax | grep cron y busque cron.
• Debian: service cron start o service cron restart

2. ¿Está funcionando cron?

• * * * * * /bin/echo "cron works" >> /tmp/file
• ¿Sintaxis correcta? Vea abajo.
• 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 debería ser siempre modificable.
• Probablemente también agregue 2>&1 para incluir el error estándar, así como la salida estándar, o el error estándar de salida por separado a otro archivo con 2>>/tmp/errors

3. ¿El comando funciona de forma independiente?

• Verifique si la secuencia de comandos tiene un error, realizando una ejecución en seco en la CLI
• Cuando pruebe su comando, pruebe como el usuario cuyo crontab está editando, que podría no ser su nombre de usuario o root

4. ¿Puede cron ejecutar tu trabajo?

• Cheque /var/log/cron.log o /var/log/messages por errores.
• Ubuntu: grep CRON /var/log/syslog
• Sombrero rojo: /var/log/cron

5. Verificar 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

6. Verificar caminos

• comprobar la línea she-bangs / hashbangs
• no confíe en variables de entorno como PATH, ya que su valor probablemente no será el mismo en cron que en una sesión interactiva

7. No suprima la salida durante la depuración

• Se utiliza comúnmente esta supresión: 30 1 * * * command > /dev/null 2>&1
• Vuelva a habilitar la salida estándar o la salida de mensaje de error estándar quitando >/dev/null 2>&1 en total; o quizás redirigir a un archivo en una ubicación donde tenga acceso de escritura: >>cron.out 2>&1 agregará salida estándar y error estándar a cron.out en el directorio de inicio del usuario que invoca.
• Si está tratando de averiguar por qué algo falló, los mensajes de error serán visibles en este archivo. Léalo y entiéndalo.

¿Sigue sin funcionar? ¡Ay!

1. Elevar el nivel de depuración cron

• Debian
  • en /etc/default/cron
  • colocar 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.crit /var/log/cron.log
  • recargar registrador sudo /etc/init.d/rsyslog reload
  • volver a ejecutar cron
  • abierto /var/log/cron.log y busque salida de error detallada
• Recordatorio: desactive el nivel de registro cuando haya terminado con la depuración

2. Ejecute cron y verifique los archivos de registro nuevamente

Sintaxis de 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

Esta sintaxis es solamente correcto para el root usuario. Usuario regular crontab la sintaxis no tiene la 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 de 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 del cron spooler, pero no del archivo crontab.

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

Desde el archivo man:

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 script, y fallaba silenciosamente. Finalmente descubrí lo que estaba pasando cuando revisé syslog y vi que mi comando se truncó en el % símbolo. Necesitas escapar así:

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

Consulte aquí para obtener más detalles:

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

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

1. Nunca use la ruta relativa en los scripts de Python para que se ejecuten 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 mailserver y verifique el correo del usuario. Eso da una idea más clara de lo que está sucediendo.

---

---

Utiliza Nuestro Buscador