
Chasing missing SIGINT signals down the SSH rabbit hole - craigkerstiens
https://gravitational.com/blog/ssh-client-signal-handling/
======
kccqzy
I've gradually learned to almost always allocate a PTY, whether it be ssh or
some docker run. Too many programs work badly or unexpectedly differently when
fd 0 or 1 is not a terminal. Maybe we should start collecting a hall of shame
for programs that insist on dealing with a terminal, not just a pipe.

Another fun fact I just came across a few weeks ago. The sudo command doesn't
always handle job control signals in the way you expect it to. From its
manual:

> There are two distinct ways sudo can run a command. If an I/O logging plugin
> is configured or if the security policy explicitly requests it, a new
> pseudo-terminal (“pty”) is allocated and fork(2) is used to create a second
> sudo process, referred to as the monitor. The monitor creates a new terminal
> session with itself as the leader and the pty as its controlling terminal,
> calls fork(2), sets up the execution environment as described above, and
> then uses the execve(2) system call to run the command in the child process.
> The monitor exists to relay job control signals between the user's existing
> terminal and the pty the command is being run in. This makes it possible to
> suspend and resume the command. Without the monitor, the command would be in
> what POSIX terms an “orphaned process group” and it would not receive any
> job control signals from the kernel.

~~~
d0mine
The signal handling behavior may differ between versions e.g.,
[https://stackoverflow.com/questions/34337840/cant-
terminate-...](https://stackoverflow.com/questions/34337840/cant-terminate-a-
sudo-process-created-with-python-in-ubuntu-15-10)

------
godelmachine
I took SIGINT for Signal Intelligence

~~~
dboreham
Me too, since I date back to before signals had symbolic names.

------
jxy
It's not anybody's fault. Everything is working exactly as it is supposed to
do. Except for the leaky abstraction of a "pty".

I wish there would be a better world than people constantly fighting for their
terminal, TERM, terminfo, termcap, curses, tty, ...

------
russjones
Author here, happy to answer any questions about the post.

~~~
yayana
Is the double meaning of the headline intentional? I was expecting a timing or
other attack to determine data has a particular origin..

~~~
wyldfire
No it's [probably] not. SIGINT is unfortunately ambiguous, unlike SIGKILL,
SIGTERM, SIGQUIT, SIGUSR1. :)

~~~
derefr
I'd have suggested "missing Ctrl+C" instead (like the title of the bug
report.)

~~~
c12
As far as I know SIGINT is the name of the signal and Ctrl+C is simply a key
combination that triggers it.

I read the title to mean SIGINT the signal and it wasn't until I came to HN
comments did I see have another meaning.

------
Drdrdrq
I created an ssh terminal over browser back in the day (kind of like ajaxterm,
but proprietary). I tried at least 4 different libraries over the years, but
there would always be that one special device that refused to play ball. In
the end I used an OpenSSH process, connected to it and drove it through
input/output. Made those customer support calls really short: "Did you try
connecting from the command line?"

------
jiveturkey
deja vu. I remember having to dig into this behavior 10 years ago (maybe a tad
more).

Completely disagree with Teleport's fix and methodology. Sending remote
SIGKILL because you got a local SIGINT? horrible for the general case. Now if
Teleport performs specific functions for a specific controlled environment,
then it might be fine and provide certain guarantees. But AFAICT teleport is a
fronted to generic functionality.

------
JdeBP
This is a fairly reasonable explanation, that is somewhat marred by two
things.

First, the suggestion to demonstrate non-canonical input mode with the stty
command will not work for many people. Many shells that have command-line
editing save and restore the termios settings before and after reading each
line of interactive input. Run stty raw and stty sane from the Z shell, for
example, and nothing at all will apparently change when typing input to ZLE.
The same goes for the Bourne Again shell and Readline.

Second, it keeps talking about a "local PTY device". The local end has a
terminal, but that is not necessarily a _pseudo_ terminal. It could be a real
terminal, or a kernel virtual terminal.

