trabalho cron ocasionalmente não está em execução

Question

Eu tenho um servidor CentOS 6.6 com os seguintes pacotes instalados:

crontabs-1.10-33.el6.noarch
cronie-1.4.4-12.el6.x86_64
cronie-anacron-1.4.4-12.el6.x86_64
kernel-2.6.32-504.3.3.el6.x86_64

Às vezes, uma das tarefas de backup agendadas para execução diária simplesmente não é executada. O script nem é chamado de acordo com /var/log/cron.log. É interessante mencionar que outras tarefas agendadas para execução exatamente ao mesmo tempo são executadas sem nenhum problema.

Não consigo reproduzir o problema e não localizei nenhum padrão nele. Se eu não fizer nada, o trabalho será executado corretamente no dia seguinte, conforme o esperado.

crond simplesmente ignora apenas um dos vários trabalhos que devem ser executados em um determinado momento. Isso só acontece esporadicamente.

Eu li em alguns outros lugares pessoas falando sobre como adicionar uma linha vazia no final do arquivo crontab. O trabalho que ocasionalmente não funciona é, na verdade, na última linha do meu arquivo crontab. Não consegui encontrar nenhuma confirmação de que este seja um bug real ou conhecido.

# tail -2 /var/spool/cron/postgres
*  * * * * OTHERJOB
0 21 * * * /pg_backup.sh

Isso é tudo o que tenho em meu /var/log/cron.log

Mar 31 21:00:02 SERVERNAME [cron.info] CROND[19394]: (root) CMD (OTHERJOB)
Mar 31 21:00:02 SERVERNAME [cron.info] CROND[19418]: (postgres) CMD (/pg_backup.sh)
Mar 31 21:01:02 SERVERNAME [cron.info] CROND[20062]: (root) CMD (OTHERJOB)

Apr  1 21:00:02 SERVERNAME [cron.info] CROND[31349]: (root) CMD (OTHERJOB)
Apr  1 21:01:01 SERVERNAME [cron.info] CROND[32080]: (root) CMD (OTHERJOB)

Veja como OTHERJOB sempre é executado enquanto em Apr 1 pg_backup.sh nem sequer foi executado.

Eu já tentei reiniciar o crond, mas isso continua acontecendo. Isso está afetando vários servidores com a mesma versão do sistema operacional, kernel e RPMs cron.

Existe uma versão mais recente do cronie (1.4.12), no entanto, atualizá-lo não é uma opção, já que já estamos usando a última versão disponível do Centos 6.6

Eu passei pelo changelog para todas as versões do cronie depois do meu (1.4.4) e não pareço nenhuma correção para esse problema específico. Também verifiquei todas as mensagens de commit .

    

Answer 1

usamos sssd para autenticação remota. crond precisa verificar os usuários disponíveis antes de executar os trabalhos e faz isso a cada 60 segundos. sssd padrão client_idle_timeout é 60 segundos. então tivemos uma condição de corrida entre sssd e crond

Nós só chegamos ao fim deste problema porque na versão 1.4.4-14 crond começou a ser um pouco mais detalhado sobre alguns erros.

* Thu Feb  5 12:00:00 2015 Tomáš Mráz <[email protected]> - 1.4.4-14
- add log message when getpwnam fails

Após a atualização para essa versão, começamos a ver o erro abaixo ao mesmo tempo em que um trabalho não seria executado:

[cron.err] crond[8654]: (user) ERROR (getpwnam() failed): Broken pipe

que nos trouxe a isso: link

e finalmente para isso: link

Issue: sssd_be terminated with SIGKILL due to getpwnam() returning EPIPE (ie. broken pipe) can cause crond to silently skip cron job entries.

A sugestão de solução no link acima foi adicionada à linha abaixo para /etc/sssd/sssd.conf :

client_idle_timeout = 75

A alteração acima corrigiu o problema para nós e o cron não pula mais trabalhos.

    

Answer 2

O cron original exigia que cada entrada terminasse com uma nova linha, então sim, às vezes você precisa de uma linha em branco ou algo assim no final.

   Although cron requires that each entry in a crontab end  in  a  newline
   character,  neither the crontab command nor the cron daemon will detect
   this error. Instead, the crontab will appear to load normally. However,
   the  command  will  never  run.  The best choice is to ensure that your
   crontab has a blank line at the end.

   4th Berkeley Distribution      29 December 1993               CRONTAB(1)

Algumas versões corrigem ou emitem um aviso, por exemplo, o Ubuntu Maverik (10.10): crontab veja a seção de diagnósticos na parte inferior, que afirma que um aviso será gravado no syslog.

DIAGNOSTICS
       cron requires that each entry in a crontab end in a newline  character.
       If  the last entry in a crontab is missing a newline (ie, terminated by
       EOF), cron will consider the crontab (at  least  partially)  broken.  A
       warning will be written to syslog. 

    

Answer 3

Esta é a primeira resposta que surge com o texto de pesquisa cron error getpwname failed , por isso pensei em publicar a causa do meu problema:

Eu estava usando o / etc / crontab, mas esqueci de colocar o usuário na frente do comando.

ou seja,

*/5   *  *  *  * /bin/bash <filename>

Em vez de

 */5   *  *  *  * root /bin/bash <filename>

Ele deu o mesmo erro, vai descobrir.