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

Ambiente diferente

Cron passa um conjunto mínimo de variáveis de ambiente para seus trabalhos. Para ver a diferença, adicione um trabalho falso assim:

* * * * * env > /tmp/env.output

Espere que /tmp/env.output seja criado e remova o trabalho novamente. Agora compare o conteúdo de /tmp/env.output com a saída de env em seu terminal normal.

Uma "pegadinha" comum é a variável de ambiente PATH sendo diferente. Talvez seu script do cron use o comando somecommand encontrado em /opt/someApp/bin , que você adicionou a PATH in /etc/environment ? O cron ignora PATH desse arquivo, então runnning somecommand do seu script falhará quando executado com o cron, mas funciona quando executado em um terminal. Vale a pena notar que as variáveis de /etc/environment serão passadas para tarefas agendadas, mas não as variáveis que o cron define especificamente, como PATH .

Para contornar isso, basta definir sua própria variável PATH na parte superior do script. Por exemplo,

#!/bin/bash
PATH=/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 . Você teria que percorrer todo o script substituindo /opt/someApp/bin por /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 será aplicada a todas as tarefas do cron. Por exemplo,

PATH=/opt/someApp/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

15 1 * * * backupscript --incremental /home /root

    

Answer 2

Minha melhor pegadinha: se você esquecer de adicionar uma nova linha no final do arquivo crontab . Em outras palavras, o arquivo crontab deve terminar com uma linha vazia.

Abaixo está a seção relevante nas man pages desse problema ( 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)

    

Answer 3

O daemon do Cron não está em execução. Eu realmente estraguei tudo isso alguns meses atrás.

Tipo:

pgrep cron 

Se você não encontrar nenhum número, o cron não estará em execução. sudo /etc/init.d/cron start pode ser usado para iniciar o cron.

EDIT: Em vez de invocar scripts de inicialização por meio de /etc/init.d, use o serviço utilidade, por exemplo,

sudo service cron start

    

Answer 4

Os nomes de arquivo de script em cron.d/ , cron.daily/ , cron.hourly/ , etc., não devem conter ponto ( . ), caso contrário, as partes de execução os ignorarão.

Veja run-parts (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_-]+$).

Portanto, se você tiver um script do cron cronograma backup.sh , analyze-logs.pl in cron.daily/ , é melhor remover os nomes das extensões.

    

Answer 5

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

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

• Tente executar o comando em sh para ver se funciona
• Envolva o comando em um subshell de 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 seu crontab:
  SHELL=/bin/bash
• Se o comando for um script, verifique se o script contém um shebang:% #!/bin/bash

Answer 6

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

sudo service cron restart

    

Answer 7

Se o seu comando crontab tiver um símbolo % , o cron tenta interpretá-lo. Então, se você estava usando qualquer comando com um % (como uma especificação de formato para o comando date), você precisará escapar dele.

Essa e outras boas dicas aqui: link

    

Answer 8

O caminho absoluto deve ser usado para scripts:

Por exemplo, /bin/grep deve ser usado em vez de grep :

# m h  dom mon dow   command
0 0 *  *  *  /bin/grep ERROR /home/adam/run.log &> /tmp/errors

Em vez de:

# m h  dom mon dow   command
0 0 *  *  *  grep ERROR /home/adam/run.log &> /tmp/errors

Isso é especialmente complicado, porque o mesmo comando funcionará quando executado a partir do shell. O motivo é que cron não possui a mesma variável de ambiente PATH do usuário.

    

Answer 9

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á o 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), o registro para o cron não é ativado por padrão. Em /etc/rsyslog.conf ou /etc/rsyslog.d/50-default.conf a linha:

# cron.*                          /var/log/cron.log

deve ser editado ( sudo nano /etc/rsyslog.conf ) descomentado para:

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 log de crontab no Debian Linux

Em alguns sistemas (Ubuntu), o arquivo de log separado para o cron não é 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

para visualizar mensagens relacionadas ao cron.

    

Answer 10

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

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

    

Answer 11

Se o seu cronjob invoca aplicativos GUI, você precisa dizer a eles que DISPLAY eles devem usar.

Exemplo: lançamento do Firefox com o cron.

Seu script deve conter export DISPLAY=:0 em algum lugar.

    

Answer 12

Problemas de permissões são bastante comuns, receio.

