¿Por qué mi proceso remoto todavía se ejecuta después de matar una sesión ssh?

Estoy siguiendo un archivo de registro remoto ejecutando este comando en un shell local:

ssh remotemachine tail -100f /path/to/error_file

Cuando ctrl-c sale de este comando, parece que ctrl-c mata el proceso ssh local y deja mi cola corriendo en la máquina remota. Tenía la impresión de que romper la conexión enviaría una señal de bloqueo (ya que no estoy usando nohup) y mataría el proceso, pero claramente ese no es el caso.

¿Alguien puede arrojar algo más de luz cuando se envían señales de suspensión y cuando no se envían? La máquina remota es Ubuntu, y mi shell local es OS X bash si alguno de los dos marca la diferencia.

Este comportamiento proviene de la falta de un terminal de control para el proceso en ejecución. Cuando el proceso remoto no tiene una terminal de control, el proceso ssh remoto que maneja su sesión no puede matar el comando, que queda colgado en un estado zombie para que eventualmente lo limpie init.

Puede evitar esto ejecutándolo con una opción -t, que le da un terminal de control. Esto hará que el proceso finalice cuando ctrl-c su comando ssh de forma remota.

La opción -t :

Forzar asignación de pseudo-tty. Esto se puede usar para ejecutar programas arbitrarios basados ​​en pantalla en una máquina remota, lo que puede ser muy útil, por ejemplo, al implementar servicios de menú. Varias opciones -t fuerzan la asignación de tty, incluso si ssh no tiene tty local.

Eche un vistazo a man ssh y man sshd cuando use esta opción, ya que existen otras implicaciones de tener un terminal de control, por ejemplo, la capacidad de enviar caracteres de escape.