¿Por qué los scripts crontab no funcionan?

A menudo, los crontabscripts no se ejecutan según lo programado o como se esperaba. Existen numerosas razones para eso:

1. notación de crontab incorrecta
2. problema de permisos
3. Variables de entorno

Este wiki de la comunidad tiene como objetivo agregar las principales razones para que los crontabscripts no se ejecuten como se esperaba. Escribe cada razón en una respuesta separada.

Incluya una razón por respuesta (detalles sobre por qué no se ejecuta) y arregle (s) por esa razón.

Escriba solo problemas específicos de cron, por ejemplo, comandos que se ejecutan como se espera del shell pero que cron ejecuta erróneamente.

Ambiente diferente

Cron pasa un conjunto mínimo de variables de entorno a sus trabajos. Para ver la diferencia, agregue un trabajo ficticio como este:

* * * * * env> /tmp/env.output

Espere a /tmp/env.outputque se cree, luego elimine el trabajo nuevamente. Ahora compare el contenido de /tmp/env.outputcon la salida de envejecución en su terminal regular.

Un "problema" común aquí es que la PATHvariable de entorno es diferente. Tal vez la secuencia de comandos cron utiliza el comando somecommandque se encuentra en /opt/someApp/bin, que se ha añadido a PATHen /etc/environment? cron ignora PATHde ese archivo, por lo que la ejecución somecommandde su script fallará cuando se ejecute con cron, pero funcionará cuando se ejecute en una terminal. Vale la pena señalar que las variables de /etc/environmentse pasarán a los trabajos cron, pero no las variables que cron se establece específicamente, como PATH.

Para evitar eso, simplemente configure su propia PATHvariable en la parte superior del script. P.ej

#!/bin/bash
PATH=/opt/someApp/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

# rest of script follows

Algunos prefieren usar rutas absolutas a todos los comandos en su lugar. Recomiendo contra eso. Considere lo que sucede si desea ejecutar su script en un sistema diferente, y en ese sistema, el comando está en su /opt/someAppv2.2/binlugar. Tendría que pasar por todo el script reemplazando /opt/someApp/binen /opt/someAppv2.2/binlugar de simplemente hacer una pequeña edición en la primera línea del script.

También puede establecer la variable PATH en el archivo crontab, que se aplicará a todos los trabajos cron. P.ej

PATH=/opt/someApp/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

15 1 * * * backupscript --incremental /home /root

Mi principal problema: si olvida agregar una nueva línea al final del crontabarchivo. En otras palabras, el archivo crontab debe terminar con una línea vacía.

A continuación se encuentra la sección relevante en las páginas del manual para este problema ( man crontabluego salte al final):

   Although cron requires that each entry in a crontab end  in  a  newline
   character,  neither the crontab command nor the cron daemon will detect
   this error. Instead, the crontab will appear to load normally. However,
   the  command  will  never  run.  The best choice is to ensure that your
   crontab has a blank line at the end.

   4th Berkeley Distribution      29 December 1993               CRONTAB(1)

Cron daemon no se está ejecutando. Realmente lo arruiné hace algunos meses.

Tipo:

pgrep cron 

Si no ve ningún número, entonces cron no se está ejecutando. sudo /etc/init.d/cron startse puede usar para iniciar cron.

EDITAR: en lugar de invocar scripts de inicio a través de /etc/init.d, use la utilidad de servicio, p. Ej.

sudo service cron start

EDITAR: También podría usar systemctl en Linux moderno, por ejemplo

sudo systemctl start cron

El guión en nombres de archivo cron.d/, cron.daily/, cron.hourly/, etc, no debe contener puntos ( .), de otro modo run-parts saltarán ellos.

Ver run-parts (8):

   If neither the --lsbsysinit option nor the --regex option is given then
   the names must consist entirely of upper and lower case  letters,  dig‐
   its, underscores, and hyphens.

   If  the  --lsbsysinit  option  is given, then the names must not end in
   .dpkg-old  or .dpkg-dist or .dpkg-new or .dpkg-tmp, and must belong  to
   one  or more of the following namespaces: the LANANA-assigned namespace
   (^[a-z0-9]+$);   the   LSB   hierarchical   and   reserved   namespaces
   (^_?([a-z0-9_.]+-)+[a-z0-9]+$);  and  the  Debian cron script namespace
   (^[a-zA-Z0-9_-]+$).

