Desativa os e-mails do cron, a menos que haja erros?

Question

Como posso receber apenas emails do cron se houver erros?

Na esmagadora maioria dos casos, as tarefas serão executadas bem - e eu realmente não me importo com a saída.

É apenas no caso raro de uma falha que eu quero / preciso saber.

Eu tenho procmail disponível - mas não tenho certeza se o que estou descrevendo é possível gerenciar externamente para cron "corretamente".

    

Answer 1

Como você não está se importando com a saída, é possível redirecionar o STDOUT de um trabalho para /dev/null e deixar que o STDERR seja enviado via correio (usando a variável de ambiente MAILTO ).

Então, por exemplo:

...
...
[email protected]
...
...
* * * * * /my/script.sh >/dev/null

enviará mensagens quando houver saída somente no STDERR (com o STDERR) e descartará o STDOUT.

Isto, obviamente, pressupõe que quando um programa escreveu em STDERR, falhou; isso pode não ser sempre o caso. Se você tiver controle sobre o programa, poderá fazê-lo. Para qualquer caso complexo, você deve escrever um wrapper de algum tipo que execute o (s) comando (s) e envie correspondências de acordo. E coloque o wrapper como o trabalho cron .

    

Answer 2

O comando chronic de moreutils executa um comando silenciosamente, a menos que ele falhe.

Citando seu manual:

chronic runs a command, and arranges for its standard out and standard error to only be displayed if the command fails (exits nonzero or crashes). If the command succeeds, any extraneous output will be hidden.

A common use for chronic is for running a cron job. Rather than trying to keep the command quiet, and having to deal with mails containing accidental output when it succeeds, and not verbose enough output when it fails, you can just run it verbosely always, and use chronic to hide the successful output.

    

Answer 3

How can I only receive emails from cron if there are errors?

Você poderia envolver suas invocações de cron com cronic , um script de shell que come saída cron, a menos que o código de retorno do processo invocado seja não -zero ou há saída de erro não-rastreio.

Para usar o cronic, faça o download do script em um local adequado, como /usr/local/bin . Suas entradas de crontab precisam ser prefixadas com o caminho para o script (por exemplo, /usr/local/bin/cronic ) ou simplesmente cronic , desde que seu PATH esteja definido corretamente.

Observe que "erros" é um termo mal definido em sua pergunta e exige uma definição cuidadosa. Para que o cronic seja útil, você deve garantir as tarefas que você encerra com erros de relatórios crônicos em uma das maneiras de definir uma condição de erro. Os métodos implícitos de geração de relatórios, como escrever strings de texto para STDOUT , exigirão mais reflexão para torná-lo compatível com o cronic ou outro mecanismo de relatório cron.

Outros wrappers estão disponíveis, como vinculados do site cronic:

• Shush
• Cronwrap

Answer 4

Aqui está outra variação que eu tenho utilizado com sucesso por muitos anos - capturar a saída e imprimi-la somente no erro . Isso não requer arquivos temporários e preserva toda a saída . A parte importante é o 2>&1 que redireciona STDERR para STDOUT.

Envie a saída inteira por meio da configuração padrão do programa de mensagens do cron:

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

O mesmo, mas com um endereço e um assunto específicos:

1 2 * * * root OUTPUT='flexbackup -set all 2>&1' || echo "$OUTPUT" | mail -s "Failed to backup" [email protected]

Você pode até executar várias ações com erro e adicionar ao e-mail:

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

Isso funcionará para comandos simples. Se você estiver lidando com pipes complexos ( find / -type f | grep -v bla | tar something-or-other ), é melhor mover o comando para um script e executar o script usando a abordagem mencionada anteriormente. A razão é que, se qualquer parte do pipe sair para o STDERR, você ainda receberá e-mails.

    

Answer 5

Eu provavelmente não pensei nisso até o final, mas

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

em casos comuns, redirecionaria tudo para um arquivo temporário (provavelmente você usaria mktemp para obter um nome de arquivo exclusivo), excluiria se o arquivo tivesse êxito e, em seguida, cat o conteúdo novamente, se eles ainda existem (ou seja, yourthing.sh foi encerrado com uma condição de erro), para serem escolhidos pelo mailer do cron.

Se a memória funcionar, o cron já não enviará nada se não houver saída, portanto, se o arquivo de log estiver vazio ou não existir, nada acontece. (Nós redirecionamos a mensagem de erro.)