Entonces me preguntaba por qué quedan algunas conexiones SSH bloqueadas en algunos de mis scripts automatizados y me encontré con un problema extraño: SSH, si se usa sin PTY, no termina cuando se cierra la tubería de salida. Esto ya se ha discutido en varias otras preguntas aquí, pero no encontré una respuesta aplicable: algunas personas recomendaron usar -t
la opción, pero eso solicita el PTY y la tubería no funciona.
De todos modos, reduje el problema al siguiente ejemplo mínimo:
#this works
cat /dev/zero |false
#this never terminates
ssh user@host "cat /dev/zero" |false
¿Hay alguna explicación de por qué SSH ignoraría SIGPIPE que surge de la escritura en una tubería ya muerta (la que condujo a falso), o algún método para hacer que esto "funcione" correctamente?
Tenga en cuenta que no es necesario "retransmitir" el SIGPIPE al host remoto; simplemente matar al cliente ssh (que es lo que sucedería exactamente sin ignorar los SIGPIPE) conduce al mismo resultado con menos complejidad y algunas suposiciones "más correctas".
¡Gracias por tus ideas!
-mk
EDITAR: ocurre solo en el servidor Sun_SSH, parece algún tipo de problema no documentado. Estoy buscando una buena solución.
Respuesta1
Respondiendo a mi propia pregunta: este es un problema conocido con Sun SSH. La mejor solución que encontré es detectar "Sun_SSH" en la salida ssh -V
y aplicar algo como esto:
#!/bin/bash
# ....
( ssh host 'localCommand' | remoteCommand || pkill -P $BASHPID )
También puede usarlo $$
en lugar de $BASHPID
en otros shells o en situaciones más simples (si su shell no tiene otros procesos secundarios).