Entonces, si tiene un script cron backup.sh, analyze-logs.plen el cron.daily/directorio, es mejor que elimine los nombres de extensión.

En muchos entornos, cron ejecuta comandos usando sh, mientras que muchas personas suponen que lo usará bash.

Sugerencias para probar o corregir esto para un comando que falla:

• Intente ejecutar el comando shpara ver si funciona:

  sh -c "mycommand"
  

• Envuelva el comando en un subshell bash para asegurarse de que se ejecute en bash:

  bash -c "mybashcommand"
  

• Dile a cron que ejecute todos los comandos en bash configurando el shell en la parte superior de tu crontab:

  SHELL=/bin/bash
  

• Si el comando es un script, asegúrese de que el script contenga un shebang:

  #!/bin/bash
  

Tuve algunos problemas con las zonas horarias. Cron estaba corriendo con la nueva zona horaria de instalación. La solución fue reiniciar cron:

sudo service cron restart

La ruta absoluta debe usarse para los scripts:

Por ejemplo, /bin/grepdebe usarse en lugar de grep:

# m h  dom mon dow   command
0 0 *  *  *  /bin/grep ERROR /home/adam/run.log &> /tmp/errors

En lugar de:

# m h  dom mon dow   command
0 0 *  *  *  grep ERROR /home/adam/run.log &> /tmp/errors

Esto es especialmente complicado, porque el mismo comando funcionará cuando se ejecute desde el shell. La razón es que cronno tiene la misma PATHvariable de entorno que el usuario.

Si su comando crontab tiene un %símbolo, cron intenta interpretarlo. Por lo tanto, si estaba utilizando algún comando con un %(como una especificación de formato para el comando de fecha), deberá escapar.

Eso y otros buenos trucos aquí:
http://www.pantz.org/software/cron/croninfo.html

Cron está llamando a un script que no es ejecutable.

Al ejecutar chmod +x /path/to/scripel script, se vuelve ejecutable y debe resolver este problema.

También es posible que la contraseña del usuario haya expirado. Incluso la contraseña de root puede caducar. Puede tail -f /var/log/cron.logy verá que cron fallará con la contraseña caducada. Puede configurar la contraseña para que nunca caduque haciendo esto:passwd -x -1 <username>

En algunos sistemas (Debian, Ubuntu), el registro de cron no está habilitado de forma predeterminada. En /etc/rsyslog.conf o /etc/rsyslog.d/50-default.conf la línea:

# cron.*                          /var/log/cron.log

debe ser editado ( sudo nano /etc/rsyslog.conf) sin comentarios para:

cron.*                          /var/log/cron.log

Después de eso, debe reiniciar rsyslog a través de

/etc/init.d/rsyslog restart

o

service rsyslog restart 

Fuente: Habilite el registro crontab en Debian Linux

En algunos sistemas (Ubuntu), el archivo de registro separado para cron no está habilitado de forma predeterminada, pero los registros relacionados con cron aparecen en el archivo syslog. Uno puede usar

cat /var/log/syslog | grep cron -i

para ver mensajes relacionados con cron.

Si su cronjob invoca aplicaciones GUI, debe decirles qué PANTALLA deben usar.

Ejemplo: lanzamiento de Firefox con cron.

Su script debe contener en export DISPLAY=:0alguna parte.

Los problemas de permisos son bastante comunes, me temo.

Tenga en cuenta que una solución común es ejecutar todo utilizando el crontab de root, que a veces es una idea realmente mala. Definir los permisos adecuados es definitivamente un problema que se pasa por alto en gran medida.

Permiso inseguro de la tabla cron

Se rechaza una tabla cron si su permiso es inseguro

sudo service cron restart
grep -i cron /var/log/syslog|tail -2
2013-02-05T03:47:49.283841+01:00 ubuntu cron[49906]: (user) INSECURE MODE (mode 0600 expected) (crontabs/user)

El problema se resuelve con

# correct permission
sudo chmod 600 /var/spool/cron/crontabs/user
# signal crond to reload the file
sudo touch /var/spool/cron/crontabs

