Por que os scripts crontab não estão funcionando?

Frequentemente, crontab os scripts não são executados dentro do cronograma ou conforme o esperado. Existem inúmeras razões para isso:

  1. Notação crontab errada
  2. problema de permissões
  3. 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.

Ambiente diferente

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.

PATH=/opt/someApp/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin15 1 * * * backupscript --incremental /home /root

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.

sudo systemctl start cron

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.

Em muitos ambientes, o cron executa comandos usando sh, enquanto muitas pessoas assumem que vai usar bash.

Sugestões para testar ou corrigir isso para um comando com falha:

  • Tente executar o comando em sh para ver se funciona:

    sh -c "mycommand"
  • Envolva o comando em uma subcamada bash para garantir que ele seja executado no bash:

    bash -c "mybashcommand"
  • Diga ao cron para executar todos os comandos no bash definindo o shell na parte superior do crontab:

    SHELL=/bin/bash
  • Se o comando for um script, verifique se o script contém um shebang:

    #!/bin/bash

Eu tive alguns problemas com os fusos horários. Cron estava funcionando com o novo fuso horário de instalação. A solução foi reiniciar o cron:

sudo service cron restart

Caminho absoluto deve ser usado para scripts:

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.

Isso e outros bons gotchas aqui:
http://www.pantz.org/software/cron/croninfo.html

Cron está chamando um script que não é executável.

Correndo chmod +x /path/to/script, o script se torna executável e isso deve resolver esse problema.

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

/etc/init.d/rsyslog restart

ou

service rsyslog restart 

Fonte: Ativar o registo crontab no Debian Linux

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

cat /var/log/syslog | grep cron -i

para visualizar mensagens relacionadas ao cron.

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.

Acho que a melhor maneira de depurar o cron é verificar o syslog e encontrar os problemas.

No meu caso - o e-mail estava indo para a minha pasta de SPAM, então… verifique isso antes de passar horas na depuração: D

Interrupções de eletricidade

Por favor, verifique este cron - Script doesn't run via crontab but works fine standalone - Ask Ubuntu