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

Question

Geralmente, os scripts crontab não são executados no horário ou conforme o esperado. Existem inúmeras razões para isso:

1. notação incorreta de crontab
2. problema de permissões
3. variáveis de ambiente

Este wiki da comunidade tem como objetivo agregar as principais razões pelas quais crontab scripts não estão sendo executados como esperado. Escreva cada motivo em uma resposta separada.

Inclua um motivo por resposta - detalhes sobre o motivo pelo qual ele não foi executado - e corrija (s) por esse motivo.

Por favor, escreva apenas questões específicas do cron. comandos que executam como esperado a partir do shell mas executam erroneamente pelo cron.

    

Answer 1

Eu tive um problema com um script que chamou o grep com uma expressão regular. Alguns regex funcionaram quando o script foi chamado de crontab, enquanto outros não, por exemplo. [[: print:]] não funcionou. Acontece que a variável de ambiente LANG tem um impacto nos conjuntos de caracteres como [a-z] ou [[: print:]]. Quando colei minha variável de ambiente LANG na parte superior do meu crontab, ou seja, "LANG = en_GB.UTF-8", todas as expressões regulares do grep funcionaram bem quando o script foi chamado de crontab. HTH.

    

Answer 2

Se crontab menciona algo como run-parts /etc/cron.daily , então run-parts pode estar se recusando a executar seu script . No meu caso, o script em cron.daily não começou com #! / Bin / sh .

Descobri isso colocando meu script em um diretório sozinho e executando run-parts nesse diretório.

    

Answer 3

Isso aconteceu comigo recentemente: eu tinha duas linhas que modificaram PATH , assim:

PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/home/ernesto/bin

Então, mais tarde no arquivo:

PATH=$PATH:/some/other/path

como normalmente faria em um contexto interpretado por shell. No entanto, $ PATH parece não ter sido expandido, fazendo com que todos os meus trabalhos falhem. A solução é colocar tudo em uma única linha.

Editar:

Como eu não queria esperar até a próxima iteração normal do anacron para verificar se meus trabalhos funcionavam corretamente, eu corri:

anacron -fnd "jobname"

Onde "jobname" é o identificador de trabalho especificado no anacrontab. Isso força as tarefas a serem executadas pelo mesmo processo de anacron, sequencialmente e sem demora.

    

Answer 4

Outra pegadinha:

Quando você digita crontab -e e salva dentro do editor, não terá nenhum efeito. Você precisa sair do editor para adicionar ou atualizar de acordo com suas alterações (por exemplo, use :x no Vim).

( crontab -e efetivamente executa "editar arquivo cron; atualizar a partir do arquivo cron", então ele está bloqueando o editor até você fechá-lo.)

    

Answer 5

=== Alerta do Docker ===

Se você estiver usando o docker,

Acho correto acrescentar que não consegui fazer com que o cron seja executado em segundo plano.

Para executar um cron job no contêiner, usei o supervisor e executei cron -f junto com o outro processo.

Edit: Outro problema - eu também não consegui fazê-lo funcionar ao executar o contêiner com a rede HOST. Veja esta questão aqui também: link

    

Answer 6

Permissões de registro

Um crontab muito simples, não será executado porque /var/log/ não é gravável por luser conta!

* * * * * /usr/local/bin/teamviewer_check >> /var/log/teamviewer.log 2>&1

SOLUÇÃO: crie o arquivo como root e chmod to 777

Graças à sugestão anterior de habilitar o log do cron em /etc/rsyslog.d/50-default.conf , leva à entrada do syslog (No MTA installed, discarding output) , então graças a " (CRON) info (Nenhum MTA instalado, descartando a saída) "erro no syslog instalando o postfix no modo local, tail / var / mail / luser, /bin/sh: 1: cannot create /var/log/teamviewer.log: Permission denied

    

Answer 7

Os trabalhos do Cron não serão executados se a senha do usuário expirar.

Uma indicação disso é se o seu log cron (geralmente /var/log/syslog no Ubuntu, acredito) contiver mensagens como "O token de autenticação não é mais válido; é necessário um novo".

Você pode verificar esse problema executando sudo chage -l the_username .

Veja um exemplo de uma senha expirada:

$ sudo chage -l root
Last password change                    : password must be changed
Password expires                    : password must be changed
Password inactive                   : password must be changed
Account expires                     : never
Minimum number of days between password change      : 0
Maximum number of days between password change      : 14600
Number of days of warning before password expires   : 14

A correção é mudar a senha. Por exemplo:

sudo -u root passwd

Em seguida, siga as instruções, especificando uma nova senha conforme solicitado.

Graças ao link por me apontar na direção certa aqui. No meu caso, assim como para aquele comentador, era o usuário root de uma caixa DigitalOcean.

    

Answer 8

