¿Dónde se registran los errores cron?

Si configuro los crontrabajos incorrectamente, parecen fallar silenciosamente. ¿Dónde debo buscar un registro de errores para entender qué salió mal?

Como otros han señalado, cronle enviaremos por correo electrónico la salida de cualquier programa que ejecute (si hay alguna salida). Entonces, si no obtiene ningún resultado, existen básicamente tres posibilidades:

1. crond ni siquiera pudo iniciar un shell para ejecutar el programa o enviar correos electrónicos
2. crond tuvo problemas para enviar la salida o se perdió el correo.
3. el programa no produjo ningún resultado (incluidos los mensajes de error)

El caso 1. es muy poco probable, pero debería haberse escrito algo en los registros cron. Cron tiene una instalación reservada de syslog propia, por lo que debe consultar /etc/syslog.conf(o el archivo equivalente en su distribución) para ver dónde cronse envían los mensajes de la instalación . Los destinos populares incluyen /var/log/cron, /var/log/messagesy /var/log/syslog.

En el caso 2., debe inspeccionar los registros del demonio de correo: los mensajes del demonio Cron generalmente aparecen como de root@yourhost. Puede usar una MAILTO=...línea en el archivo crontab para que cron envíe un correo electrónico a una dirección específica, lo que debería facilitar la tarea de seleccionar los registros del demonio de correo. Por ejemplo:

MAILTO=my.offsite.email@example.org
00 15 * * *  echo "Just testing if crond sends email"

En el caso 3., puede probar si el programa realmente se ejecutó agregando otro comando cuyo efecto puede verificar fácilmente: por ejemplo,

00 15 * * * /a/command; touch /tmp/a_command_has_run

para que pueda verificar si crondrealmente ha ejecutado algo mirando el mtime de /tmp/a_command_has_run.

Siempre puede enviar explícitamente la salida del trabajo a un archivo de registro:

0 8 * * * /usr/local/bin/myjob > /var/log/myjob.log 2>&1

Tenga en cuenta que esto reemplazará el comportamiento del correo que se ha mencionado anteriormente, porque crond iself no recibirá ningún resultado del trabajo. Si desea mantener ese comportamiento, debe buscar en tee (1).

Si no está viendo los correos, puede estar enviando spam a root @ yourcompany con los errores que pueden ser bastante molestos para las personas que usan esa cuenta para el monitoreo. Intente enviar la salida a Syslog en su lugar:

*/5 * * * * yourcronjob 2>&1 | /usr/bin/logger -t yourtag

Luego, espere a que se ejecute el cronjob y busque el error en / var / log / messages (o /var/log/user.log en algunos sistemas).

Esto funciona muy bien para mensajes de error que tienen solo 1-2 líneas de largo, como "yourcronjob: comando no encontrado". También hace uso de su infraestructura syslog existente (Logrotation, syslogging central, Splunk, etc.) También reduce el correo no deseado a la raíz.

Puede que no sea una buena solución si su cronjob genera cientos de líneas de salida.

La configuración cron predeterminada le enviará un correo con la salida de su programa. Si esto falla, puede intentar envolver su programa defectuoso en un script de shell que garantice que el programa no falle, y podría seguir registrando la salida.

Esta es una configuración configurable en algunas implementaciones cron.

Debería recibir un correo electrónico crondcuando el trabajo no se ejecuta o cuando el trabajo devuelve un código de salida distinto de cero. Intenta escribir:

$ mailx

en el símbolo del sistema.

mailx(1)es el programa básico de lectura de correo en la mayoría de los sistemas Unixlike. Es muy primitivo para los estándares modernos, pero puedes contar con que siempre esté disponible. Otros mejores agentes de correo pueden estar disponibles, pero hay suficientes para que nunca sepas cuál está instalado en alguna máquina aleatoria que estás usando.

Tenga en cuenta que a menos que haya configurado su sistema como un servidor de correo electrónico de Internet, este subsistema de correo solo se usa dentro de la máquina. Puede enviar y recibir correos electrónicos de otros usuarios en la máquina, pero es posible que no pueda enviar correos electrónicos al mundo, y los correos electrónicos del mundo exterior ciertamente no podrán llegar a su máquina.

Cron registra información básica en /var/log/messages, pero envía cualquier salida de programa al usuario que invoca.

Me encontré con este hilo hace unos años, experimentando los mismos problemas y recientemente encontré una solución a los casos mencionados por Ricardo. La falta de un correo electrónico es difícil de detectar (como mencionó) y ciertamente no desea enviar spam a su correo electrónico raíz @ su empresa. Si está interesado, visite deadmanssnitch.com. . Esta herramienta parece resolver los casos antes mencionados. Parece bastante simple de usar, solo agregue el bit de código que la herramienta le brinda a su cronjob. Si su trabajo no se ejecuta en un interno específico, recibirá una alerta. Si su trabajo comienza a ejecutarse nuevamente, también recibirá una alerta.

Yo uso vixie-cron, así que no sé si esto se aplica a todo. Pero tengo un dead.letterarchivo que contiene toda la salida del trabajo.

En mi /root/carpeta tengo la crons.cronque configuré como mi crontab ejecutando crontab /root/crons.cron. dead.letterserá creado /root/también en

Editar Acabo de buscar en Google dead.letter, y es un correo que no se puede entregar. No tiene nada que ver con cron aparentemente. Si no tiene el correo configurado correctamente (como yo), tendrá el archivo.

Para los novatos, esto podría ser un dolor de depuración. Asegúrese de no intercambiar los valores de minutos y horas. Primero viene el minuto, luego la hora. Cuando proporciona valores inferiores a 12 para cada uno, los aceptará, pero es posible que no funcionen como se esperaba o no funcionen.