Início / unix / Perguntas / 430394
Accepted
dot
Asked: 2018-03-16 05:08:50 +0800 CST

Como solucionar problemas de cron job com falha

  • 772

Eu tenho um crontab rootarquivo que se parece com isso:

lab-1:/var/www/cdd# crontab -l
# do daily/weekly/monthly maintenance
# min   hour    day     month   weekday command
*       *       *       *       *       /etc/scripts/script1
*/15    *       *       *       *       /etc/scripts/script2
0       *       *       *       *       /etc/scripts/script3

Posso ver que todos os trabalhos são acionados executando este comando:

lab-1:/var/www/cdd# cat /var/log/messages | grep cron.info
Mar 15 13:00:00 lab-1 cron.info crond[7897]: USER root pid 26217 cmd /etc/scripts/script2
Mar 15 13:00:00 lab-1 cron.info crond[7897]: USER root pid 26219 cmd /etc/scripts/script3        
Mar 15 13:01:00 lab-1 cron.info crond[7897]: USER root pid 26293 cmd /etc/scripts/script1

O problema é que script3 (eu provei que script2 e script1 funcionam) não está realmente produzindo a saída esperada. É suposto criar arquivos em outra pasta. No entanto, quando eu o executo manualmente, funciona bem:

 lab-1:/etc/scripts# bash script3

Eu não sou um administrador de sistema real, então não tenho certeza de qual é a melhor maneira de solucionar isso.

A primeira coisa que vem à mente são as permissões.

lab-1:/etc/scripts# ls -lah                            
total 24                                                                     
drwxr-xr-x    2 root     root        4.0K Mar 15 12:20 .                     
drwxr-xr-x   34 root     root        4.0K Mar 14 17:11 ..                    
-rwxr-xr-x    1 root     root        5.0K Mar 15 12:19 script3
-rwxr-xr-x    1 root     root        1.8K Mar 14 15:26 script1
-rwxr-xr-x    1 root     root        1.9K Mar 14 15:26 script2

Embora ... tendo dito isso, se fosse um problema de permissão, ele apareceria como sendo acionado / iniciado em meu /var/log/messagesarquivo?

Como devo proceder?

EDITAR 1

lab-1:/etc/scripts# ./script3 | head -n 4                                             
Working folder set to: /tmp/tmp.kOfhip                                                                        
*****Grab SQL Data from Remote Server: spp.mydomain.net *****                                             
COPY 344                                                                                                      
Warning: Permanently added 'spp.mydomain.net,10.1.1.1' (ECDSA) to the list of known hosts.           
Evaluate /tmp/tmp.kOfhip/spp.mydomain.net.db                                                          
lab-1:/etc/scripts#

EDITAR 2

É assim que meu script se parece:

https://paste.pound-python.org/show/90vAlrOsAYP0CtYqNWfl/

Como você pode ver, estou criando uma pasta temporária e fazendo todo o meu trabalho lá.

EDITAR 3

Para provar a mim mesmo que não é por causa de linhas como a linha 9, comentei tudo, exceto as linhas 1 a 15. Adicionei a linha 16 que faz isso:

 echo "done" >> /tmp/results.txt

E então mudei o cronograma do trabalho para executar a cada dois minutos a partir de uma hora. Eu posso ver que já foi executado 3 vezes. Acho que vou continuar com essa abordagem até encontrar algo que não funcione / exploda. Não entendo muito bem o comentário feito abaixo sobre o uso de uma variável PATH ... mas acho que vou pesquisar no Google.

EDITAR 4

Alterei o arquivo raiz do crontabs para que ele gere os resultados do script3 em um arquivo e é isso que vejo:

Working folder set to: /tmp/tmp.GeNGDJ
*****Grab SQL Data from Remote Server: servername *****
COPY 344
Warning: Permanently added 'spp.mydomain.net,10.1.1.132' (ECDSA) to the list of known hosts.
Permission denied (publickey,keyboard-interactive).
Evaluate /tmp/tmp.GeNGDJ/spp.mydomain.net.db
cat: can't open '/tmp/tmp.GeNGDJ/spp.mydomain.net.db': No such file or directory

Então está morrendo ao tentar scp o arquivo. O SQL remoto funciona bem e mostra a saída. Mas, como você pode ver, estou recebendo uma permissão negada. Mas se eu executar o mesmo comando manualmente, parece funcionar. Terá que continuar bisbilhotando. Tentarei despejar o ENV como sugerido na resposta abaixo.

bash shell-script

1 respostas

  1. Best Answer

    Um erro comum ao escrever scripts que serão executados posteriormente pelo cron, é que você assume que o script terá exatamente o mesmo ambiente que você tem quando está logado e o está desenvolvendo. Não tem!

    Escreva um script4 que contenha a seguinte linha

    OFILE=/tmp/crons.environment
(/usr/bin/whoami
/usr/bin/env ) > $OFILE 2>&1

    E faça com que o cron execute isso

    Agora compare a saída em /tmp/crons.environment com o que você obtém quando digitaenv

    Seu script assume, por exemplo, que $PATH está configurado corretamente para encontrar todos os programas que você executa, você também está consultando um banco de dados, pode haver outras variáveis ​​de ambiente necessárias para que esses comandos sejam executados corretamente.

    Para verificar a saída do trabalho cron. Modifique temporariamente o comando executado pelo cron e redirecione stdout e stderr para um arquivo conhecido, como fiz acima.

    0       *       *       *       *       /etc/scripts/script3 > /tmp/s3.out 2>&1
    • 3

relate perguntas