Desactivando alertas de correo en cron
Las tareas programadas en cron por defecto reportan un correo electrónico con la salida del comando a la cuenta local del propietario de la tarea. Si por alguna razón no queremos que ese correo se envíe tenemos varias alternativas que podemos encadenar para garantizarlo.
Por un lado podemos intentar eliminar la salida de errores en las tareas que hemos programado, bien en la propia tarea o bien haciendo uso de /dev/null/. Y por otro lado está el uso de la variable MAILTO en el cron del usuario, vamos a describir un poco más cada una de estas opciones. [@MORE@]
Eliminar la salida de errores
Para eliminar la salida -output- de errores en tareas programadas es tan sencillo como enviarla a /dev/null con lo que el cron quedaría de la siguiente forma:*/5 * * * * tarea_programada.sh >/dev/null 2>&1 */7 * * * * tarea_programada2.sh &> /dev/nullComo vemos hay dos opciones distintas, cualquiera de las dos son válidas, agregando esta pequeña coletilla a cada tarea nos aseguramos que no habrá ningún tipo de informe que enviar.
Variable MAILTO
Como decía al principio, por defecto todos los correos se enviarán a la cuenta local del usuario que ejecuta el cron (root@localhost, usuario@localhost...), para evitar este comportamiento tan solo hemos de editar el cron (crontab -e) y agregar la variable MAILTO vacía al principio del mismo:# crontab -e MAILTO=\"\" */5 * * * * tarea_programada.sh >/dev/null 2>&1 */7 * * * * tarea_programada2.sh &> /dev/nullNo tiene mucha más ciencia, con estas dos prácticas evitaremos ese tan molesto correo en las tareas programadas.
Referencias
- David Martinez Mira tu que bien me viene :DSuelo largar todo a /dev/null pero mejor así :D
- coder Este coñazo de recibir los crons en realidad es un debate eterno. ¿Qué es mejor? ¿Recibir el mail de cron para saber que se han ejecutado las tareas o programarse en las propias tareas un mailer para cuando la ocasión lo requiera? Yo lo que suelo hacer es optar por la segunda pero dejando log de cada ejecución en algún directorio del server o enviando SYSLOGS a un equipo remoto. La movida de dejar el MAILTO vacío es que no sabes si se ha ejecutado la tarea o no. O sea, no ya si se ha ejecutado mal, sino si se ha ejecutado siquiera.
- r0sk @coder: Interesante cuestión, supongo que será un interrogante a aplicar en cada caso concreto, pero me parece bastante buena solución programar un mailer cuando la ocasión lo requiera.