¿Por qué los scripts crontab no funcionan?

452

A menudo, las secuencias de comandos crontab no se ejecutan según lo previsto o como se esperaba. Hay muchas razones para eso:

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

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

Incluya un motivo por respuesta - detalles sobre por qué no se ejecuta - y solucione el problema por ese único motivo.

Escribe solo problemas específicos de cron, p. comandos que se ejecutan según lo esperado del shell pero se ejecutan erróneamente por cron.

    
pregunta Adam Matan 08.05.2017 - 20:15

46 respuestas

430

Entorno diferente

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

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

Espere a que se cree /tmp/env.output , luego elimine el trabajo nuevamente. Ahora compare los contenidos de /tmp/env.output con la salida de env ejecutada en su terminal regular.

Un "gotcha" común aquí es la variable de entorno PATH siendo diferente. Tal vez tu script cron use el comando somecommand encontrado en /opt/someApp/bin , que has agregado a PATH en /etc/environment ? cron omite PATH de ese archivo, por lo que la ejecución somecommand de la secuencia de comandos fallará cuando se ejecute con cron, pero funcionará cuando se ejecute en una terminal. Vale la pena señalar que las variables de /etc/environment se transmitirán a las tareas de cron, pero no a las variables que cron específicamente establece, como PATH .

Para solucionarlo, simplemente configure su propia variable PATH en la parte superior del script. Por ejemplo,

#!/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 quiere ejecutar su script en un sistema diferente, y en ese sistema, el comando está en /opt/someAppv2.2/bin en su lugar. Tendría que pasar por el script completo reemplazando /opt/someApp/bin con /opt/someAppv2.2/bin en lugar 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. Por ejemplo,

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

15 1 * * * backupscript --incremental /home /root
    
respondido por el geirha 27.02.2018 - 19:47
287

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

A continuación, se muestra la sección relevante en las páginas de manual para este número ( man crontab luego omita hasta el 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)
    
respondido por el user4124 02.02.2011 - 21:32
122

Cron daemon no se está ejecutando. Realmente arruiné esto hace unos meses.

Tipo:

pgrep cron 

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

EDITAR: En lugar de invocar scripts de inicio a través de /etc/init.d, use el servicio utilidad, por ejemplo,

sudo service cron start
    
respondido por el 4 revs, 4 users 38%user6019 26.01.2012 - 11:57
82

Los nombres de archivo de script en cron.d/ , cron.daily/ , cron.hourly/ , etc., no deben contener punto ( . ), de lo contrario, run-parts los saltará.

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.pl en cron.daily/ directory, será mejor que elimine los nombres de las extensiones.

    
respondido por el Xiè Jìléi 10.01.2017 - 16:20
55

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

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

  • Intenta ejecutar el comando en sh para ver si funciona
  • Envuelve el comando en una subshell bash para asegurarte de que se ejecute en bash:
    bash -c "mybashcommand"
  • Dile a cron que ejecute todos los comandos en bash estableciendo 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
respondido por el Ian Mackinnon 25.06.2011 - 21:30
34

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

sudo service cron restart
    
respondido por el luissquall 07.02.2012 - 15:49
29

Si su comando crontab tiene un símbolo % , cron intenta interpretarlo. Por lo tanto, si estaba usando un comando con un % en él (como una especificación de formato al comando de fecha), tendrá que escapar de él.

Eso y otros buenos problemas aquí:
enlace

    
respondido por el JMS 26.08.2012 - 08:59
28

Se debe usar una ruta absoluta para los scripts:

Por ejemplo, se debe usar /bin/grep 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 cron no tiene la misma variable de entorno PATH que el usuario.

    
respondido por el Adam Matan 24.01.2011 - 11:02
23

También es posible que la contraseña del usuario haya caducado. Incluso la contraseña de root puede caducar. Puedes tail -f /var/log/cron.log y verás que el cron falla con la contraseña expirada. Puede configurar la contraseña para que nunca caduque al hacer esto: passwd -x -1 <username>

En algunos sistemas (Debian, Ubuntu) el inicio de sesión para cron no está habilitado por defecto. En /etc/rsyslog.conf o /etc/rsyslog.d/50-default.conf la línea:

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

debe editarse ( sudo nano /etc/rsyslog.conf ) sin comentar a:

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: Habilitar el registro crontab en Debian Linux

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

cat /var/log/syslog | grep cron

para ver los mensajes relacionados con cron.

    
respondido por el 6 revs, 5 users 34%unknown 11.05.2016 - 12:48
20

Cron llama a un script que no es ejecutable.

Al ejecutar chmod +x /path/to/scrip , la secuencia de comandos se vuelve ejecutable y debería resolver este problema.

    
respondido por el jet 26.01.2011 - 19:24
16

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

Ejemplo: lanzamiento de Firefox con cron.

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

    
respondido por el andrew 26.07.2012 - 17:46
14

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. Establecer los permisos adecuados definitivamente es un tema que se pasa por alto.

    
respondido por el user9521 26.01.2011 - 16:53
13

