Este código termina com o erro:
(
ssh localhost seq 100000
seq 100000
) | wc
#-> seq: write error: Resource temporarily unavailable
Este é um código mínimo para reproduzir o erro de gravação. O objetivo não é alterar a arquitetura do subprocesso/pipe para fazê-lo funcionar, mas entender por que esse erro ocorre quando fd 1 é atribuído a um pipe que é reutilizado posteriormente para gravar uma saída grande.
Por que o cliente SSH deixa o descritor de arquivo stdout sujo? É uma desvantagem de design? Existe uma opção para fazê-lo se comportar como outro processo faria?
EDIT : graças às pistas nos comentários, suspeito que possa estar relacionado às versões 7.9 a 8.4 do OpenSSH
Dadas as fortes pistas sugerindo que é devido a uma regressão específica da versão, aqui estão três maneiras de obter o código que não depende da versão do OpenSSH.
Verificação feita de que apenas fd 1 é afetado e fd 0 e 2 são deixados limpos, a permutação entre fd 1 e 2 é uma solução possível. No código a seguir, o fd 2 fica sujo, mas o defeito não aparece, a menos que uma quantidade suficiente de dados seja escrita nele, enquanto o fd 1 está limpo:
Ou usando um pipe adicional, envolva ssh em um subprocesso para isolar o descritor de arquivo afetado:
Pode ser uma desvantagem aceitável se você tiver que escrever uma invocação SSH que pode compartilhar o descritor de arquivo stdout sem dependência da versão afetada do OpenSSH.
Uma terceira maneira é atribuir o fd afetado a um arquivo em vez de diretamente a um pipe. Aqui está uma função para fazer isso:
EDIT: https://bugzilla.mindrot.org/show_bug.cgi?id=3280 foi reportado na versão 8.5 (mas existia pelo menos na 7.9) e fechado na versão 8.9. Se você não pode atualizar seus binários, você pode querer colocar este script com basename
ssh
na frente/usr/bin
de seu usuário PATH: