¿Cómo depurar un problema de crons que no ejecuta un script determinado u otro?

Question

Tengo un script de Rails que me gustaría ejecutar diariamente. Sé que hay muchos enfoques, y que un enfoque cron'd script / runner es mal visto por algunos, pero parece satisfacer mis necesidades.

Sin embargo, mi script no se ejecuta según lo programado.

Mi aplicación reside en / data / myapp / current , y el script está en script / myscript.rb . Puedo ejecutarlo manualmente sin problema como root con:

/data/myapp/current/script/runner -e production /data/myapp/current/script/myscript.rb

Cuando hago eso, el archivo de registro especial ( log / myscript.log ) se registra como se esperaba:

Tue Mar 03 13:16:00 -0500 2009 Starting to execute script...
...
Tue Mar 03 13:19:08 -0500 2009 Finished executing script in 188.075028 seconds

Lo tengo configurado para ejecutarse con cron cada mañana a las 4 am. Crontab de root :

$ crontab -l
0 4 * * * /data/myapp/current/script/runner -e production /data/myapp/current/script/myscript.rb

De hecho, ¡parece que se intentó correr tan recientemente como esta mañana!

$ tail -100 /var/log/cron
...
Mar  2 04:00:01 hostname crond[8894]: (root) CMD (/data/myapp/current/script/runner -e production /data/myapp/current/script/myscript.rb)
...
Mar  3 04:00:01 hostname crond[22398]: (root) CMD (/data/myapp/current/script/runner -e production /data/myapp/current/script/myscript.rb)
...

Sin embargo, no hay ninguna entrada en mi archivo de registro y los datos que debería actualizar no se han actualizado. Los permisos del archivo de registro (como una prueba) incluso se configuraron para escritura global:

$ ls -lh
total 19M
...
-rw-rw-rw- 1 myuser apps 7.4K Mar  3 13:19 myscript.log
...

Estoy corriendo en CentOS 5.

Así que mis preguntas son ...

1. ¿Dónde más puedo buscar información para depurar esto?
2. ¿Podría ser esto un problema de SELinux? ¿Hay algún contexto de seguridad que pueda establecer o cambiar que pueda resolver este error?

¡Gracias!

Actualizar

Gracias a Paul y Luke. Resultó ser un problema de entorno, y la captura del stderr en un archivo de registro me permitió encontrar el error.

$ cat cron.log 
/usr/bin/env: ruby: No such file or directory

$ head /data/myapp/current/script/runner 
#!/usr/bin/env ruby
require File.dirname(__FILE__) + '/../config/boot'
require 'commands/runner'

Agregar el ejecutable específico de Ruby al comando hizo el truco:

$ crontab -l
0 4 * * * /usr/local/bin/ruby /data/myapp/current/script/runner -e production /data/myapp/current/script/myscript.rb >> /data/myapp/current/log/cron.log 2>&1

Answer 1

De forma predeterminada, cron envía su salida al usuario que la ejecutó. Podrías mirar allí.

Es muy útil redirigir la salida de los scripts ejecutados por cron para que pueda ver los resultados en un archivo de registro en lugar del correo local de algún usuario aleatorio en el servidor.

Aquí se explica cómo redireccionar stdout y stderr a un archivo de registro:

cd /home/deploy/your_app/current; script/runner -e production ./script/my_cron_job.rb >> /home/deploy/your_app/current/log/my_file.log 2>&1

El > > redirige stdout a un archivo, y 2 > & amp; 1 redirige stderr a stdout para que también se registre cualquier mensaje de error.

Una vez hecho esto, podrás examinar los mensajes de error para ver qué está sucediendo realmente.

Answer 2

El problema habitual cuando alguien descubre que su secuencia de comandos no se ejecutará en una tarea cron cuando se ejecutará desde la línea de comandos es que se basa en una parte del entorno que una sesión interactiva tiene pero cron no recibe. Algunos candidatos frecuentes son el " PATH " medio ambiente, y posiblemente " INICIO " ;.

Answer 3

En Linux, asegúrese de que todos los archivos de configuración (/ etc / crontab, /etc/crond.{daily,hourly,etc}/* y /etc/cron.d/*) solo se pueden escribir en la raíz del usuario y son no enlaces simbólicos, de lo contrario ni siquiera serán considerados.

Para permitir enlaces no root y / o enlaces simbólicos, especifique la opción -p para el demonio crond.