RSync Erro no script

Question

No meu trabalho, nós temos um servidor central de Backup, rodando Debian Wheezy, e servidores locais em cada site, também rodando Debian Wheezy.

Algumas semanas atrás, o técnico do escritório central me enviou por e-mail que o backup não foi concluído corretamente na noite anterior. Nós temos resolvido desde então, mas ainda não conseguimos resolver o problema. A única coisa que cuspiu foi a seguinte em um cron email:

rsync error: received SIGINT, SIGTERM, or SIGHUP (code 20) at rsync.c(549) [generator=3.0.9]
rsync error: received SIGUSR1 (code 19) at main.c(1316) [receiver=3.0.9]

Pesquisando essa frase não leva praticamente nada. Eu encontrei um post de 2002 sobre a remoção da opção -v , mas isso não está sendo usado no script. O script que é executado todas as noites está abaixo:

#!/bin/sh
set -e
x="delete --exclude-from=r_filter --delete-excluded"

rsync -aq --$x site1.company.com:/etc  /BACKUPS/site1
rsync -aq --$x site1.company.com:/home /BACKUPS/site1

Está definido para ser executado às 3:00 da manhã, de segunda a sexta-feira, a partir do servidor de backup central. Se eles tentarem executá-lo manualmente durante o dia, ele funcionará bem (porque a maioria dos arquivos foi copiada anteriormente?). Está usando a opção -a , então presumo que possa arquivar arquivos abertos? Isso é tudo o que posso pensar.

Qual seria o nosso próximo passo para descobrir isso?

    

Answer 1

Se algo acontecer quando você executar um trabalho em um crontab em um determinado horário e isso não acontecer se você fizer um teste em que executar o trabalho em um minuto, há duas possibilidades possíveis:

• Há outro processo em um crontab que de alguma forma interfere no seu.
• Há um processo humano acontecendo naquele momento, como a equipe de limpeza desconectando um computador para conectar o aspirador de pó.

Seu processo de rsync está recebendo sinais a uma determinada hora da noite. A primeira coisa que eu procuro é outro processo em um crontab enviando sinais que ele não deveria estar enviando.

(Se algo correr bem na linha de comando, mas falhar quando executado a partir do cron, essa é uma chaleira de peixe totalmente diferente .)

    

Answer 2

Você pode tentar tornar seus comandos imunes aos sinais no caso isso acontece de novo e, ao mesmo tempo, na captura de fundo o sinal se está sendo direcionado para o seu shell através de alguns pai no mesmo grupo de processos. Por exemplo:

#!/bin/bash
( trap 'echo got signal; date; ps ax; kill $pid; exit' sigint sigterm sighup
  sleep 999999 &
  pid=$!
  wait
) &

trap '' sigint sigterm sighup
rsync ...
rsync ...
kill -hup $!

O trap '' irá ignorar os 3 sinais listados nos seguintes comandos. A parte de fundo em () irá capturar os sinais e, por exemplo, um ps ou algo semelhante para talvez encontrar o que está sendo executado neste momento.

Eu procuraria algo estúpido como um comando logrotate super entusiasmado fazendo essa sinalização.