Observe que uma solução comum é executar tudo usando o crontab do root, que às vezes é uma Idéia Realmente Ruim. Definir permissões adequadas é definitivamente um problema amplamente negligenciado.

    

Answer 13

Permissão de tabela cron insegura

Uma tabela cron é rejeitada se sua permissão for insegura

sudo service cron restart
grep -i cron /var/log/syslog|tail -2
2013-02-05T03:47:49.283841+01:00 ubuntu cron[49906]: (user) INSECURE MODE (mode 0600 expected) (crontabs/user)

O problema é resolvido com

# correct permission
sudo chmod 600 /var/spool/cron/crontabs/user
# signal crond to reload the file
sudo touch /var/spool/cron/crontabs

    

Answer 14

O script é sensível à localização. Isso está relacionado a sempre usar caminhos absolutos em um script, mas não exatamente o mesmo. Seu trabalho cron pode precisar de cd para um diretório específico antes de ser executado, por exemplo, uma tarefa rake em um aplicativo Rails pode precisar estar na raiz do aplicativo para que o Rake encontre a tarefa correta, sem mencionar a configuração apropriada do banco de dados, etc.

Portanto, uma entrada de crontab

23 3 * * * /usr/bin/rake db:session_purge RAILS_ENV=production

seria melhor como

23 3 * * * cd /var/www/production/current && /usr/bin/rake db:session_purge RAILS_ENV=production

Ou, para manter a entrada do crontab mais simples e menos frágil:

23 3 * * * /home/<user>/scripts/session-purge.sh

com o seguinte código em /home/<user>/scripts/session-purge.sh :

cd /var/www/production/current
/usr/bin/rake db:session_purge RAILS_ENV=production

    

Answer 15

As especificações do Crontab que funcionavam no passado podem quebrar quando movidas de um arquivo crontab para outro. Às vezes, o motivo é que você moveu a especificação de um arquivo crontab do sistema para um arquivo crontab do usuário ou vice-versa.

O formato de especificação da tarefa cron difere entre os arquivos crontab dos usuários (/ var / spool / cron / username ou / var / spool / cron / crontabs / username) e os crontabs do sistema ( /etc/crontab e os arquivos em /etc/cron.d ).

O crontabs do sistema tem um campo extra 'user' logo antes do comando a executar.

Isso causará erros indicando coisas como george; command not found quando você mover um comando de /etc/crontab ou um arquivo em /etc/cron.d para o arquivo crontab de um usuário.

Por outro lado, o cron fornecerá erros como /usr/bin/restartxyz is not a valid username ou semelhantes quando ocorrer o inverso.

    

Answer 16

o script do cron invoca um comando com a opção --verbose

Eu tive um script cron com falha em mim porque estava no piloto automático ao digitar o script e incluí a opção --verbose:

#!/bin/bash
some commands
tar cvfz /my/archive/file.tar.gz /my/shared/directory
come more commands

O script correu bem ao executar a partir do shell, mas falhou ao executar a partir do crontab porque a saída detalhada vai para stdout quando executada a partir do shell, mas em nenhum lugar quando executada a partir do crontab. Correção fácil de remover o 'v':

#!/bin/bash
some commands
tar cfz /my/archive/file.tar.gz /my/shared/directory
some more commands

    

Answer 17

O motivo mais frequente que vi o cron falhar em um cronograma declarado incorretamente. É necessário especificar uma tarefa marcada para as 23:15 como 30 23 * * * em vez de * * 11 15 * ou 11 15 * * * . O dia da semana para os trabalhos após a meia-noite também fica confuso M-F é 2-6 depois da meia-noite, não 1-5 . Datas específicas geralmente são um problema, pois raramente as usamos * * 3 1 * não é 3 de março.

Se o seu trabalho com plataformas diferentes usando opções não suportadas, como 2/3 em especificações de tempo, também pode causar falhas. Esta é uma opção muito útil, mas não universalmente disponível. Eu também encontrei várias listas como 1-5 ou 1,3,5 .

O uso de caminhos não qualificados também causou problemas. O caminho padrão geralmente é /bin:/usr/bin , então somente os comandos padrão serão executados. Esses diretórios geralmente não possuem o comando desejado. Isso também afeta os scripts usando comandos não padrão. Outras variáveis de ambiente também podem estar ausentes.

