O trabalho do Cron não funciona consistentemente

Question

Eu tenho um cron job:

1 0 * * * /usr/bin/wget -q -O /dev/null 'http://123.456.78.90/index/parsedata?&today=1'

Ele deve coletar um monte de dados do banco de dados às 12h01 de cada dia, organizá-lo para ser usado por nosso aplicativo em gráficos e exibições e, em seguida, pronto.

Às vezes, alguns gráficos parecem não ter sido processados, pois não mostram resultados por algum período de tempo. Executar manualmente o comando fará com que eles tenham os dados corretos.

Então, parece que o cron é parte do problema. Ou o cron não está disparando isso, não é verdade, pois vejo que a maioria das entradas exibe dados de gráficos esperados, ou talvez o cron não esteja terminando? Não sei onde procurar, pois achei que, como o acionamento manual da linha de script acima funciona, por que não funcionaria da mesma maneira quando eu configurava o cron para fazer isso? Alguma ideia?

Existe outro trabalho cron que é executado a cada 5 minutos no mesmo servidor, usando o mesmo código:

*/5 * * * * /usr/bin/wget -q -O /dev/null http://123.456.78.90/index/parsedata

É possível que a primeira execução demore demais e ainda esteja sendo processada quando esse script, executado a cada 5 minutos, entra em ação e isso está atrapalhando as coisas? O primeiro script pode levar mais de 5 minutos para ser executado, de modo que essa segunda instância possa ser executada enquanto o primeiro ainda está funcionando. Ambos usam a mesma ação, parsedata (), em nosso framework e escrevem no mesmo banco de dados. Talvez? Qualquer idéia apreciada.

    

Answer 1

As tarefas que falham no cron, mas funcionam em um terminal, geralmente são um sinal de que a tarefa está tentando produzir saída para stdout ou stderr e está caindo porque não pode.

Parece que você precisa de algum registro. Tente redirecionar stdout e stderr para um arquivo para ter uma ideia melhor do que está acontecendo:

/usr/bin/wget -q -O /dev/null http://123.456.78.90/index/parsedata >> /tmp/somelogfile.txt 2>&1

Se alguma saída for gerada, talvez ela lhe dê uma idéia da causa raiz do problema. Se o arquivo de log ainda estiver vazio após a falha de um trabalho, pelo menos você saberá procurar em outro lugar.

    

Answer 2

Se os dois processos estiverem entrando em uma situação de deadlock no banco de dados, isso pode ser a causa da falha no job mais longo (que é escolhido como a tarefa que é eliminada para resolver o deadlock). Se for esse o caso, ou se algum outro erro estiver causando a falha do processo, você poderá descobrir que o script parsedata está retornando uma mensagem de erro útil (ou outra pista), mas nunca está vendo isso porque está descartando sua saída com %código%. Sugiro que você registre a saída em vez de enviá-la para -O /dev/null , por exemplo:

-O /var/log/dailyparsedata/'date +%Y%m%d_%H%M'

(nota: são back-ticks, não aspas simples) criarão um novo arquivo a cada dia em /dev/null . Você pode definir outra tarefa do cron (ou configurar o logwatch) para remover arquivos após uma determinada idade, para não preencher a partição com esses arquivos ao longo do tempo.

Além disso, pode haver condições de erro que parem /var/log/dailyparsedata/ mesmo vendo a saída do script (talvez, por algum motivo, não seja possível ver o servidor da Web por algum motivo ocasionalmente: bem possível se o servidor que está chamando for remoto), caso em que não haverá nada para a saída para o arquivo especificado por wget , assim como o logout do script outout log wget's stdout e stderr como sugerido pela resposta de Stephen. Como as linhas do seu cron atualmente estão em execução, a maioria das implementações do cron enviarão parte dessa saída para alguém como um e-mail, adicionando -O para manter essa informação em um arquivo. Eu evitaria enviar este tipo de saída para >> /var/log/dailyparsedata/wget.output 2>&1 , pois há dois riscos: preencher / tmp com logs para que seu uso principal seja interrompido e ser desativado por padrão quando o servidor for reinicializado, o que significa que você perderá os logs que mais tarde desejar verifique.