Início / unix / Perguntas / 688021
Accepted
Ole Tange
Asked: 2022-01-27 04:08:13 +0800 CST

ssh lê stdin sem ser solicitado a

  • 772

Estes não fazem o mesmo:

$ seq 1000000 | (ssh localhost sleep 1; wc -l)
675173
$ seq 1000000 | (ssh localhost sleep 1 </dev/null; wc -l)
1000000

Qual é a razão para sshler stdin?

ssh pipe

2 respostas

  1. Best Answer

    ssh sempre lê stdin, a menos que você diga para não com a -nopção (ou a -fopção).

    A razão é para que você possa fazer coisas como

    tar cf - somedir | ssh otherhost "tar xf -"

    E sempre faz isso porque o ssh não tem como saber se seu comando remoto aceita entrada ou não.

    Provavelmente, o que está acontecendo no seu primeiro comando é que o seq preenche os buffers de rede e pipe (seq -> ssh -> sleep) e, como o sono não está lendo nada, ele fica bloqueado aguardando mais leituras e, em seguida, o sono sai, fazendo com que esses buffers completos sejam despejados e, em seguida, seq é desbloqueado, alimentando o restante para wc.

    Observe que você obteria resultados semelhantes comseq 1000000 | ( cat | cat | sleep 1; wc -l)

    Em seu segundo comando, ele ainda está lendo stdin, mas você atribuiu externamente /dev/null a stdin.

    • 6

  2. A entrada/saída do Unix é baseada em primitivas de comunicação unidirecional: enviar dados com write¹, extrair dados com read¹ e consultar a disponibilidade de dados com select. Não é o mesmo modelo que, por exemplo, é comum na web, onde o consumidor de dados envia uma solicitação “por favor, me dê alguns dados” e o produtor responde com os dados, ou o consumidor envia uma solicitação “quantos dados você pode me dar?" e o produtor responde com um tamanho. Um consumidor de dados chama readpara recuperar quaisquer dados disponíveis, e isso não precisa necessariamente envolver o produtor (por exemplo, os pipes têm um buffer e a leitura do buffer não precisa envolver a extremidade de gravação do pipe). Um consumidor de dados pode ligar selectpara saber se os dados estão disponíveis e isso não envolve o produtor.

    O servidor SSH pode saber se o aplicativo em execução no servidor está tentando ativamente ler a partir de sua entrada padrão: o servidor SSH pode chamar selectpara saber se a gravação de dados seria bloqueada. Mas se o aplicativo tentar ler de forma intermitente, o servidor SSH pode não chamar selectno momento certo, então pode perder que o aplicativo está tentando ler os dados. E o servidor SSH não tem como saber se ou quando o aplicativo pergunta se há dados disponíveis em sua entrada padrão chamando select. A única maneira de o servidor SSH fornecer dados ao aplicativo quando desejar é fornecer dados ao aplicativo quando estiverem disponíveis.

    Isso requer que o cliente transmita os dados para o servidor. Assim, o cliente lê sua entrada padrão e encaminha os dados assim que estiverem disponíveis.

    Uma vez que o cliente tenha lido alguns dados de sua entrada padrão, ele não poderá desler. Se o aplicativo do lado do servidor não acabar consumindo os dados, eles serão perdidos.

    Como consequência, ao chamar ssh, você precisa decidir no lado do cliente se deseja que a entrada padrão seja roteada pela conexão SSH ou não. Não é algo que o servidor possa lhe dizer.

    Consulte também conexões SSH em execução em segundo plano não saem se várias conexões tiverem sido iniciadas pelo mesmo shell que explora um cenário semelhante, mas mais complexo, envolvendo terminais.

    ¹ e amigos.

    • 4

relate perguntas