El script es sensible a la ubicación. Esto está relacionado con el uso siempre de rutas absolutas en un script, pero no exactamente lo mismo. Es posible que su trabajo cron necesite cdun directorio específico antes de ejecutarse, por ejemplo, una tarea de rake en una aplicación Rails puede necesitar estar en la raíz de la aplicación para que Rake encuentre la tarea correcta, sin mencionar la configuración de base de datos adecuada, etc.

Entonces, una entrada crontab de

23 3 * * * /usr/bin/rake db:session_purge RAILS_ENV=production

sería mejor como

23 3 * * * cd / var / www / production / current && / usr / bin / rake db: session_purge RAILS_ENV = production

O, para mantener la entrada de crontab más simple y menos frágil:

23 3 * * * /home/<user>/scripts/session-purge.sh

con el siguiente código en /home/<user>/scripts/session-purge.sh:

cd / var / www / production / current
/ usr / bin / rake db: session_purge RAILS_ENV = producción

Las especificaciones de Crontab que funcionaban en el pasado pueden romperse cuando se mueven de un archivo crontab a otro. A veces, la razón es que ha movido la especificación de un archivo crontab del sistema a un archivo crontab de usuario o viceversa.

El formato de especificación de trabajo cron difiere entre los archivos crontab de los usuarios (/ var / spool / cron / username o / var / spool / cron / crontabs / username) y los crontabs del sistema ( /etc/crontaby los archivos en /etc/cron.d).

Los crontabs del sistema tienen un campo adicional 'usuario' justo antes del comando para ejecutar.

Esto provocará errores que indiquen cosas como george; command not foundcuando mueves un comando /etc/crontabo un archivo /etc/cron.dal archivo crontab de un usuario.

Por el contrario, cron entregará errores similares /usr/bin/restartxyz is not a valid usernameo similares cuando ocurra lo contrario.

El script cron invoca un comando con la opción --verbose

Tuve un error de secuencia de comandos cron en mí porque estaba en piloto automático mientras escribía la secuencia de comandos e incluí la opción --verbose:

#!/bin/bash
some commands
tar cvfz /my/archive/file.tar.gz /my/shared/directory
come more commands

El script se ejecutó bien cuando se ejecutó desde shell, pero falló cuando se ejecutó desde crontab porque la salida detallada va a stdout cuando se ejecuta desde shell, pero en ninguna parte cuando se ejecuta desde crontab. Solución fácil para eliminar la 'v':

#!/bin/bash
some commands
tar cfz /my/archive/file.tar.gz /my/shared/directory
some more commands

La razón más frecuente por la que he visto que cron falla en un horario incorrectamente establecido. Se necesita práctica para especificar un trabajo programado para las 11:15 pm como en 15 23 * * *lugar de * * 11 15 *o 11 15 * * *. El día de la semana para los trabajos después de la medianoche también se confunde MF es 2-6después de la medianoche, no 1-5. Las fechas específicas suelen ser un problema, ya que rara vez las usamos * * 3 1 *no es el 3 de marzo. Si no está seguro, consulte sus cronogramas cron en línea en https://crontab.guru/ .

Si su trabajo con diferentes plataformas utilizando opciones no compatibles, como las 2/3especificaciones de tiempo, también puede causar fallas. Esta es una opción muy útil pero no está disponible universalmente. También me he encontrado con problemas con listas como 1-5o 1,3,5.

El uso de rutas no calificadas también ha causado problemas. La ruta predeterminada suele ser /bin:/usr/binasí que solo se ejecutarán los comandos estándar. Estos directorios generalmente no tienen el comando deseado. Esto también afecta a los scripts que utilizan comandos no estándar. También pueden faltar otras variables de entorno.

Clobbering un crontab existente me ha causado problemas por completo. Ahora cargo desde una copia de archivo. Esto se puede recuperar del crontab existente usando crontab -lsi se golpea. Mantengo la copia de crontab en ~ / bin. Se comenta en todo momento y termina con la línea # EOF. Esto se recarga diariamente desde una entrada crontab como:

#! / usr / bin / crontab
# Recargar este crontab
# #
54 12 * * * $ {HOME} / bin / crontab

