Re:Chasing missing SIGINT signals down the SSH rabbit hole
by kccqzy on Thursday May 24, 2018 @05:03PM
(#17148388)
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.
Re:Chasing missing SIGINT signals down the SSH rabbit hole
by Drdrdrq on Thursday May 24, 2018 @04:15PM
(#17147923)
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?"
Re:Chasing missing SIGINT signals down the SSH rabbit hole
by jiveturkey on Thursday May 24, 2018 @06:30PM
(#17149067)
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.
Re:Chasing missing SIGINT signals down the SSH rabbit hole
by JdeBP on Friday May 25, 2018 @10:04AM
(#17153791)
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.
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.
I wish there would be a better world than people constantly fighting for their terminal, TERM, terminfo, termcap, curses, tty, ...
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.
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.
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.