linux - tasks - crontab not running script ubuntu

CronJob no corre

Question

He configurado el cronjob para el usuario root en el entorno de 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 comprobar si el cronjob se ejecuta utilizando

pgrep cron

y eso le da al ID de proceso 3033. El script de shell se llama archivo python y se usa para enviar correos electrónicos. Ejecutar el archivo python está bien. No hay error en ello, pero el 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

Answer 1

A veces, el comando que debe ejecutar cron está en un directorio donde cron no tiene acceso, generalmente en sistemas donde los permisos de los directorios personales de los usuarios son 700 y el comando está en ese directorio.

Answer 2

Experimenté el mismo problema donde los crons no están corriendo. Lo arreglamos cambiando los permisos y el propietario por Crons se hizo propietario de la raíz como lo mencionamos en crontab Y Cronjobs 644 permiso dado

Answer 3

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

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

Answer 4

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

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

Ahora el archivo 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 forma de solucionarlo es agregar el nombre de host al archivo hosts para que se parezca 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

Answer 5

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

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 generar parámetros para mi script, y estaba fallando silenciosamente. Finalmente, descubrí lo que estaba pasando cuando revisé syslog y vi que mi comando estaba truncado en el símbolo % . Necesitas escapar de esta manera:

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/

Answer 6

Para mí, la solución fue que el archivo cron intentaba ejecutarse en un directorio encriptado, más específicamente un directorio de usuario en / home /. Aunque el crontab se configuró como root, porque el script que se está ejecutando existe 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á cifrado, verifique si existe este directorio:

/home/.ecryptfs/<yourusername>

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

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

Answer 7

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 le permitirá programar cron.

Refs:

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

Answer 8

WTF ?! Mi cronjob no funciona ?!

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

1. ¿Se está ejecutando el demonio Cron?
   • Ejecutar ps ax | grep cron ps ax | grep cron y buscar cron.
   • Debian: service cron start o service cron restart
2. ¿Está trabajando 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 escribible.
3. ¿El comando funciona de manera independiente?
   • Compruebe si la secuencia de comandos tiene un error, realizando una ejecución en seco en la CLI
   • al probar su comando, pruebe como el usuario cuyo crontab está editando, que podría no ser su nombre de usuario o su raíz
4. ¿Puede cron ejecutar su trabajo?
   • Verifique /var/log/cron.log o /var/log/messages para ver si hay errores.
   • Ubuntu: grep CRON /var/log/syslog
   • Redhat: /var/log/cron
5. Comprobar permisos
   • establecer el indicador de 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. Comprobar caminos
   • revisar la línea de she-bangs / hashbangs
   • no confíe en variables de entorno como PATH, ya que su valor probablemente no será el mismo en cron como en una sesión interactiva
7. No suprimir la salida durante la depuración
   • comúnmente se usa esta supresión: 30 1 * * * command > /dev/null 2>&1
   • volver a habilitar la salida estándar o la salida de mensaje de error estándar

¿Sigue sin funcionar? ¡Ay!

1. Elevar el nivel de depuración 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 resultados de error detallados
   • Recordatorio: desactivar el nivel de registro, cuando haya terminado con la depuración
2. Ejecutar cron y revisar los archivos de registro de nuevo

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 solo es correcta para el usuario root . La sintaxis 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 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.
   • Al salir del editor, el crontab modificado se instala automáticamente.
3. crontab -r
   • Elimina la entrada de crontab de la cola de espera cron, pero no del archivo crontab.