Disabilitare le email cron a meno che non ci siano errori?

Come posso ricevere email da cron solo se ci sono errori?

Nella stragrande maggioranza dei casi, i compiti si svolgeranno perfettamente e non mi interessa davvero l'output.

È solo nel raro caso di un fallimento che voglio / ho bisogno di sapere.

Ho procmail disponibile - ma non sono sicuro che ciò che sto descrivendo sia possibile gestire esternamente a cron "correttamente".

Dato che non ti /dev/nulloccupi dell'output, puoi reindirizzare lo STDOUT di un lavoro e lasciare che lo STDERR venga inviato via mail (usando MAILTOla variabile d'ambiente).

Quindi, per esempio:

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

invierà posta quando viene emesso solo su STDERR (con STDERR) e scarterà STDOUT.

Questo ovviamente presuppone che quando un programma ha scritto su STDERR, non è riuscito; questo potrebbe non essere sempre il caso. Se hai il controllo del programma, puoi farlo. Per qualsiasi caso complesso, è necessario scrivere un wrapper di qualche tipo che esegua i comandi e inviare la posta di conseguenza. E metti la confezione come cronlavoro.

Il chroniccomando da moreutils esegue un comando in silenzio, a meno che non fallisca.

Citando dal suo manuale:

cronico esegue un comando e organizza la visualizzazione dell'errore standard e dell'errore standard solo se il comando fallisce (esce da zero o si arresta in modo anomalo). Se il comando ha esito positivo, qualsiasi output estraneo verrà nascosto.

Un uso comune per cronico è per l'esecuzione di un processo cron. Invece di cercare di mantenere silenzioso il comando e di dover gestire le e-mail contenenti output accidentale quando ha esito positivo e non un output sufficientemente dettagliato in caso di errore, è possibile eseguirlo sempre verbalmente e utilizzare cronico per nascondere l'output riuscito.

Come posso ricevere email da cron solo se ci sono errori?

È possibile racchiudere le invocazioni cron con cronic , uno script di shell che utilizza l'output cron a meno che il codice di ritorno del processo richiamato sia diverso da zero o non sia presente un output di errore senza traccia.

Per usare cronic, scarica lo script in una posizione adatta, ad esempio /usr/local/bin. Le voci crontab devono essere precedute dal percorso dello script (ad es. /usr/local/bin/cronic), O semplicemente cronic, purché PATHsia impostato correttamente.

Nota che "errori" è un termine mal definito nella tua domanda e richiede un'attenta definizione. Affinché cronic sia utile, è necessario assicurarsi che i lavori che vengono completati con errori di report cronic siano in uno dei modi in cui definisce una condizione di errore. Metodi impliciti di segnalazione, come la scrittura di stringhe di testo STDOUT, richiederanno ulteriori riflessioni per renderlo compatibile con cronic o un altro meccanismo di cron cron.

Sono disponibili altri wrapper, collegati dal sito cronico:

• zitto
• Cronwrap

Ecco un'altra variante che ho usato con successo per molti anni: catturare l'output e stamparlo solo per errore . Ciò non richiede file temporanei e conserva tutto l'output . La parte importante è quella 2>&1che reindirizza STDERR a STDOUT.

Invia l'intero output tramite la configurazione cron mailer predefinita:

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

Lo stesso ma con un indirizzo e un soggetto specifici:

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

Puoi anche eseguire più azioni in caso di errore e aggiungere all'email:

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

Funzionerà con comandi semplici. Se hai a che fare con pipe complesse ( find / -type f | grep -v bla | tar something-or-other), allora è meglio spostare il comando in uno script ed eseguirlo usando l'approccio sopra menzionato. Il motivo è che se qualsiasi parte del tubo viene inviata a STDERR, riceverai comunque e-mail.

Probabilmente non ci ho pensato fino in fondo, ma

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

, in casi ordinari, reindirizzerebbe tutto a un file temporaneo (probabilmente si vorrebbe usare mktempper ottenere un nome file univoco), eliminerebbe quello se il file ha avuto successo, e poi di catnuovo il contenuto, se esistono ancora (es. yourthing.sh è uscito con condizione di errore), che deve essere raccolto dal cron mailer.

Se la memoria serve, cron già non invia nulla se non c'è stato alcun output, quindi se il file di registro è vuoto o non esiste, non succede nulla. (Reindirizziamo il messaggio di errore.)