Onde os erros do cron são registrados?

Como outros já apontaram, cron enviará por e-mail a saída de qualquer programa executado (se houver alguma saída). Portanto, se você não obtiver nenhuma saída, existem basicamente três possibilidades:

1. crond não foi possível iniciar um Shell para executar o programa ou enviar email
2. crond teve problemas ao enviar a saída ou o correio foi perdido.
3. o programa não produziu nenhuma saída (incluindo mensagens de erro)

O caso 1. é muito improvável, mas algo deveria ter sido escrito nos logs do cron. Cron tem um recurso de syslog reservado, então você deve dar uma olhada em /etc/syslog.conf (ou o arquivo equivalente em sua distribuição) para ver para onde as mensagens do recurso cron são enviadas. Destinos populares incluem /var/log/cron, /var/log/messages e /var/log/syslog.

No caso 2., você deve inspecionar os logs do daemon do mailer: as mensagens do daemon Cron geralmente aparecem como [email protected]. Você pode usar um MAILTO=... linha no arquivo crontab para que o cron envie um email para um endereço específico, o que deve facilitar a recepção dos logs do daemon do mailer. Por exemplo:

[email protected]
00 15 * * *  echo "Just testing if crond sends email"

No caso 3., você pode testar se o programa foi realmente executado anexando outro comando cujo efeito você pode verificar facilmente: por exemplo,

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

para que você possa verificar se crond realmente executou algo, observando o horário de /tmp/a_command_has_run.

Você sempre pode enviar explicitamente a saída do trabalho para um arquivo de log:

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

Lembre-se de que isso substituirá o comportamento do correio mencionado anteriormente, porque o próprio crond não receberá nenhuma saída do trabalho. Se você deseja manter esse comportamento, consulte o tee (1).

Se você não estiver vendo os e-mails, poderá estar enviando spam para root @ yourcompany com os erros que podem ser bastante irritantes para as pessoas que usam essa conta para monitorar. Tente enviar a saída para o Syslog:

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

Em seguida, aguarde a execução do cronjob e procure o erro em/var/log/messages (ou /var/log/user.log em alguns sistemas).

Isso funciona muito bem para mensagens de erro com apenas 1-2 linhas, como "yourcronjob: command not found". Ele também utiliza sua infraestrutura de syslog existente (Logrotation, syslogging central, Splunk etc.) e também reduz o spam de e-mail para o root.

Pode não ser uma boa solução se o seu cronjob gerar centenas de linhas de saída.

Você deve receber e-mail de crond quando o trabalho falhar na execução ou quando retornar um código de saída diferente de zero. Tente digitar:

$ mailx

no prompt de comando.

mailx(1) é o programa básico de leitura de e-mail em quase todos os sistemas Unixlike. É muito primitivo para os padrões modernos, mas é possível contar com ele para estar sempre disponível. Outros agentes de correio melhores podem estar disponíveis, mas há um número suficiente deles para que você nunca saiba qual deles está instalado em alguma máquina aleatória que estiver usando.

Observe que, a menos que você tenha configurado seu sistema como um servidor de email na Internet, esse subsistema de email será usado apenas dentro da máquina. Você pode enviar e-mails para e receber de outros usuários na máquina, mas talvez não seja possível enviar e-mails para o mundo, e e-mails do mundo exterior certamente não poderão chegar à sua máquina.

A configuração padrão do cron enviará um email com a saída do seu programa. Se isso falhar, tente agrupar seu programa com falha em um script do Shell que garanta que o programa não falhe e você poderá registrar ainda mais a saída.

Essa é uma configuração configurável em algumas implementações do cron.

Cron registra informações básicas em /var/log/messages, mas envia qualquer saída do programa para o usuário que está chamando.

Eu me deparei com esse tópico há alguns anos, enfrentando os mesmos problemas e, recentemente, deparei com uma solução para os casos mencionados por Ricardo. A falta de um email é difícil de detectar (como você mencionou) e você certamente não deseja enviar spam para o email root @ yourcompany. Se estiver interessado, confira deadmanssnitch.com. . Essa ferramenta parece resolver os casos mencionados acima. Parece bastante simples de usar - basta adicionar o pouco de código que a ferramenta fornece ao seu cronjob. Se o seu trabalho falhar na execução em um interno especificado, você será alertado. Se o seu trabalho começar a ser executado novamente, você também será alertado.

Eu uso vixie-cron, então não sei se isso se aplica a tudo. Mas eu tenho um dead.letter arquivo que contém toda a saída do trabalho.

No meu /root/ pasta que tenho crons.cron que defini como meu crontab executando crontab /root/crons.cron. dead.letter será criado em /root/ também.

Editar Acabei de pesquisar no Google dead.letter, e é um e-mail não entregue. Aparentemente, não tem nada a ver com o cron. Se você não tiver o correio configurado corretamente (como eu), terá o arquivo.

Outro truque útil é ver quais scripts são realmente executados.

Isso é feito com run-parts -v --test /etc/cron.hourly/

> /etc/cron.hourly//logrotate

Se o seu script não aparecer, ele não será executado.

Este btw funciona apenas para os scripts instalados no /etc/cron.hourly diretório. Ele não mostra os itens configurados no seu crontab.

Para iniciantes, isso pode ser difícil de depurar. Certifique-se de não trocar os valores de minutos e horas. O minuto chega primeiro, depois a hora. Quando você fornece valores inferiores a 12 para cada um, ele os aceita, mas pode não funcionar como o esperado ou de maneira alguma.