CronJob no se está ejecutando

He configurado cronjob para usuario root en el entorno ubuntu de la siguiente manera escribiendo crontab -e

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 

Pero el cronjon no se ejecuta. He intentado verificar si el cronjob se está ejecutando usando

pgrep cron

y eso da el id. de proceso 3033. El scrip de shell se llama al archivo python y se usa para enviar correos electrónicos. Ejecutar el archivo python está bien. No hay ningún error, pero cron no se ejecuta. El archivo daily.sh tiene el siguiente código.

 python /srv/www/live/CronJobs/daily.py python /srv/www/live/CronJobs/notification_email.py python /srv/www/live/CronJobs/log_kpi.py 

    ¡¿WTF ?! Mi cronjob no se ejecuta?

    Aquí hay una guía de lista de comprobación para depurar no ejecutando cronjobs:

    1. ¿Está funcionando el daemon Cron?
      • Ejecute ps ax | grep cron ps ax | grep cron y busca cron.
      • Debian: service cron start service cron restart o service cron restart
    2. Está cron trabajando?
      • * * * * * /bin/echo "cron works" >> /tmp/file
      • Sintaxis correcta? Vea abajo.
      • Obviamente necesita tener acceso de escritura al archivo al que está redireccionando la salida. Un nombre de archivo único en /tmp que no existe actualmente siempre debe poder escribirse.
    3. ¿El comando funciona de manera independiente?
      • Compruebe si el script tiene un error, haciendo 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 raíz
    4. ¿Puede cron ejecutar tu trabajo?
      • Compruebe /var/log/cron.log o /var/log/messages para ver si hay errores.
      • Ubuntu: grep CRON /var/log/syslog
      • Redhat: /var/log/cron
    5. Compruebe los permisos
      • establecer la 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. Revisa las rutas
      • comprobar 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
    7. No suprima la salida mientras se depura
      • comúnmente utilizado es esta supresión: 30 1 * * * command > /dev/null 2>&1
      • volver a habilitar la salida estándar o salida de mensaje de error estándar

    ¿Sigue sin funcionar? ¡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
        • agregar o comentar la línea cron.crit /var/log/cron.log
        • reload logger sudo /etc/init.d/rsyslog reload
        • volver a ejecutar cron
        • abra /var/log/cron.log y busque la salida de error detallada
      • Recordatorio: desactivar 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 syntax solo es correcta para el usuario root . La syntax crontab usuario regular no tiene el campo Usuario (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 tu archivo crontab.
      • Cuando sale del editor, el crontab modificado se instala automáticamente.
    3. crontab -r
      • Elimina su entrada de crontab de la cola de cron, pero no del archivo crontab.

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

    1. Nunca use la ruta relativa en las secuencias de comandos de Python para ser ejecutada a través de crontab. Hice algo como esto en su lugar:

       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 para el usuario. Eso da una idea más clara de lo que está sucediendo.

    Otra razón por la cual crontab fallará: manejo especial del carácter % .

    Del 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 en mi script, y estaba fallando silenciosamente. Finalmente descubrí lo que sucedía cuando revisé syslog y vi que mi comando se truncó en el símbolo % . Debes escapar de esta manera:

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

    Mira aquí para más detalles:

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

    Quiero agregar 2 puntos que aprendí:

    1. Los archivos de configuración de Cron puestos en /etc/cron.d/ no deben contener un punto (.). De lo contrario, cron no lo leerá.
    2. Si el usuario que ejecuta su comando no está en / etc / shadow. No se permitirá progtwigr cron.

    Refs:

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

    He encontrado otra razón para que el crontab del usuario no se ejecute: el nombre de host no está presente en el archivo de hosts:

     user@ubuntu:~$ cat /etc/hostname ubuntu 

    Ahora el archivo de hosts:

     user@ubuntu:~$ 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 

    Esto está en un Ubuntu 14.04.3 LTS, la manera de arreglarlo es agregar el nombre de host al archivo hosts para que se asemeje a algo como esto:

     user@ubuntu:~$ 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 

    Para mí, la solución fue que el archivo cron que intentaba ejecutar estaba en un directorio cifrado, más específicamente un directorio de usuario en / home /. Aunque el crontab se configuró como root, porque el script que se ejecutaba existía en un directorio de usuario cifrado en / home / cron solo podía leer este directorio cuando el usuario estaba realmente conectado. Para ver si el directorio está encriptado, verifique si este directorio existe:

     /home/.ecryptfs/ 

    si es así, entonces tienes un directorio de inicio encriptado.

    La solución para mí fue mover el script a un directorio no = encriptado y todo funcionó bien.

    Experimenté el mismo problema donde los crones no se están ejecutando. Lo arreglamos cambiando los permisos y el propietario por parte de Crons como propietario de la raíz, como lo mencionamos en crontab y Cronjobs 644.

    Algunas veces, el comando que cron necesita ejecutar se encuentra en un directorio donde cron no tiene acceso, normalmente en sistemas donde los permisos de los directorios de usuario son 700 y el comando está en ese directorio.