El comando de recarga anterior se basa en un crontab ejecutable con una ruta de acceso que ejecuta crontab. Algunos sistemas requieren la ejecución de crontab en el comando y la especificación del archivo. Si el directorio es compartido en red, a menudo lo uso crontab.$(hostname)como el nombre del archivo. Esto eventualmente corregirá los casos en los que se carga el crontab incorrecto en el servidor incorrecto.

El uso del archivo proporciona una copia de seguridad de lo que debería ser el crontab, y permite que las ediciones temporales (la única vez que uso crontab -e) se restituyan automáticamente. Hay encabezados disponibles que ayudan a obtener los parámetros de programación correctos. Los he agregado cuando los usuarios inexpertos estarían editando un crontab.

Raramente, me he encontrado con comandos que requieren la entrada del usuario. Estos fallan en crontab, aunque algunos funcionarán con la redirección de entrada.

Si está accediendo a una cuenta a través de claves SSH, es posible iniciar sesión en la cuenta, pero no se da cuenta de que la contraseña de la cuenta está bloqueada (por ejemplo, debido a intentos de contraseña vencidos o no válidos)

Si el sistema usa PAM y la cuenta está bloqueada, esto puede detener la ejecución de su cronjob. (He probado esto en Solaris, pero no en Ubuntu)

Puede encontrar mensajes como este en / var / adm / messages:

24 de octubre 07:51:00 mybox cron [29024]: [ID 731128 auth.notice] pam_unix_account: cron intenta validar la cuenta bloqueada myuser del host local
24 de octubre 07:52:00 mybox cron [29063]: [ID 731128 auth.notice] pam_unix_account: cron intenta validar la cuenta bloqueada myuser del host local
24 de octubre 07:53:00 mybox cron [29098]: [ID 731128 auth.notice] pam_unix_account: cron intenta validar la cuenta bloqueada myuser desde el host local
24 de octubre 07:54:00 mybox cron [29527]: [ID 731128 auth.notice] pam_unix_account: cron intenta validar la cuenta bloqueada myuser desde el host local

Todo lo que debe hacer es ejecutar:

# passwd -u <USERNAME>

como root para desbloquear la cuenta, y el crontab debería funcionar nuevamente.

Si tiene un comando como este:

* * * * * /path/to/script >> /tmp/output

y no funciona y no puede ver ningún resultado, no necesariamente significa que cron no está funcionando. El script podría romperse y la salida iría a stderr que no se pasa a / tmp / output. Comprueba que este no es el caso, capturando también esta salida:

* * * * * /path/to/script >> /tmp/output 2>&1

para ver si esto te ayuda a resolver tu problema.

=== Alerta Docker ===

Si estás usando docker,

Creo que es correcto agregar que no pude hacer que cron se ejecute en segundo plano.

Para ejecutar un trabajo cron dentro del contenedor, utilicé supervisor y ejecuté cron -f, junto con el otro proceso.

Editar: Otro problema: tampoco logré que funcionara al ejecutar el contenedor con la red HOST. Vea este problema aquí también: https://github.com/phusion/baseimage-docker/issues/144

Estaba escribiendo un script de instalación de shell que crea otro script para purgar los datos de transacciones anteriores de una base de datos. Como parte de la tarea, tenía que configurar el crontrabajo diario para ejecutarse en un momento arbitrario, cuando la carga de la base de datos era baja.

Creé un archivo mycronjobcon cron cronograma, nombre de usuario y el comando y lo copié en el /etc/cron.ddirectorio. Mis dos trampas:

1. mycronjob el archivo tenía que ser propiedad de root para ejecutarse
2. Tuve que configurar los permisos del archivo a 644 - 664 no se ejecutaría.

Un problema de permiso aparecerá /var/log/syslogcomo algo similar a:

Apr 24 18:30:01 ip-11-22-33-44 cron[40980]: (*system*) INSECURE MODE (group/other writable) (/etc/crontab)
Apr 24 18:30:01 ip-11-22-33-44 cron[40980]: (*system*) INSECURE MODE (group/other writable) (/etc/cron.d/user)

La primera línea se refiere al /etc/crontabarchivo y la posterior a un archivo que coloqué debajo /etc/cront.d.

Línea escrita de una manera que crontab no entiende. Tiene que estar escrito correctamente. Aquí está CrontabHowTo .