Derrubar um crontab existente me causou problemas. Eu agora carrego de uma cópia de arquivo. Isso pode ser recuperado a partir do crontab existente usando crontab -l se ele for derrotado. Eu guardo a cópia do crontab em ~ / bin. É comentado e termina com a linha # EOF . Isso é recarregado diariamente a partir de uma entrada do crontab como:

#!/usr/bin/crontab
# Reload this crontab
#
54 12    *   *   *   ${HOME}/bin/crontab

O comando reload acima se baseia em um crontab executável com um caminho bang executando o crontab. Alguns sistemas requerem o crontab em execução no comando e especificam o arquivo. Se o diretório for compartilhado em rede, geralmente uso crontab.$(hostname) como o nome do arquivo. Isso eventualmente corrigirá casos em que o crontab errado foi carregado no servidor errado.

O uso do arquivo fornece um backup do que deve ser o crontab e permite que edições temporárias (a única vez que eu uso crontab -e ) sejam restauradas automaticamente. Existem cabeçalhos disponíveis que ajudam a obter os parâmetros de agendamento corretamente. Eu os adicionei quando usuários inexperientes estariam editando um crontab.

Raramente, encontrei comandos que exigem entrada do usuário. Estes falham sob o crontab, embora alguns trabalhem com redirecionamento de entrada.

    

Answer 18

Se você estiver acessando uma conta por meio de chaves SSH, é possível fazer login na conta, mas não perceber que a senha da conta está bloqueada (por exemplo, devido a tentativas de expiração ou de senha inválida)

Se o sistema estiver usando o PAM e a conta estiver bloqueada, isso poderá impedir que seu cronjob seja executado. (Eu testei isso no Solaris, mas não no Ubuntu)

Você pode encontrar mensagens como esta em / var / adm / messages:

Oct 24 07:51:00 mybox cron[29024]: [ID 731128 auth.notice] pam_unix_account: cron attempting to validate locked account myuser from local host
Oct 24 07:52:00 mybox cron[29063]: [ID 731128 auth.notice] pam_unix_account: cron attempting to validate locked account myuser from local host
Oct 24 07:53:00 mybox cron[29098]: [ID 731128 auth.notice] pam_unix_account: cron attempting to validate locked account myuser from local host
Oct 24 07:54:00 mybox cron[29527]: [ID 731128 auth.notice] pam_unix_account: cron attempting to validate locked account myuser from local host

Tudo o que você precisa fazer é executar:

# passwd -u <USERNAME>

como root para desbloquear a conta, e o crontab deve funcionar novamente.

    

Answer 19

No meu caso, o cron e o crontab tinham proprietários diferentes.

NÃO está funcionando, eu tive isso:

User@Uva ~ $ ps -ef | grep cron | grep -v grep
User    2940    7284 pty1     19:58:41 /usr/bin/crontab
SYSTEM   11292     636 ?        22:14:15 /usr/sbin/cro 

Basicamente eu tive que executar o cron-config e responder as perguntas corretamente. Há um ponto em que fui obrigado a digitar minha senha de usuário do Win7 para minha conta de 'Usuário'. Da leitura que fiz, parece que esse é um possível problema de segurança, mas eu sou o único administrador em uma única rede doméstica, então decidi que estava tudo bem.

Aqui está a sequência de comandos que me levou:

User@Uva ~ $ cron-config
The cron daemon can run as a service or as a job. The latter is not recommended.
Cron is already installed as a service under account LocalSystem.
Do you want to remove or reinstall it? (yes/no) yes
OK. The cron service was removed.

Do you want to install the cron daemon as a service? (yes/no) yes
Enter the value of CYGWIN for the daemon: [ ] ntsec

You must decide under what account the cron daemon will run.
If you are the only user on this machine, the daemon can run as yourself.
   This gives access to all network drives but only allows you as user.
To run multiple users, cron must change user context without knowing
  the passwords. There are three methods to do that, as explained in
  http://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-nopasswd1
If all the cron users have executed "passwd -R" (see man passwd),
  which provides access to network drives, or if you are using the
  cyglsa package, then cron should run under the local system account.
Otherwise you need to have or to create a privileged account.
  This script will help you do so.
Do you want the cron daemon to run as yourself? (yes/no) no

Were the passwords of all cron users saved with "passwd -R", or
are you using the cyglsa package ? (yes/no) no