Depois de horas descobri o problema em que, eu estava editando o script de shell de Windows ( notepad ++ ), onde o arquivo estava originalmente localizado em um servidor Linux e perdi o novo caractere de linha.

Como eu estava usando o Notepad ++ para editar o arquivo, tive que fazer o EOL Conversion para Unix para obter o novo caractere de linha, e funcionou perfeitamente.

Espero que ajude!

    

Answer 9

Outra ressalva:

Tente não colocar seus scripts cron no diretório pessoal de um usuário.

Acabei de ter um problema em que tudo parecia bom, mas só depois de um tempo - provavelmente algumas horas após o logout, as tarefas do cron para de funcionar e essas mensagens aparecem no log:

Signature not found in user keyring
Perhaps try the interactive 'ecryptfs-mount-private'

Meu diretório pessoal, pelo menos até onde eu sei, não é criptografado. Mas ainda assim, mover esses scripts para fora do diretório home resolveu o problema.

    

Answer 10

Meu crontab só funcionava quando eu estava logado como usuário.

Eu encontrei a solução sugerida aqui no Unix & amp; Linux SE

Qual foi o problema é que os scripts estavam no meu diretório inicial que foi criptografado. Por isso, será desmontado e indisponível quando eu estava logado. Você pode usar o comando mount para ver se o seu diretório pessoal está montado para criptografia.

Corrigi o problema colocando meus scripts na pasta /usr/local/bin .

    

Answer 11

Os arquivos .bashrc padrão no UBuntu 16.04 (e muitas outras versões) possuem um mecanismo embutido para não fazer nada se não estiverem um shell interativo.

Isso pode impedir que o arquivo seja originado corretamente dentro de um script que é executado pelo cron! Para evitar isso, comente as seguintes linhas da parte superior do seu arquivo .bashrc:

Ubuntu 16.04

# If not running interactively, don't do anything
case $- in
    *i*) ;;
      *) return;;
esac

Ubuntu 12.04 e algumas outras versões

# If not running interactively, don't do anything
[ -z "$PS1" ] && return

Contanto que estes sejam deixados no cron, se você executar um script que crie o seu arquivo .bashrc, você não terá nenhuma das variáveis de ambiente que você está acostumado dentro do seu terminal!

    

Answer 12

Eu já trabalhei em um servidor compartilhado com muitas restrições .

Todas as respostas aqui (PATH, SHELL, bash -c, ...) não conseguiram que meu script funcionasse no crontab.

Funcionou perfeitamente quando coloquei o comando em um pequeno arquivo de script com o PATH, o SHELL e o shebang, e não no próprio crontab. Eu tive que mudar as permissões para 700.

    

Answer 13

Se estiver executando scripts nos diretórios /etc/cron.* , verifique se seus scripts:

• são executáveis,
• corresponde ao namespace do script do cron Ubuntu / Debian (^[a-zA-Z0-9_-]+$) .

Por exemplo, se você tiver um script com extensão (como .sh ) não funcionará.

Para imprimir os nomes dos scripts que seriam executados de hora em hora, tente:

sudo run-parts --report --test /etc/cron.hourly

    

Answer 14

Eu tive alguns problemas com o uso de sudo em um cron.

Basicamente, eu queria executar um comando como um usuário específico e testei primeiro, na linha de comando, su , que retornou o erro This account is not available . Usando sudo , o comando foi executado sem erros.

No entanto, ao executar a partir do cron, o comando sudo retornou o seguinte erro: sudo: sorry, you must have a tty to run sudo .

Mais tarde, descobri que usar runuser e especificar um shell para executar o comando funciona.

    

Answer 15

Às vezes, o cron está funcionando bem, mas o script ou comando que você quer executar só falha silenciosamente, fazendo com que você descubra a árvore errada.

Nesses casos, acho útil envolver o destino em outro script curto, que gera algum código de depuração visível (incluindo a saída de date ) e usa o redirecionamento para garantir que eu receba alguma evidência para inspecionar. Se o alvo for um script, envolver em torno de um sh -x pode ajudar ainda mais.

A entrada do crontab (sempre editar com crontab -e ) poderia ter esta aparência:

00 14 * * * (sh -x /tmp/my_wrapper_script) >> /tmp/debug.log 2>&1

Inspecione /tmp/debug.log e seu registro de data e hora. Se estiver vazio, inexistente ou o limite de tempo não for logo após as 14:00 (neste exemplo), você pode ter um problema com o cron, caso contrário, você precisará depurar a ação de destino real e o cron estará funcionando bem!

    

Answer 16

Você usou:

*  *  * * * DISPLAY=:0 /path/to/your/app

mas falhou porque o seu diretório ~/.dbus pertence não a você, mas ao root. Verifique:

ls -l ~/.dbus