Cron daemon podría estar ejecutándose, pero en realidad no funciona. Intenta reiniciar cron:

sudo /etc/init.d/cron restart

Escribir en cron a través de "crontab -e" con el argumento de nombre de usuario en una línea. He visto ejemplos de usuarios (o administradores de sistemas) que escriben sus scripts de shell y no entienden por qué no se automatizan. El argumento "usuario" existe en / etc / crontab, pero no en los archivos definidos por el usuario. entonces, por ejemplo, su archivo personal sería algo como:

# m h dom mon dow command

* * */2  *   *  /some/shell/script

mientras que / etc / crontab sería:

# m h dom mon dow user   command

* * */2  *   *  jdoe   /some/shell/script

Entonces, ¿por qué harías lo último? Bueno, dependiendo de cómo desee establecer sus permisos, esto puede ser muy complicado. He escrito guiones para automatizar tareas para usuarios que no entienden las complejidades o que no quieren molestarse con el trabajo pesado. Al establecer permisos para --x------, puedo hacer que el script sea ejecutable sin que puedan leerlo (y quizás cambiarlo accidentalmente). Sin embargo, es posible que desee ejecutar este comando con varios otros desde un archivo (lo que hace que sea más fácil de mantener), pero asegúrese de que la salida del archivo esté asignada al propietario correcto. Al hacerlo (al menos en Ubuntu 10.10) se interrumpe tanto la incapacidad para leer el archivo como para ejecutarlo, más el problema antes mencionado de poner períodos en / etc / crontab (que, curiosamente, no causa ningún error al pasar crontab -e) .

A modo de ejemplo, he visto instancias sudo crontab -eutilizadas para ejecutar un script con permisos de root, con un correspondiente chown username file_outputen el script de shell. Descuidado, pero funciona. En mi humilde opinión, la opción más elegante es ponerlo /etc/crontabcon el nombre de usuario declarado y los permisos adecuados, por lo que file_outputva al lugar correcto y al propietario.

A partir de lo que Aaron Peart mencionó sobre el modo detallado, a veces las secuencias de comandos que no están en modo detallado se inicializarán pero no finalizarán si el comportamiento predeterminado de un comando incluido es generar una línea o más en la pantalla una vez que se inicia el proceso. Por ejemplo, escribí un script de respaldo para nuestra intranet que usaba curl, una utilidad que descarga o carga archivos a servidores remotos, y es bastante útil si solo puede acceder a dichos archivos remotos a través de HTTP. El uso de 'curl http://something.com/somefile.xls ' estaba causando que un script que escribí se bloqueara y nunca completara porque escupe una nueva línea seguida de una línea de progreso. Tuve que usar el indicador de silencio (-s) para decirle que no mostrara ninguna información y escribir mi propio código para controlar si el archivo no se pudo descargar.

Aunque puede definir variables de entorno en su crontable, no está en un script de shell. Entonces las construcciones como las siguientes no funcionarán:

SOME_DIR=/var/log
MY_LOG_FILE=${SOME_LOG}/some_file.log

BIN_DIR=/usr/local/bin
MY_EXE=${BIN_DIR}/some_executable_file

0 10 * * * ${MY_EXE} some_param >> ${MY_LOG_FILE}

Esto se debe a que las variables no se interpretan en el crontable: todos los valores se toman literalmente. Y esto es lo mismo si omite los corchetes. Por lo tanto, sus comandos no se ejecutarán y sus archivos de registro no se escribirán ...

En su lugar, debe definir todas las variables de entorno directamente:

SOME_DIR=/var/log
MY_LOG_FILE=/var/log/some_file.log

BIN_DIR=/usr/local/bin
MY_EXE=/usr/local/bin/some_executable_file

0 10 * * * ${MY_EXE} some_param >> ${MY_LOG_FILE}

Cuando se ejecuta una tarea dentro de cron, stdin se cierra. Los programas que actúan de manera diferente en función de si stdin está disponible o no se comportarán de manera diferente entre la sesión de shell y en cron.

Un ejemplo es el programa goaccesspara analizar archivos de registro del servidor web. Esto NO funciona en cron:

goaccess -a -f /var/log/nginx/access.log > output.html

