Why does my remote process still run after killing an ssh session?

Question

I'm tailing a remote logfile by running this command in a local shell:

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

When I ctrl-c out of this command, it seems that the ctrl-c kills the local ssh process and leaves my tail running on the remote machine. I was under the impression that breaking the connection would send a hangup signal (since I am not using nohup) and kill the process, but that is clearly not the case.

Can anybody shed some more light on when hangup signals are sent and when they are not? Remote machine is Ubuntu, and my local shell is OS X bash if either of those make a difference.

Answer 1

This behaviour stems from the lack of a controlling terminal for the running process. When the remote process does not have a controlling terminal, the remote ssh process handling your session is unable to kill the command, which is left hanging in a zombie state to be eventually cleaned up by init.

You can get around this by running it with a -t option, which gives it a controlling terminal. This will cause the process to terminate when you ctrl-c your ssh command remotely.

The -t option:

Force pseudo-tty allocation. This can be used to execute arbitrary screen-based programs on a remote machine, which can be very useful, e.g. when implementing menu services. Multiple -t options force tty allocation, even if ssh has no local tty.

Have a look at man ssh and man sshd when you use this option as there are other implications of having a controlling terminal, e.g. the ability to send escape characters.