Finding or creating a privileged user.
The following accounts were found: 'cyg_server' .
This script plans to use account cyg_server.
Do you want to use another privileged account name? (yes/no) yes
Enter the other name: User

Reenter: User


Account User already exists. Checking its privileges.
INFO: User is a valid privileged account.
INFO: The cygwin user name for account User is User.

Please enter the password for user 'User':
Reenter:
Running cron_diagnose ...
... no problem found.

Do you want to start the cron daemon as a service now? (yes/no) yes
OK. The cron daemon is now running.

In case of problem, examine the log file for cron,
/var/log/cron.log, and the Windows event log (using /usr/bin/cronevents)
for information about the problem cron is having.

Examine also any cron.log file in the HOME directory
(or the file specified in MAILTO) and cron related files in /tmp.

If you cannot fix the problem, then report it to [email protected].
Please run the script /usr/bin/cronbug and ATTACH its output
(the file cronbug.txt) to your e-mail.

WARNING: PATH may be set differently under cron than in interactive shells.
         Names such as "find" and "date" may refer to Windows programs.


User@Uva ~ $ ps -ef | grep cron | grep -v grep
    User    2944   11780 ?        03:31:10 /usr/sbin/cron
    User    2940    7284 pty1     19:58:41 /usr/bin/crontab

User@Uva ~ $

    

Answer 20

Eu estava escrevendo um script de shell de instalação que cria outro script para limpar dados de transações antigos de um banco de dados. Como parte da tarefa, ele tinha que configurar o trabalho diário cron para ser executado em um momento arbitrário, quando o carregamento do banco de dados estava baixo.

Eu criei um arquivo mycronjob com agendamento de cronograma, nome de usuário & amp; o comando e copiou-o para o diretório /etc/cron.d . Meus dois truques:

1. O arquivo mycronjob teve que ser de propriedade da raiz para ser executado
2. Eu tive que configurar as permissões do arquivo para 644 - 664 não seria executado.

Um problema de permissão aparecerá em /var/log/syslog como algo semelhante a:

Apr 24 18:30:01 ip-11-22-33-44 cron[40980]: (*system*) INSECURE MODE (group/other writable) (/etc/crontab)
Apr 24 18:30:01 ip-11-22-33-44 cron[40980]: (*system*) INSECURE MODE (group/other writable) (/etc/cron.d/user)

A primeira linha refere-se ao arquivo /etc/crontab e, posteriormente, a um arquivo que coloquei em /etc/cront.d .

    

Answer 21

Se você tem um comando como este:

* * * * * /path/to/script >> /tmp/output

e ele não funciona e você não pode ver nenhuma saída, isso pode não necessariamente significar que o cron não está funcionando. O script pode ser quebrado e a saída vai para stderr que não é passada para / tmp / output. Verifique se esse não é o caso, capturando também esta saída:

* * * * * /path/to/script >> /tmp/output 2>&1

para ver se isso ajuda você a entender seu problema.

    

Answer 22

Linha escrita de uma maneira que o crontab não entende. Precisa ser escrito corretamente. Aqui está CrontabHowTo .

    

Answer 23

O daemon Cron pode estar em execução, mas não está funcionando de verdade. Tente reiniciar o cron:

sudo /etc/init.d/cron restart

    

Answer 24

Escrevendo para o cron via "crontab -e" com o argumento username em uma linha. Eu vi exemplos de usuários (ou sysadmins) escrevendo seus scripts de shell e não entendendo por que eles não automatizam. O argumento "user" existe em / etc / crontab, mas não nos arquivos definidos pelo usuário. Assim, por exemplo, seu arquivo pessoal seria algo como:

# m h dom mon dow command

* * */2  *   *  /some/shell/script

considerando que o / etc / crontab seria:

# m h dom mon dow user   command

* * */2  *   *  jdoe   /some/shell/script

Então, por que você faria o último? Bem, dependendo de como você deseja definir suas permissões, isso pode ficar muito confuso. Escrevi scripts para automatizar tarefas para usuários que não entendem as complexidades ou não querem se incomodar com o trabalho penoso. Definindo permissões para --x------ , posso tornar o script executável sem que eles possam ler (e talvez acidentalmente alterar) isso. No entanto, talvez eu queira executar esse comando com vários outros de um arquivo (facilitando, assim, a manutenção), mas certifique-se de que a saída do arquivo esteja atribuída ao proprietário correto. Fazê-lo (pelo menos no Ubuntu 10.10) rompe a incapacidade de ler o arquivo, bem como executar, além do problema mencionado antes de colocar períodos em / etc / crontab (o que, curiosamente, não causa erros ao passar por crontab -e ).