y goaccessmuestra la página de ayuda en lugar de crear el informe. En la cáscara esto se puede reproducir con

goaccess -a -f /var/log/nginx/access.log > output.html < /dev/null

La solución goaccesses hacer que lea el registro desde stdin en lugar de leerlo desde el archivo, por lo que la solución es cambiar la entrada crontab a

cat /var/log/nginx/access.log | goaccess -a > output.html

En mi caso, cron y crontab tenían diferentes propietarios.

NO funcionaba tuve esto:

User@Uva ~ $ ps -ef | grep cron | grep -v grep
User    2940    7284 pty1     19:58:41 /usr/bin/crontab
SYSTEM   11292     636 ?        22:14:15 /usr/sbin/cro 

Básicamente tuve que ejecutar cron-config y responder las preguntas correctamente. Hay un punto en el que se me solicitó ingresar mi contraseña de usuario de Win7 para mi cuenta de 'Usuario'. Por lo que leí, parece que este es un posible problema de seguridad, pero soy el único administrador en una sola red doméstica, así que decidí que estaba bien.

Aquí está la secuencia de comandos que me puso en marcha:

User@Uva ~ $ cron-config
The cron daemon can run as a service or as a job. The latter is not recommended.
Cron is already installed as a service under account LocalSystem.
Do you want to remove or reinstall it? (yes/no) yes
OK. The cron service was removed.

Do you want to install the cron daemon as a service? (yes/no) yes
Enter the value of CYGWIN for the daemon: [ ] ntsec

You must decide under what account the cron daemon will run.
If you are the only user on this machine, the daemon can run as yourself.
   This gives access to all network drives but only allows you as user.
To run multiple users, cron must change user context without knowing
  the passwords. There are three methods to do that, as explained in
  http://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-nopasswd1
If all the cron users have executed "passwd -R" (see man passwd),
  which provides access to network drives, or if you are using the
  cyglsa package, then cron should run under the local system account.
Otherwise you need to have or to create a privileged account.
  This script will help you do so.
Do you want the cron daemon to run as yourself? (yes/no) no

Were the passwords of all cron users saved with "passwd -R", or
are you using the cyglsa package ? (yes/no) no

Finding or creating a privileged user.
The following accounts were found: 'cyg_server' .
This script plans to use account cyg_server.
Do you want to use another privileged account name? (yes/no) yes
Enter the other name: User

Reenter: User


Account User already exists. Checking its privileges.
INFO: User is a valid privileged account.
INFO: The cygwin user name for account User is User.

Please enter the password for user 'User':
Reenter:
Running cron_diagnose ...
... no problem found.

Do you want to start the cron daemon as a service now? (yes/no) yes
OK. The cron daemon is now running.

In case of problem, examine the log file for cron,
/var/log/cron.log, and the Windows event log (using /usr/bin/cronevents)
for information about the problem cron is having.

Examine also any cron.log file in the HOME directory
(or the file specified in MAILTO) and cron related files in /tmp.

If you cannot fix the problem, then report it to [email protected].
Please run the script /usr/bin/cronbug and ATTACH its output
(the file cronbug.txt) to your e-mail.

WARNING: PATH may be set differently under cron than in interactive shells.
         Names such as "find" and "date" may refer to Windows programs.


User@Uva ~ $ ps -ef | grep cron | grep -v grep
    User    2944   11780 ?        03:31:10 /usr/sbin/cron
    User    2940    7284 pty1     19:58:41 /usr/bin/crontab

User@Uva ~ $

En mis servidores RHEL7, los trabajos cron de root se ejecutarían, pero los trabajos de usuario no. Descubrí que sin un directorio de inicio, los trabajos no se ejecutarán (pero verá buenos errores en / var / log / cron). Cuando creé el directorio de inicio, el problema se resolvió.

Si editó su archivo crontab usando un editor de Windows (a través de samba o algo así) y reemplazó las nuevas líneas con \ n \ r o simplemente \ r, cron no se ejecutará.

Además, si está usando /etc/cron.d/* y uno de esos archivos tiene \ r, cron se moverá a través de los archivos y se detendrá cuando llegue a un archivo defectuoso. ¿No estás seguro si ese es el problema?

Utilizar:

od -c /etc/cron.d/* | grep \r