Perché il mio processo remoto viene ancora eseguito dopo aver ucciso una sessione ssh?

Sto eseguendo la coda di un file di registro remoto eseguendo questo comando in una shell locale:

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

Quando ctrl-c fuori da questo comando, sembra che ctrl-c uccida il processo ssh locale e lasci la coda in esecuzione sul computer remoto. Avevo l'impressione che l'interruzione della connessione avrebbe inviato un segnale di blocco (poiché non sto usando Nohup) e avrebbe ucciso il processo, ma chiaramente non è così.

Qualcuno può fare luce in più quando vengono inviati segnali di riaggancio e quando non lo sono? La macchina remota è Ubuntu e la mia shell locale è OS X bash se una di queste fa la differenza.

Questo comportamento deriva dalla mancanza di un terminale di controllo per il processo in esecuzione. Quando il processo remoto non ha un terminale di controllo, il processo ssh remoto che gestisce la sessione non è in grado di uccidere il comando, che viene lasciato sospeso in uno stato di zombi per essere infine ripulito da init.

Puoi aggirare questo eseguendolo con un'opzione -t, che gli fornisce un terminale di controllo. Ciò comporterà il termine del processo quando si preme il comando ssh in remoto.

L' opzione -t :

Forza l'allocazione pseudo-tty. Questo può essere usato per eseguire programmi arbitrari basati su schermo su una macchina remota, il che può essere molto utile, ad esempio quando si implementano servizi di menu. Le opzioni multiple -t impongono l'allocazione di tty, anche se ssh non ha tty locale.

Dai un'occhiata a man ssh e man sshd quando usi questa opzione poiché ci sono altre implicazioni nell'avere un terminale di controllo, ad esempio la possibilità di inviare caratteri di escape.