Eu tenho notado que jobs em /etc/cron.d/ não estão rodando, o curioso é que o valor X será executado, mas o resto não será.
Li comentários de pessoas sobre não usar um '.' nos nomes dos arquivos, nenhum dos meus arquivos tem pontos.
Eu também li que você deve sempre colocar uma linha em branco no final de cada arquivo, mas isso não parece fazer nenhuma diferença.
No final, tirei TODOS os comentários de todos os arquivos em /etc/cron.d/, o que fez com que todos os trabalhos fossem executados corretamente.
O Cron não estava colocando nenhuma mensagem de erro em / var / log / syslog ou / var / log / messages, não há / var / log / cron (d) .log
Alguém já encontrou algo assim antes? Em caso afirmativo, existe uma solução para comentar sem causar problemas?
Use # no início da linha para comentar.
Crontabs não devem ter uma linha em branco no final - talvez eles aceitem isso em lançamentos recentes (?) mas por um longo tempo está causando problemas.
Normalmente, um e-mail é enviado para o proprietário do crontab com a saída / problemas. Se o crontab pertence a root , você deve abrir sua caixa de correio.
Atualização rápida para os comentários acima
@Dennis - Todos eles funcionaram sem problemas.
@Richard - Todas as multas continham finais de linha Unix, se algum dos meus desenvolvedores usasse finais de linha do Windows, eles sentiriam meu banimento instantaneamente.
Não houve saída ou problemas porque os arquivos cron simplesmente não foram executados. Verificar caixas de correio foi uma das minhas primeiras ideias.
Adicionando um simples - echo "file run" > / root / cron-has-worked - para um job confirmado que não estava funcionando, também sentado e assistindo / var / log / syslog em um shell e top em outros jobs cron confirmados que não estão em execução.
Obrigado pelo comentário sobre o uso de #, mas sei como comentar os arquivos cron. = P
Tags cron