Depurando o rsync sobre SSH no modo detalhado usando tee para redirecionar o stdout para o arquivo de log

1

Eu tenho tido problemas com várias operações de rsync sobre SSH, em uma máquina específica em nossa rede, falhando e dando erros como:

rsync: connection unexpectedly closed (45482 bytes received so far)  [generator]

Encontrei um post semelhante ( rsync - erro inexplicado ) para o qual um dos as respostas sugeridas executando o comando SSH usado pelo rsync no modo verbose e redirecionando a saída, no meu caso da seguinte forma:

rsync -av -e 'bash -x -c "ssh -p 22 -vvvv $0 $@ 2>/tmp/rsync-ssh.stderr | tee /tmp/rsync.stdout"' --rsync-path='sudo rsync' "[email protected]:/media/remote_volume/" "/media/local_volume"

Este comando rsync parece rodar bem por algum tempo, mas eventualmente falha com o erro:

tee: standard output: Resource temporarily unavailable

Eu estou supondo que provavelmente está falhando por uma razão semelhante à descrita na resposta à seguinte pergunta: No entanto, não parece claro para mim como eu deveria mudar o comando SSH no meu caso para remediar o problema.

Alguém sabe como fazer o SSH jogar bem com o tee neste cenário?

    
por PicoutputCls 23.11.2017 / 17:07

1 resposta

0

Depois de ler um pouco mais sobre a solução discutida na resposta à pergunta " Por que esse tee está perdendo stdout? ", parece que a mudança crucial está substituindo o pipe com o redirecionamento para um subshell contendo o comando que, de outra forma, estaria sendo canalizado. (Assim, substituindo: command1 | command2 com: command1 > >( command2 ) )

A razão para isto é que redirecionando para um subshell, ao invés de direcionar diretamente para o próximo comando, está-se forçando o subshell a lidar com qualquer EAGAIN retornaram. Como discutido nesta mensagem no fórum do FreeBSD: bin / 164947: o tee perde dados quando grava em non descritores de arquivo de bloqueio (também vinculados na resposta à outra pergunta) tee e outros binários do sistema podem ser muito ruins em manipular as próprias tentativas.

Para o comando rsync acima, as seguintes alterações parecem corrigir meu problema original:

rsync -av -e 'bash -x -c "ssh -p 22 -vvvv $0 $@ 2>/tmp/rsync-ssh.stderr > >( tee /tmp/rsync.stdout )"' --rsync-path='sudo rsync' "[email protected]:/media/remote_volume/" "/media/local_volume"
    
por 13.12.2017 / 13:37