Pregunta:
Tengo un script de Python que quiero ejecutar a través de crontab. Mi crontab se ve así:
5,20,35,50 * * * * /var/www/django-apps/callreport/util.py
Ese script está configurado para analizar un montón de archivos planos y pegar la información en una base de datos MySQL, luego eliminar los archivos. Funciona bien desde la línea de comandos, los datos se copian en la base de datos y los archivos planos se eliminan. Pero no sucede nada cuando se configura para ejecutarse como un trabajo cron.
En el pasado, recibía un mensaje de correo cuando fallaba un trabajo cron, pero no recibo ningún comentario con este, y todavía me siento bien como administrador de sistemas en este cuadro. ¿Qué estoy haciendo mal?
Respuesta:
El problema habitual con los trabajos 'cron' es que tienen un entorno cero, a diferencia de los trabajos 'at' que copian su entorno. Cuando algo funciona desde la línea de comandos y no desde 'cron', mi experiencia es que el 'entorno' es uno de los problemas más comunes. Ocasionalmente, se encuentra con otro problema: los trabajos 'cron' no se ejecutan con una terminal y, ocasionalmente, los programas se ponen nerviosos con esto. Sin embargo, esto está en el rango del 1% en comparación con el 99% de los problemas ambientales.
La otra técnica clave que utilizo es ejecutar siempre un script de shell desde 'cron'; el script de shell asegura que el entorno esté configurado correctamente y luego ejecuta el programa real. Si un trabajo 'cron' me está dando problemas, puedo modificar el script para hacer cosas útiles como esta:
{
date
env | sort
set -x
...what was there before adding the debug...
} >/tmp/cron.jobname.$$ 2>&1
Esto redirige toda la salida (salida estándar y error estándar) a un nombre de archivo. Puede crear marcas de tiempo en el nombre del archivo si lo prefiere al ID del proceso. El análisis de los archivos de registro a menudo revela los problemas rápidamente.