Erros intermitentes de rsync sobre ssh via cron w / Ubuntu 10.04: inexplicável e fluxo de dados de protocolo

Question

Eu tenho um número de clientes rsync tentando se conectar a um servidor rsync rotineiramente, e eles estão falhando intermitentemente com uma das duas mensagens de erro.

Ou:

rsync: connection unexpectedly closed (0 bytes received so far) [Receiver]
rsync error: unexplained error (code 255) at io.c(601) [Receiver=3.0.7]

Ou:

rsync: connection unexpectedly closed (0 bytes received so far) [Receiver]
rsync error: error in rsync protocol data stream (code 12) at io.c(601) [Receiver=3.0.7]

A versão atual do comando rsync que estou usando é:

rsync --rsync-path="/usr/bin/rsync" --stats --compress --times --links \
    --log-file=/home/ubuntu/rsynclog.txt --exclude thatfile --recursive \
    xxx.xx.xxx.xx:/home/ubuntu/utility_scripts/ /home/ubuntu/utility_scripts &

Anteriormente, eu tinha --verbose e --progress , mas os removi depois de ler em outro fórum que alguém havia resolvido alguns problemas de latência removendo essas opções. Eu também tentei este comando na forma de um script de shell, pensando que talvez o problema fosse que meu cliente rsync estava tentando reutilizar uma conexão ssh expirada. Para esse fim, falha aparentemente de forma aleatória, seja usando rsh ou ssh. Periodicamente falha se eu faço --del ou --delete , --compress ou não, --rsync-path ou não.

Não consigo fazer com que o comando falhe na linha de comando, mas quando é executado a cada minuto, ele falha de 5 a 15 vezes por hora, dependendo do diretório que está sendo rsync'ed. As permissões e a propriedade parecem estar corretas, e eu não estou confiando em nenhum tipo de variável ambiental que possa estar causando falha no cron. Todos os pacotes de software relevantes (bash, rsync, ssh, Linux) estão atualizados, todas as portas principais estão abertas e todos os clientes não falham simultaneamente, sugerindo que isso não é um problema do lado do servidor.

tldr: o rsync às vezes falha ao executar como uma tarefa Cron, descartou a maioria dos problemas de RTFM, mas o problema persiste.

Atualização: 20/09/10: Atualização da AMI do EC2 no cliente e no servidor e execução de um teste de 3 caixas com 2 clientes fazendo o download de um servidor em 24 horas. Após a conclusão do teste, os logs tiveram zero erros, então comecei a substituir outras instâncias pelas instâncias atualizadas da AMI. Após um fim de semana de execução dos clientes 35-40ish, eu tenho logs mais uma vez preenchidos com:

2010/09/20 16:27:01 [18581] rsync error: error in rsync protocol data stream (code 12) at io.c(601) [Receiver=3.0.7]
2010/09/20 16:30:01 [18627] rsync error: unexplained error (code 255) at io.c(601) [Receiver=3.0.7]
2010/09/20 16:36:01 [18739] rsync error: unexplained error (code 255) at io.c(601) [Receiver=3.0.7]
2010/09/20 16:40:02 [18810] rsync error: unexplained error (code 255) at io.c(601) [Receiver=3.0.7]
2010/09/20 16:50:01 [18972] rsync error: unexplained error (code 255) at io.c(601) [Receiver=3.0.7]
2010/09/20 17:00:01 [19139] rsync error: unexplained error (code 255) at io.c(601) [Receiver=3.0.7]
2010/09/20 17:10:01 [19328] rsync error: unexplained error (code 255) at io.c(601) [Receiver=3.0.7]

Não é razoável ter 35 clientes conectados a um servidor rsync simultaneamente? Isso é possivelmente um problema de carga?

    

Answer 1

Obrigado a Izidor Jerebic, que postou a solução na lista de discussão do rsync:

this might be a problem with maximal number of concurrent ssh connections or connection requests. Ssh daemon has two configuration settings where you can define what is the maximal number of clients which can connect concurrently. This number is by default not very high, so you are probably bumping against that limit.

MaxSessions

Specifies the maximum number of open sessions permitted per network connection. The default is 10.

MaxStartups

Specifies the maximum number of concurrent unauthenticated connections to the SSH daemon. Additional connections will be dropped until authentication succeeds or the LoginGraceTime expires for a connection. The default is 10.

Depois de subir esses valores, tudo está funcionando bem. Não se esconder do fato de que isso era um problema do RTFM, mas nem o MaxStartups nem o MaxSessions são definidos na página do manual ssh. E enquanto MaxStartups, pelo menos, aparece no arquivo sshd_config, MaxSessions parece apenas aparecer em um changelog do OpenSSH ( link ) .