0

When I run this:

echo '
from signal import *; signal(SIGINT, lambda *_: sys.exit(0));  # Does not work
from socket import *; socket(AF_INET, SOCK_DGRAM).recvfrom(0);
' | ssh host -- python -

pressing Ctrl+C causes SSH to quit without terminating Python.

How can I property get Python to terminate on Ctrl+C?

user541686
  • 205,094
  • 128
  • 528
  • 886
  • Try adding a `-t` option to `ssh`. – Mark Plotnick Oct 31 '19 at 10:58
  • @MarkPlotnick: `Pseudo-terminal will not be allocated because stdin is not a terminal.` – user541686 Oct 31 '19 at 11:02
  • Can you try `-tt` ? – Mark Plotnick Oct 31 '19 at 11:15
  • @MarkPlotnick: Wow, yeah, that works, thanks! So this is an SSH issue rather than a Python issue? Any chance you could explain why it's happening? – user541686 Oct 31 '19 at 11:29
  • Briefly, `ssh host command` doesn't allocate a tty, so typing Ctrl-C sends a signal and kills it. `ssh host` or `ssh -t host command` or `ssh -tt host command` does set up a tty, and typing Ctrl-C sends Ctrl-C to the remote side, where it does whatever it usually does (typically, kill the remote process). – Mark Plotnick Oct 31 '19 at 11:37
  • The answers here explain things, I think. https://stackoverflow.com/questions/7114990/pseudo-terminal-will-not-be-allocated-because-stdin-is-not-a-terminal – Mark Plotnick Oct 31 '19 at 11:38
  • @MarkPlotnick: It can't be Ctrl+C itself that's significant though, right? Because it dies even if I kill the ssh process directly? So somehow the remote side *knows* to kill the process even without Ctrl+C if a TTY is allocated, but it doesn't "know" that if not? Which makes me wonder -- who is doing the killing here, if not sshd? – user541686 Oct 31 '19 at 11:41
  • When you "kill the ssh process directly", what steps are you taking? – Mark Plotnick Oct 31 '19 at 11:56
  • @Mark: killing ssh.exe in Task Manager? – user541686 Oct 31 '19 at 15:47
  • I don't know what happens under Windows specifically. But on Unix/Linux, if you kill a process that has a TCP connection open, it closes just one end of the connection. The process(es) on the other end will continue happily running, even for hours or days, until they try to read from or write to the TCP connection, at which time the OS will give them an I/O error and the programs will usually decide to exit on their own. – Mark Plotnick Oct 31 '19 at 20:47
  • @MarkPlotnick: Hm, interesting. So to clarify, you can repro what I'm doing on Linux as follows: run `ssh -t host sleep 120`, then kill it with `SIGKILL`. Log into the host again and notice that `sleep` is no longer running. Now repeat the same thing, but without `-t`. You'll see that `sleep` is still running. For your explanation to work, it means that when a TTY is allocated, the server-side SSH is trying to read the TCP socket from the client, and then receives an I/O error, whereas when a TTY is allocated, it doesn't do that. I guess that would explain it -- is that correct? – user541686 Oct 31 '19 at 21:03
  • I will test out several scenarios and write up the results when I have access to a Linux system. Probably Monday. – Mark Plotnick Nov 01 '19 at 22:18
  • No rush! I was only trying out the tool, I don't need it for anything in particular. :) – user541686 Nov 01 '19 at 22:24

0 Answers0