Pourquoi mon processus distant s'exécute-t-il toujours après avoir tué une session ssh?

Je suis un fichier journal distant en exécutant cette commande dans un shell local:

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

Quand je ctrl-c sur cette commande, il semble que le ctrl-c tue le processus ssh local et laisse ma queue tourner sur la machine distante. J'avais l'impression que rompre la connexion enverrait un signal de raccrochage (puisque je n'utilise pas de nohup) et tuerait le processus, mais ce n'est clairement pas le cas.

Quelqu'un peut-il nous éclairer davantage lorsque des signaux de raccrochage sont envoyés et quand ils ne le sont pas? La machine distante est Ubuntu, et mon shell local est OS X bash si l'un ou l'autre fait la différence.

Ce comportement provient de l'absence d'un terminal de contrôle pour le processus en cours d'exécution. Lorsque le processus distant n'a pas de terminal de contrôle, le processus ssh distant qui gère votre session n'est pas en mesure de tuer la commande, qui reste suspendue dans un état zombie pour être finalement nettoyée par init.

Vous pouvez contourner cela en l'exécutant avec une option -t, ce qui lui donne un terminal de contrôle. Cela entraînera la fin du processus lorsque vous ctrl-c votre commande ssh à distance.

L' option -t :

Forcer l'allocation de pseudo-tty. Ceci peut être utilisé pour exécuter des programmes arbitraires sur écran sur une machine distante, ce qui peut être très utile, par exemple lors de la mise en œuvre de services de menu. Plusieurs options -t forcent l'allocation de tty, même si ssh n'a pas de tty local.

Jetez un œil à man ssh et man sshd lorsque vous utilisez cette option car il y a d'autres implications d'avoir un terminal de contrôle, par exemple la possibilité d'envoyer des caractères d'échappement.