Como exemplo, vi instâncias de sudo crontab -e usadas para executar um script com permissões de root, com um chown username file_output correspondente no script de shell. Desleixado, mas funciona. IMHO, A opção mais graciosa é colocá-lo em /etc/crontab com o nome de usuário declarado e permissões apropriadas, então file_output vai para o lugar e proprietário correto.

    

Answer 25

Criando o que Aaron Peart mencionou sobre o modo verbose, às vezes os scripts não no modo verbose serão inicializados, mas não terminados, se o comportamento padrão de um comando incluído for a saída de uma linha ou mais para a tela quando a proc for iniciada. Por exemplo, eu escrevi um script de backup para nossa intranet que usava curl, um utilitário que baixa ou envia arquivos para servidores remotos, e é bastante útil se você puder acessar apenas os arquivos remotos por meio de HTTP. Usar o 'curl link ' fazia com que um script que escrevi fosse interrompido e nunca fosse concluído porque ele cria uma nova linha seguida por uma linha de progresso. Eu tive que usar o sinalizador silencioso (-s) para dizer a ele para não produzir qualquer informação, e escrever no meu próprio código para manipular se o arquivo não conseguiu fazer o download.

    

Answer 26

Embora você possa definir variáveis de ambiente em seu crontable, você não está em um script de shell. Então, construções como as seguintes não funcionam:

SOME_DIR=/var/log
MY_LOG_FILE=${SOME_LOG}/some_file.log

BIN_DIR=/usr/local/bin
MY_EXE=${BIN_DIR}/some_executable_file

0 10 * * * ${MY_EXE} some_param >> ${MY_LOG_FILE}

Isso ocorre porque as variáveis não são interpretadas no crontable: todos os valores são tomados literalmente. E isso é o mesmo se você omitir os colchetes. Portanto, seus comandos não serão executados e seus arquivos de log não serão gravados ...

Em vez disso, você deve definir todas as suas variáveis de ambiente diretamente:

SOME_DIR=/var/log
MY_LOG_FILE=/var/log/some_file.log

BIN_DIR=/usr/local/bin
MY_EXE=/usr/local/bin/some_executable_file

0 10 * * * ${MY_EXE} some_param >> ${MY_LOG_FILE}

    

Answer 27

Quando uma tarefa é executada dentro do cron, stdin é fechado. Programas que agem diferentemente com base em se stdin está disponível ou não se comportarão diferentemente entre a sessão de shell e no cron.

Um exemplo é o programa goaccess para analisar arquivos de log do servidor web. Isso não funciona no cron:

goaccess -a -f /var/log/nginx/access.log > output.html

e goaccess mostram a página de ajuda em vez de criar o relatório. Na casca isso pode ser reproduzido com

goaccess -a -f /var/log/nginx/access.log > output.html < /dev/null

A correção para goaccess é fazer com que ele leia o log de stdin em vez de ler o arquivo, então a solução é alterar a entrada do crontab para

cat /var/log/nginx/access.log | goaccess -a > output.html

    

Answer 28

Nos meus servidores RHEL7, os trabalhos do cron do cronograma seriam executados, mas os trabalhos do usuário não. Descobri que sem um diretório inicial, os trabalhos não serão executados (mas você verá bons erros em / var / log / cron). Quando criei o diretório inicial, o problema foi resolvido.

    

Answer 29

Se você editou seu arquivo crontab usando um editor do Windows (via samba ou algo assim) e ele substituiu as novas linhas com \ n \ r ou apenas \ r, o cron não será executado.

Além disso, se você estiver usando /etc/cron.d/* e um desses arquivos tiver um \ r nele, o cron irá percorrer os arquivos e parar quando atingir um arquivo incorreto. Não tenho certeza se esse é o problema?

Uso:

od -c /etc/cron.d/* | grep \r

    

Answer 30

Em 16.04, se você tem esse erro no syslog

(CRON) error (can't fork)

tente:

systemctl status cron.service

No resultado:

Tasks: num_task (limit: 512)

Se num_task estiver perto do limite, use:

systemctl set-property cron.service TasksMax=new_max

Substitua new_max por um valor adequado.