Meu crontab só gosta de cinco asteriscos (relacionado ao fuso horário?)

Question

Eu tenho um problema com o crontab de um usuário.

O Crontab se recusa a executar qualquer trabalho, a menos que esteja programado para ser executado a cada minuto (* * * * *).

Assim que você editar a tarefa, por exemplo, no minuto 15 de cada hora, ela não será executada.

Isso funciona a cada minuto:

* * * * * touch /tmp/test01 

Isso não funciona no minuto 15 de cada hora. Apenas não será executado.

15 * * * * touch /tmp/test02

• O que está causando isso?
• Como isso pode ser resolvido?

OS é RedHat 4.

Eu sempre edito o cron com crontab -e e EDITOR está definido como vi. Eu mudei entre 15 * * * * (minuto pode mudar) e * * * * * e o resultado é o mesmo. Só gosta de cinco asteriscos.

ENORME EDIT:

Eu segui a pergunta do @ shane-h e testei por */2 * * * * (a cada minuto) e deu certo! Então eu descobri algo revelador:

Eu fiz um teste com essa string 37 * * * * touch /tmp/prueba_777777

Para minha surpresa, a coisa realmente correu, mas veja a data do arquivo:

-rw-r - r-- 1 orashut dba 0 8 de agosto 08:07 prueba_777777

Recentemente, o servidor foi configurado para o novo fuso horário da Venezuela, que é agora -04: 00, mas costumava ser -04: 30.

Quando você executa o comando date, mostra a data correta. Quando você cria um arquivo, a data do arquivo no FS está correta. Mas, de alguma forma, as tarefas do cron estão sendo executadas 30 minutos antes. É por isso que quando eu agendava um trabalho por alguns minutos no futuro, não funcionava, porque para o daemon do cron esse tempo já havia passado. Se eu esperasse quase uma hora, teria corrido exatamente em 30 minutos. É por isso que o arquivo tocado é 30 minutos mais cedo que o cronograma é 37.

Então a questão agora é:

É evidente que o daemon do cron está trabalhando com o antigo fuso horário enquanto o restante do servidor está trabalhando com o novo fuso horário.

Como posso corrigir o entendimento do daemon do cron sobre o novo fuso horário?

    

Answer 1

Não posso dar uma resposta específica, mas eis como gostaria de resolver isso:

1. Tente mais combinações para encontrar outra expressão ativa. Que tal: */2 * * * * (todos os outros minutos) ou * */2 * * * (todos os minutos, todas as outras horas). Seria interessante estabelecer que qualquer expressão relativa funciona enquanto expressões fixas não.

2. Quando você salva, vê a mensagem de confirmação "Novo crontab instalado?" (ou algo similar)

3. Você pode fazer um crontab -l para ver sua mensagem?

4. Este é um usuário crontab ou crontab do sistema?

5. Você vê mensagens no syslog? Se você adicionar um segundo, * * * * * cron você verá isso a cada minuto, e se você adicionar a variante every-other-minute, você pode ver no syslog apenas o trabalho mais frequente?

6. Você pode configurar um comando at em funcionamento?

7. Quando você descobrir isso, sugiro usar um serviço que eu criei, link para ficar de olho em seus trabalhos importantes. É gratuito para um desenvolvedor monitorar um trabalho e existem planos pagos para uso comercial. Eu havia me tornado muito depurador especialista no cron ao longo dos anos e sabia que, se precisasse de uma solução para monitorar meus trabalhos importantes, provavelmente outras pessoas também o faziam.

^{dos comentários:}

O Cron usa o mesmo fuso horário do sistema para os trabalhos de retrocesso, então eu tentaria apenas redefinir isso:

1. Defina seu fuso horário novamente, apenas para ser minucioso: na Red Hat use redhat-config-date

2. Reinicie o daemon do cron. Eu acho que na sua versão do sistema operacional: /etc/init.d/crond restart

Answer 2

So the question now is:

It's evident that the cron daemon is working with the old timezone while the rest of the server is working with the new timezone.

How can I fix the cron daemon's understanding of the new timezone?

Meu palpite é que o pacote de atualização de dados de fuso horário foi instalado ( tzdata RPM ou similar), mas o servidor não foi reinicializado e o daemon crond não foi reiniciado após a atualização, então crond ainda está usando os dados antigos do fuso horário que ele carregou quando foi originalmente iniciado.

Se esse é o problema, reiniciar o daemon deve corrigir o problema, como Shane H comentou: service crond restart ou /etc/init.d/crond restart deve fazê-lo. Você também deve considerar a reinicialização de quaisquer outros daemons de sistema de longa duração que possam registrar registros de data e hora, como sendmail .