trabalho cron ocasionalmente não em execução

Eu tenho um CentOS 6.6servidor 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 outros trabalhos agendados para execução exatamente ao mesmo tempo são executados sem problemas.

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

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

Eu li em alguns outros lugares pessoas falando sobre adicionar uma linha vazia no final do crontabarquivo. O trabalho que ocasionalmente falha na execução está realmente na última linha do meu crontabarquivo. Não foi possível encontrar nenhuma confirmação de que este é um bug real ou conhecido.

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

Isso é tudo que tenho na minha /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 OTHERJOBsempre executar enquanto Apr 1 pg_backup.shestava ligado nem foi executado.

Eu já tentei reiniciar, crondmas isso continua acontecendo. Isso está afetando vários servidores com a mesma versão do SO, kernel e cronRPMs.

Existe uma versão mais recente de cronie( 1.4.12), no entanto, a atualização não é uma opção, pois já estamos usando a versão mais recente disponível paraCentos 6.6

Examinei o changelog de todas as cronieversões após o meu ( 1.4.4) e não pareci nenhuma correção para esse problema específico. Também verificou todas as mensagens de confirmação .

— Luis
fonte

Boa solução de problemas. Por que não tentar adicionar uma última linha noop ( echo >/dev/nullpor exemplo)?

— Belmin Fernandez 02/04

Existe algum dos seus comandos com erro? possivelmente poderia parar o script. Eu tive uma experiência semelhante com scripts init.d.

— hardik

Com que rapidez cada um dos trabalhos é concluído? Se o trabalho iniciado a cada minuto for executado por dois minutos a cada vez, isso poderá ser um problema. Mas se for concluído em dois segundos, provavelmente não será um problema.

— Kasperd #

O trabalho que é executado a cada minuto (OTHERJOB) é concluído em alguns segundos. Mas esse não é o problema. Eu apenas adicionei OTHERJOB nos logs acima para mostrar que o crond estava em execução e o OTHERJOB foi processado corretamente enquanto o pg_backup.sh simplesmente não foi executado.

— Luis

Verifique /var/log/audit/audit.log.

— Michael Hampton

Respostas:

O cron original exigia que cada entrada terminasse com uma nova linha; portanto, às vezes você precisa de uma linha em branco ou de algo 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óstico na parte inferior, que indica 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.

— Brian
fonte

Esta é a primeira resposta que vem com o texto de pesquisa, cron error getpwname failedentão pensei em publicar a causa do meu problema:

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

ou seja,

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

Ao invés de

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

Deu o mesmo erro, vai entender.

— Aaron R.
fonte

usamos sssdpara autenticação remota. crondprecisa verificar os usuários disponíveis antes da execução dos trabalhos e isso é feito a cada 60 segundos. sssdo padrão client_idle_timeouté 60 segundos. então tivemos uma condição de corrida entre sssdecrond

Chegamos apenas ao fundo desse problema porque, na versão 1.4.4-14crond, começamos a ser um pouco mais detalhados sobre alguns erros.

* Thu Feb  5 12:00:00 2015 Tomáš Mráz <tmraz@redhat.com> - 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 era executado:

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

que nos levou a isso: https://bugzilla.redhat.com/show_bug.cgi?id=1209600#c2

e finalmente: https://access.redhat.com/solutions/1125133

Problema: sssd_befinalizado com SIGKILL devido ao retorno do EPIPE de getpwnam () (ou seja, tubo quebrado) pode fazer com que o crond ignore silenciosamente as entradas da tarefa cron.

A solução sugerida no link acima foi adicionar a linha abaixo a /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 os trabalhos.

— Luis
fonte