ssh “-f” não devolve mão no bash ao ouvir stdout / stderr

Question

Por favor, olhe para estes:

## Does NOT return to the shell, but Ctrl-C can exit
ssh -S none -fNR 13018:localhost:22 example.com | cat

## Returns to the shell (no "-S none")
ssh         -fNR 13019:localhost:22 example.com | cat

## Returns to the shell (no "| cat")
ssh -S none -fNR 13020:localhost:22 example.com

Por que o primeiro comando não retorna ao shell? Eu esperava que ele retornasse para o shell como o outro fez (como o -f Solicita o ssh para ir para o segundo plano antes da execução do comando. ) e está presente nas três amostras que dei e parecem se comportar erraticamente após o redirecionamento de sua saída (simbolizado aqui pelo | cat ). O -S none não é uma opção relacionada (especialmente que -S none deve ser o comportamento padrão, pois não tenho nenhuma opção ControlMaster definida) e parece, no entanto, alterar o comportamento de -f . Tudo isso me intriga.

Existe alguma maneira de capturar o stdout / stderr do último comando com este comando retornando ao shell, para poder reagir de acordo com sua saída?

A história toda:

Eu quero executar o túnel SSH e, após uma falha, verifique se ele está relacionado à porta que está sendo usada. Nesse caso, vou tentar outra porta. Eu não posso usar o nível de erro, pois não é distintivo, e ao tentar pegar stderr, eu corri em comportamentos ssh que não são claros para mim e eles parecem mesmo falsos (não deve haver diferenças entre usar -S none e não usá-lo, porque é o valor padrão e eu verifiquei meu ~/.ssh/config que estava vazio, e o /etc/ssh/ssh_config não tinha ControlMaster relacionado conjunto de opções.)

EDITAR:

• Parece que não consigo reproduzir o segundo exemplo, conforme descrito. O processo ssh pode terminar algumas vezes antes e, às vezes, após cat process abrir o canal?

Answer 1

Estranho, o que eu não entendo é por que seu segundo exemplo retorna ao shell (e não consigo reproduzir isso).

Quando você executa ssh -S none -fNR 13018:localhost:22 example.com | cat , um processo ssh permanece em segundo plano. Ainda tem a extremidade de gravação do tubo aberta. Portanto, cat ainda não viu um fim de arquivo em sua entrada padrão e, portanto, continua lendo.

Pressionando Ctrl + C mata o processo cat (é a única parte da tarefa que ainda está em execução, já que o processo ssh no plano de fundo foi movido para o seu próprio grupo de processos e o processo ssh em primeiro plano termina assim que é bifurcado). Se o processo ssh de fundo tentou gravar em sua saída padrão (o que não acontecerá, devido ao -N ), a gravação seria falsa com EPIPE (blocos ssh SIGPIPE). O processo cat também sairia se você matasse o processo ssh em segundo plano.