Permiso de tabla cron inseguro

Una tabla cron es rechazada 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
    
respondido por el John Peterson 15.06.2013 - 05:12
10

El script es sensible a la ubicación. Esto está relacionado con usar siempre rutas absolutas en un script, pero no exactamente lo mismo. Su trabajo cron puede necesitar cd a un directorio específico antes de ejecutar, p. una tarea de rake en una aplicación Rails puede necesitar estar en la raíz de la aplicación Rake para encontrar la tarea correcta, sin mencionar la configuración adecuada de la base de datos, etc.

Entonces, una entrada de crontab de

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

sería mejor que

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

O bien, 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=production
    
respondido por el pjmorse 29.11.2011 - 16:20
10

Las especificaciones de Crontab que funcionaron en el pasado pueden romperse cuando se mueven de un archivo crontab a otro. En ocasiones, 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 cron de trabajo difiere entre los archivos crontab de los usuarios (/ var / spool / cron / username o / var / spool / cron / crontabs / username) y los crontabs del sistema ( /etc/crontab y los archivos en /etc/cron.d ).

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

Esto causará errores que indiquen cosas como george; command not found cuando mueva un comando de /etc/crontab o un archivo en /etc/cron.d en el archivo crontab de un usuario.

Por el contrario, cron generará errores como /usr/bin/restartxyz is not a valid username o similar cuando ocurra lo contrario.

    
respondido por el pbr 25.10.2013 - 17:04
9

script cron invoca un comando con --verbose option

Hice que fallara un script cron porque estaba en piloto automático mientras escribía el script e incluí la opción --verbose:

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

La secuencia de comandos funcionó bien cuando se ejecutaba desde el shell, pero falló al ejecutarse desde crontab porque la salida detallada se usa para stdout cuando se ejecuta desde el shell, pero en ningún lugar 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
    
respondido por el Aaron Peart 03.06.2012 - 08:59
7

Razón más frecuente por la que he visto fallar cron en un cronograma incorrectamente establecido. Se necesita práctica para especificar un trabajo programado para las 11:15 p.m. como 30 23 * * * en lugar de * * 11 15 * o 11 15 * * * . El día de la semana para trabajos posteriores a la medianoche también se confunde M-F es 2-6 después de la medianoche no 1-5 . Las fechas específicas suelen ser un problema ya que raramente las usamos * * 3 1 * no es el 3 de marzo.

Si trabaja con plataformas diferentes que usan opciones no compatibles como 2/3 in time, las especificaciones también pueden causar fallas. Esta es una opción muy útil pero no universalmente disponible. También me he encontrado con listas de problemas como 1-5 o 1,3,5 .

El uso de rutas no calificadas también ha causado problemas. La ruta predeterminada suele ser /bin:/usr/bin , por lo 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 usan comandos no estándar. También pueden faltar otras variables de entorno.

Bloquear completamente un crontab existente me ha causado problemas. Ahora cargo desde una copia de archivo. Esto puede recuperarse del crontab existente usando crontab -l si se destruye. Guardo la copia de crontab en ~ / bin. Se comenta en todo momento y finaliza con la línea # EOF . Esto se carga diariamente desde una entrada de crontab como:

#!/usr/bin/crontab
# Reload this crontab
#
54 12    *   *   *   ${HOME}/bin/crontab

El comando de recarga anterior se basa en un crontab ejecutable con una ruta bang ejecutando crontab. Algunos sistemas requieren ejecutar crontab en el comando y especificar el archivo. Si el directorio está compartido en la red, a menudo uso crontab.$(hostname) como el nombre del archivo. Esto eventualmente corregirá los casos en los que se cargue el crontab incorrecto en el servidor incorrecto.

El uso del archivo proporciona una copia de seguridad de lo que debe ser el crontab, y permite que las ediciones temporales (la única vez que uso crontab -e ) se retiren 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.

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

    
respondido por el BillThor 01.02.2011 - 19:37
6

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

Si el sistema está usando PAM y la cuenta está bloqueada, esto puede impedir que se ejecute cronjob. (He probado esto en Solaris, pero no en Ubuntu)

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

Oct 24 07:51:00 mybox cron[29024]: [ID 731128 auth.notice] pam_unix_account: cron attempting to validate locked account myuser from local host
Oct 24 07:52:00 mybox cron[29063]: [ID 731128 auth.notice] pam_unix_account: cron attempting to validate locked account myuser from local host
Oct 24 07:53:00 mybox cron[29098]: [ID 731128 auth.notice] pam_unix_account: cron attempting to validate locked account myuser from local host
Oct 24 07:54:00 mybox cron[29527]: [ID 731128 auth.notice] pam_unix_account: cron attempting to validate locked account myuser from local host

Todo lo que debe hacer es ejecutar:

# passwd -u <USERNAME>

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

    
respondido por el JohnGH 24.10.2012 - 09:22
4

Si tiene un comando como este:

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

