RSYNC falha periodicamente via SSH, cano quebrado

Question

Um script post-commit chama um comando rsync para atualizar arquivos do sistema SVN para um servidor Web de produção, ambos executando o Ubuntu 10.04.3, rsync 3.1.1. O problema também estava ocorrendo com rsync 3.0.7, e a atualização para 3.1.1 foi uma etapa de solução de problemas.

Independentemente de os arquivos precisarem ser atualizados ou não, eu recebo periodicamente:

Write Failed: Broken pipe
rsync: connection unexpectedly closed (xxxx bytes sent so far) [sender]

Quando o pipe quebra a saída muito detalhada, 99% do tempo termina em:

send_files(2, /some/path/to/.htaccess)
send_files(3, /some/path/to/file1.zip)
send_files(4, /some/path/to/file2.zip)
send_files(5, /some/path/to/file3.zip)
send_files(6, /some/path/to/file4.zip)
send_files(7, /some/path/to/index.php)
recv_files(22) starting
[sender] _exit_cleanup(code=12, file=io.c, line=226): about to call exit(255)

As conexões

SSH e SCP permanecem ativas e funcionam bem nos dois servidores, sem problemas. Se eu executar o comando rsync 10 vezes seguidas, cerca de 50% do tempo é suficiente. A transferência de arquivos de todos os diretórios exibe esse sintoma. Por isso, não acho que seja um problema específico de tipo de arquivo ou de permissão.

Mais alguns resultados:

send_files(27, /a/different/path/verdana.ttf)
recv_files(50) starting
[sender] _exit_cleanup(code=12, file=io.c, line=226): about to call exit(255)

send_files(25, /yet/another/path/unsubscribe.htm)
recv_files(162) starting
[sender] _exit_cleanup(code=12, file=io.c, line=226): about to call exit(255)

Aqui está uma amostra do comando:

rsync -azv --delete --exclude=.svn /svn/path -e ssh user@server:/remote/path

    

Answer 1

Você mencionou que vê o pacote TCP RST sempre que isso falha. Isso soa semelhante ao problema de um firewall potencialmente desconectar, como mencionado na postagem a seguir, que também tem um trabalho ao reutilizar uma conexão suspensa do ssh. rsync-connection-closing-right-around-a-hour

Há também uma opção de --timeout = [timeout value] mas eu acho que não é tão bom quanto a solução de conexão pendente ssh.