O problema é que o Debian não permite '.' no nome do arquivo de um trabalho cron armazenado em /etc/cron.(d|daily|weekly|monthly) . Remova o '.' E o trabalho é executado corretamente.
Eu tenho uma caixa Debian GNU / Linux 4.0 (que não pode ser atualizada) rodando 24x7. Tem vários trabalhos em /etc/cron.daily, incluindo nossos scripts de backup. Percebi há algumas semanas que o script de backup não estava sendo executado com regularidade.
Esta manhã, executei o diretório cron manualmente ( nice run-parts --report /etc/cron.daily ), que é visto em /etc/anacrontab e /etc/crontab . Eu recebi um email para logwatch, mas não para nenhum dos outros trabalhos. Nossos scripts de backup, especificamente, têm uma grande quantidade de saída e levam algumas horas. Tentei reorganizar os trabalhos em /etc/cron.daily , sem efeito, e recentemente removi anacron , pois essa caixa "nunca" deve sofrer paralisação.
Executar qualquer um dos trabalhos individualmente parece funcionar bem. Acabei de adicionar o script de backup a /etc/crontab manualmente para ver se ele é executado corretamente.
Alguém tem outras sugestões?
Os logs do cron estão mostrando algum erro ou estão sendo executados nos horários especificados?
O que acontece se você observar os processos sendo executados nas horas em que eles deveriam estar em execução (isto é, se eles estão programados para serem executados às 4:00 da tarde, como é o sistema na lista de processos e registra-os aos 4:01 ?
Tola pergunta, mas você disse que recebe e-mails do logwatch, mas não de nenhum outro trabalho. Você verificou se os trabalhos estão realmente falhando, e não que há um problema de comunicação com os e-mails que notificam você sobre os trabalhos concluídos?
As tarefas estão sendo executadas como o contexto adequado do usuário, com permissões para fazer as coisas necessárias? Estas estão falhando apenas algumas vezes, mas outras não?
Você pode encontrar qualquer coisa que aconteça durante os momentos em que eles falham, mas não outras vezes (você disse que isso é um sistema sem tempo de espera ... está fazendo algo onde os scripts estão sobrepostos para que não possam ser concluídos? ou há processos que os bloqueariam?)
Existe alguma coisa configurada no sistema que elimine processos em um determinado nível de carga? Os timers do watchdog, etc., podem matar um processo se a carga for muito grande ou se a cota de processador / memória estiver muito alta, etc. ou se o sistema não responder. Outro motivo para ver se alguém pode ficar de olho nele por meio de uma sessão ssh em um ponto em que o servidor deve estar executando o trabalho.
Bart pregou sobre tudo que eu procuraria, exceto talvez o espaço em disco. Quando todos os trabalhos correm juntos, eles ficam sem espaço? Há algo mais acontecendo naquele momento que possa colocar uma grande carga temporária no espaço da unidade?
Outra coisa que você pode tentar, se puder, é executá-los em um horário diferente. De uma só vez, digamos 5:00, ou individualmente, 4:00 / 4:30 / 5:00 / 5:30 / etc ...
outra coisa poderia ser o meio ambiente. os scripts já foram executados com sucesso pelo cron? o ambiente cron pode ser diferente do seu ambiente de teste (PATH, ...). é possível adicionar log aos seus scripts de backup com logger ou echo?
Eu também tive o mesmo problema com '.' nos nomes dos scripts. Removendo qualquer '.' no nome do script resolveu o meu problema (até mesmo a extensão ".sh"!)
As opções --lsbsysinit ou --regex para executar partes permitem que você altere quais nomes de arquivos são considerados válidos.