y no funciona y no se puede ver ningún resultado, puede no significar necesariamente que cron no está funcionando. La secuencia de comandos podría estar rota y la salida iría a stderr que no pasará a / tmp / output. Comprueba que este no es el caso, al capturar también esta salida:

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

para ver si esto lo ayuda a detectar su problema.

    
respondido por el Philluminati 18.04.2018 - 20:26
3

=== Alerta de acoplador ===

Si usa la ventana acoplable,

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é el supervisor y ejecuté cron -f , junto con el otro proceso.

Editar: Otro problema: tampoco conseguí que funcionara al ejecutar el contenedor con la red HOST. Consulte también este problema: enlace

    
respondido por el AlonL 20.05.2015 - 17:48
3

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

NO funciona. Tenía 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 la lectura que hice, parece que este es un problema potencial 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 impulsó:

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 cygwin@cygwin.com.
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 ~ $
    
respondido por el KiloOne 10.12.2015 - 10:20
3

Estaba escribiendo una secuencia de comandos de instalación de shell que crea otra secuencia de comandos para purgar los datos de transacciones anteriores de una base de datos. Como parte de la tarea, tenía que configurar el trabajo diario cron para que se ejecutara en un momento arbitrario, cuando la carga de la base de datos era baja.

Creé un archivo mycronjob con cronograma cron, nombre de usuario y amp; el comando y lo copió en el directorio /etc/cron.d . Mis dos problemas:

  1. El archivo mycronjob debe ser propiedad de root para ejecutar
  2. Tuve que configurar los permisos del archivo en 644 - 664 no se ejecutarían.

Aparecerá un problema de permiso en /var/log/syslog como 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 archivo /etc/crontab y la última a un archivo que coloqué debajo de /etc/cront.d .

    
respondido por el Izik Golan 24.04.2017 - 21:53
2

Línea escrita de una manera que crontab no entiende. Necesita ser escrito correctamente. Aquí hay CrontabHowTo .

    
respondido por el Kangarooo 02.02.2011 - 20:52
2

Cron daemon podría estar ejecutándose, pero no funcionar realmente. Prueba a reiniciar cron:

sudo /etc/init.d/cron restart
    
respondido por el Phil Dodd 25.11.2011 - 00:20
2

Escribir a cron mediante "crontab -e" con el argumento de nombre de usuario en una línea. He visto ejemplos de usuarios (o administradores de sistemas) escribiendo sus scripts de shell y sin entender 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 así 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 esto último? Bueno, dependiendo de cómo quiera establecer sus permisos, esto puede volverse muy intrincado. He escrito guiones para automatizar tareas para usuarios que no entienden las complejidades, o no quieren molestarse con el trabajo pesado. Al establecer permisos en --x------ , puedo hacer que el script sea ejecutable sin que ellos puedan leerlo (y quizás cambiarlo accidentalmente). Sin embargo, es posible que desee ejecutar este comando con varios otros de un archivo (lo que hace que sea más fácil de mantener), pero asegúrese de que a la salida del archivo se le asigna el propietario correcto. Al hacerlo (al menos en Ubuntu 10.10) se rompe tanto la incapacidad de leer el archivo como su ejecución, más el problema antes mencionado de poner períodos en / etc / crontab (lo cual, curiosamente, no causa ningún error al pasar por crontab -e ).

Como ejemplo, he visto ejemplos de sudo crontab -e utilizado para ejecutar un script con permisos de root, con un chown username file_output correspondiente en el script de shell. Sloppy, pero funciona. En mi humilde opinión, la opción más elegante es ponerlo en /etc/crontab con el nombre de usuario declarado y los permisos adecuados, por lo que file_output va al lugar y propietario correctos.

    
respondido por el Mange 12.06.2012 - 19:42
2

Partiendo de lo que Aaron Peart mencionó sobre el modo detallado, a veces los scripts que no están en modo detallado se inicializan pero no finalizan 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 enlace ' hacía que una secuencia de comandos que escribí cuelgue y nunca se complete porque arroja una nueva línea seguida de una línea de progreso. Tuve que usar el indicador silencioso (-s) para indicarle que no emitiera ninguna información, y escribir en mi propio código para manejar si el archivo no se pudo descargar.

    
respondido por el Mange 12.06.2012 - 22:06
2

Aunque puede definir variables de entorno en su crontable, no está en un script de shell. Entonces 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 omites 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}
    
respondido por el Alexandre 07.06.2013 - 11:13
2

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

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

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

y goaccess muestra la página de ayuda en lugar de crear el informe. En el shell esto se puede reproducir con

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

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

cat /var/log/nginx/access.log | goaccess -a > output.html
    
respondido por el Martijn de Milliano 09.08.2013 - 22:27
2

En mis servidores RHEL7, los trabajos cron de raíz se ejecutarían, pero los trabajos de los usuarios 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 fue resuelto.

    
respondido por el Dennis Parslow 02.02.2017 - 22:29
2

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

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

Uso:

od -c /etc/cron.d/* | grep \r
    
respondido por el Doug 20.04.2017 - 03:38

Lea otras preguntas en las etiquetas