Crontab não executará script

0

Aqui está o meu cron:

crontab -l

30 2 * * * /usr/sbin/stime&
32 2 * * * /usr/sbin/rtc -s
30 2 2 * * /usr/sbin/rtc -c
00 5 * * * /path/to/script/backup.sh >/dev/null 2>&1

Aqui está meu script:

backup.sh

#!/bin/sh

rsync -e"ssh -i /path.to/id_rsa" -aP MyUsername@HostIP:/path/to/host/backup/ /path/to/local/backup --exclude '*.sql'

Se eu executar backup.sh na linha de comando, ele será executado. Cron não vai rodá-lo.

Eu pensei que poderia ser um problema, então eu modifiquei o comando no crontab assim:

00 5 * * * su - root -c /path/to/script/backup.sh >/dev/null 2>&1

Ainda não há execução do crontab. A hora e a data estão corretas. Alguma idéia?

    
por wjk 05.03.2016 / 10:47

1 resposta

2

Não descarte mensagens potencialmente úteis

Sempre que uma tarefa do cron falha misteriosamente, minha primeira ação geralmente é redirecionar STDOUT e STDERR para arquivos em / tmp para que eu possa ver qualquer mensagem de erro e outra saída potencialmente útil.

Assim, a entrada do cron seria

00 5 * * * /path/to/script/backup.sh >/tmp/backup.out 2>&1

Faça scripts auto documentando

Eu também geralmente garanto que algo útil está escrito lá, adicionando saída de diagnóstico para o script:

#!/bin/sh
echo "Backup starting..."
date
rsync -e"ssh -i /path.to/id_rsa" \
      -aP MyUsername@HostIP:/path/to/host/backup/ \ 
      /path/to/local/backup \
      --exclude '*.sql'    
echo "Backup ended"

Verifique as man pages

A página man do rsync diz

-q, --quiet
This option decreases the amount of information you are given during the 
transfer, notably suppressing information messages from the remote server. 
This option is useful when invoking rsync from cron.

Portanto, é provável que, quando a saída do rsync for direcionada para / dev / null, o rsync perceba que o STDOUT não está conectado a um terminal ou a um arquivo regular e termina com uma condição de erro.

Você talvez possa verificar isso alterando o comando cron para

00 5 * * * /path/to/script/backup.sh >/dev/null 2>/tmp/backup.err

e, em seguida, revendo o conteúdo de /tmp/backup.err

No entanto, adicionar a opção -q seria uma solução apropriada.

Um shell em lote não é como um shell interativo

Geralmente, ao executar a partir do cron, existem algumas diferenças importantes correndo de forma interativa

  • Você não pode confiar nas variáveis de ambiente que estão sendo configuradas (pegadinha importante)
  • Não há um TTY anexado ao processo (alguns programas dependem disso)
  • etc

Então, quando as coisas não funcionam como esperado, você deve reconsiderar como tudo isso pode afetar o que você está fazendo.

    
por 05.03.2016 / 16:13

Tags