¿Deshabilitar correos electrónicos cron a menos que haya errores?

¿Cómo puedo recibir correos electrónicos de cron solo si hay errores?

En la inmensa mayoría de los casos, las tareas funcionarán bien, y realmente no me importa el resultado.

Es solo en el raro caso de una falla que quiero / necesito saber.

Tengo procmail disponible, pero no estoy seguro de si lo que estoy describiendo es posible administrarlo externamente para cron "correctamente".

Como no le interesa la salida, puede redirigir el STDOUT de un trabajo /dev/nully dejar que el STDERR se envíe por correo (utilizando MAILTOla variable de entorno).

Así por ejemplo:

...
...
MAILTO=foobar@example.com
...
...
* * * * * /my/script.sh >/dev/null

enviará correo cuando haya salida solo en STDERR (con el STDERR), y descartará el STDOUT.

Por supuesto, esto supone que cuando un programa ha escrito en STDERR, ha fallado; Esto podría no ser siempre el caso. Si tiene control sobre el programa, puede hacerlo. Para cualquier caso complejo, debe escribir un contenedor de algún tipo que ejecute los comandos y enviar el correo en consecuencia. Y pon el envoltorio como el crontrabajo.

El chroniccomando de moreutils ejecuta un comando en silencio a menos que falle.

Citando de su manual:

chronic ejecuta un comando y organiza su salida estándar y su error estándar para que solo se muestren si el comando falla (sale de cero o se bloquea). Si el comando tiene éxito, cualquier salida extraña se ocultará.

Un uso común para crónico es ejecutar un trabajo cron. En lugar de tratar de mantener el comando en silencio, y tener que lidiar con correos que contienen resultados accidentales cuando tiene éxito, y no detallar lo suficiente cuando falla, puede ejecutarlo de manera vergonzosa siempre y usar crónico para ocultar el resultado exitoso.

¿Cómo puedo recibir correos electrónicos de cron solo si hay errores?

Puede envolver sus invocaciones cron con cronic , un script de shell que come la salida cron a menos que el código de retorno del proceso invocado no sea cero o no haya una salida de error de rastreo.

Para usar cronic, descargue el script en una ubicación adecuada, como /usr/local/bin. Sus entradas de crontab deben tener el prefijo de la ruta al script (por ejemplo /usr/local/bin/cronic), o simplemente cronic, siempre que su PATHesté configurado correctamente.

Tenga en cuenta que "errores" es un término mal definido en su pregunta y requiere una definición cuidadosa. Para que cronic sea útil, debe asegurarse de que los trabajos que envuelve con errores de informe crónico de una de las formas en que define una condición de error. Los métodos implícitos de generación de informes, como escribir cadenas de texto STDOUT, requerirán más reflexión para que sea compatible con cronic u otro mecanismo de informes cron.

Hay otros contenedores disponibles, como los vinculados desde el sitio crónico:

• Silenciar
• Cronwrap

Aquí hay otra variación que he utilizado con éxito durante muchos años: capturar la salida e imprimirla solo por error . Esto no requiere archivos temporales y conserva toda la salida . La parte importante es la 2>&1que redirige STDERR a STDOUT.

Envíe la salida completa a través de la configuración predeterminada de cron mailer:

1 2 * * * root OUTPUT=`flexbackup -set all 2>&1` || echo "$OUTPUT"

Lo mismo pero con una dirección y tema específicos:

1 2 * * * root OUTPUT=`flexbackup -set all 2>&1` || echo "$OUTPUT" | mail -s "Failed to backup" an@email.address

Incluso puede realizar múltiples acciones en caso de error y agregar al correo electrónico:

1 2 * * * root OUTPUT=`flexbackup -set all 2>&1` || {echo "$OUTPUT" ; ls -ltr /backup/dir ; }

Esto funcionará para comandos simples. Si se trata de tuberías complejas ( find / -type f | grep -v bla | tar something-or-other), es mejor que mueva el comando a un script y ejecute el script utilizando el enfoque mencionado anteriormente. La razón es que si alguna parte de la tubería sale a STDERR, aún recibirá correos electrónicos.

Probablemente no lo he pensado hasta el final, pero

* * * * * yourthing.sh >/tmp/yourthing.log && rm -f /tmp/yourthing.log; cat /tmp/yourthing.log 2>/dev/null

En casos normales, redirigiría todo a un archivo temporal (probablemente querría usar mktemppara obtener un nombre de archivo único), lo eliminaría si el archivo fue exitoso y luego catlos contenidos nuevamente, si aún existen (es decir, yourthing.sh salió con condición de error), para ser recogido por el programa publicitario cron.

Si la memoria funciona, cron ya no envía nada si no hubo salida, por lo que si el archivo de registro está vacío o no existe, no sucede nada. (Redirigimos el mensaje de error).