Frequentemente, crontab os scripts não são executados dentro do cronograma ou conforme o esperado. Existem inúmeras razões para isso:
Notação crontab errada
problema de permissões
variavel
Esta wiki da comunidade visa agregar as principais razões para crontab scripts não sendo executados conforme o esperado. Escreva cada motivo em uma resposta separada.
Inclua um motivo por resposta-detalhes sobre por que não foi executado - e corrija(es) por esse motivo.
Escreva apenas problemas específicos do cron, por exemplo, comandos que são executados conforme o esperado do shell, mas executados erroneamente pelo cron.
Cron passa um conjunto mínimo de variáveis de ambiente para seus trabalhos. Para ver a diferença, adicione um trabalho fictício como este:
>* * * * * env /tmp/env.saida
Esperar /tmp/env.output para ser criado, remova o trabalho novamente. Agora compare o conteúdo do /tmp/env.output com a saída de env execute em seu terminal regular.
Um "gotcha" comum aqui é o PATH variável de ambiente sendo diferente. Talvez seu script cron use o comando somecommand encontrado em /opt/someApp/bin, que você adicionou a PATH em /etc/environment? cron ignora PATH desse arquivo, então runnning somecommand a partir do seu script falhará quando executado com cron, mas funcionará quando executado em um terminal. Vale a pena notar que as variáveis de /etc/environment será passado para trabalhos cron, apenas não as variáveis cron se define especificamente, como PATH.
Para contornar isso, basta definir o seu próprio PATH variável na parte superior do script. Por exemplo.
#!/bin/bashPATH=/opt/someApp/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin# rest of script follows
Alguns preferem apenas usar caminhos absolutos para todos os comandos. Eu recomendo contra isso. Considere o que acontece se você deseja executar seu script em um sistema diferente e, nesse sistema, o comando está em /opt/someAppv2.2/bin Sim. Você teria que passar por todo o script substituindo /opt/someApp/bin com /opt/someAppv2.2/bin em vez de apenas fazer uma pequena edição na primeira linha do script.
Você também pode definir a variável PATH no arquivo crontab, que se aplicará a todos os trabalhos cron. Por exemplo.
Meu top gotcha: se você esquecer de adicionar uma nova linha no final do crontab arquivo. Em outras palavras, o arquivo crontab deve terminar com uma linha vazia.
Abaixo está a seção relevante nas páginas de manual para esta questão (man crontab em seguida, pule para o 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)
Cron daemon não está em execução. Eu realmente fiz asneira com isso há alguns meses.
Tipo:
pgrep cron
Se você não vir nenhum número( ou seja, o PID principal de cron), cron não está em execução. sudo /etc/init.d/cron start pode ser usado para iniciar cron.
EDIT: em vez de invocar scripts init por meio de /etc / init.D, use o serviceutility, por exemplo.
sudo service cron start
EDIT: também você pode usar systemctl no Linux Moderno, Por exemplo.
Os nomes dos arquivos do script em cron.d/, cron.daily/, cron.hourly/, etc., não deve conter ponto (.), caso contrário, as peças de execução Irão ignorá-las.
Ver peças de corrida (8):
If neither the --lsbsysinit option nor the --regex option is given then the names must consist entirely of upper and lower case letters, dig‐ its, underscores, and hyphens. If the --lsbsysinit option is given, then the names must not end in .dpkg-old or .dpkg-dist or .dpkg-new or .dpkg-tmp, and must belong to one or more of the following namespaces: the LANANA-assigned namespace (^[a-z0-9]+$); the LSB hierarchical and reserved namespaces (^_?([a-z0-9_.]+-)+[a-z0-9]+$); and the Debian cron script namespace (^[a-zA-Z0-9_-]+$).
Então, se você tiver um script cron backup.sh, analyze-logs.pl em cron.daily/ diretório, é melhor remover os nomes das extensões.
Por exemplo, /bin/grep deve ser usado em vez de grep:
# m h dom mon dow command0 0 * * * /bin/grep ERROR /home/adam/run.log &> /tmp/errors
Em vez de:
# m h dom mon dow command0 0 * * * grep ERROR /home/adam/run.log &> /tmp/errors
Isso é especialmente complicado, porque o mesmo comando funcionará quando executado a partir do shell. A razão é que cron não tem o mesmo PATH variável de ambiente como o usuário.
Se o seu comando crontab tiver um % símbolo nele, cron tenta interpretá-lo. Então, se você estivesse usando qualquer comando com um % nele (como uma especificação de formato para o comando date), você precisará escapar dele.
Também é possível que a senha do usuário tenha expirado. Mesmo a senha do root pode expirar. Você pode tail -f /var/log/cron.log e você verá cron falhar com a senha expirada. Você pode definir a senha para nunca expirar fazendo isso: passwd -x -1 <username>
Em alguns sistemas (Debian, Ubuntu) logging para cron não está habilitado por padrão. Em / etc / rsyslog.conf ou / etc / rsyslog.d / 50-Padrão.conf linha:
# cron.* /var/log/cron.log
deve ser editado (sudo nano /etc/rsyslog.conf) não autorizado a:
cron.* /var/log/cron.log
Depois disso, você precisa reiniciar o rsyslog via
Em alguns sistemas (Ubuntu), o arquivo de registro separado para cron não está habilitado por padrão, mas os logs relacionados ao cron estão aparecendo no arquivo syslog. Pode-se usar
Você deve fechar ‘crontab-e’ para que o cron tome efeito. Por exemplo, usando o vim, edito o arquivo e uso: W ' para gravá-lo, mas o trabalho não é adicionado ao cron até que eu saia também. Então eu não vou ver o trabalho até depois de eu :q` também.