7

I need to send a SIGINT to the remote process running in foreground in an SSH session.

The SSH session is already established, so I cannot use option of starting it with (as described in How to send SIGINT to a remote process over SSH?) 

ssh -t user@host

I know I could open a second ssh session and kill the process or close the current ssh session, but I want to avoid that and do it directly throw the current session (if this is possible).

Manuel Schmidt
  • 2,178
  • 2
  • 15
  • 19
  • The short answer is that you cannot without an allocated terminal (pty/tty) because capturing a key-sequence and converting it to a signal is the job of the terminal. If maintaining a single socket session is what you're trying to achieve then you can use shared sessions. Where multiple ssh connections occur over the same socket. If you're clever about the sequence in which you start your shared sessions, then terminating the primary session will kill the secondary sessions. – Ahmed Masud Jun 04 '17 at 13:26
  • Stack Overflow is a site for programming and development questions. This question appears to be off-topic because it is not about programming or development. See [What topics can I ask about here](http://stackoverflow.com/help/on-topic) in the Help Center. Perhaps [Super User](http://superuser.com/) or [Unix & Linux Stack Exchange](http://unix.stackexchange.com/) would be a better place to ask. Also see [Where do I post questions about Dev Ops?](http://meta.stackexchange.com/q/134306) – jww Jun 04 '17 at 14:33

2 Answers2

8

If you use ssh to start a process without a PTY on a remote system, then as far as I can tell, there's no way to signal the remote process through that ssh session.

The SSH protocol has a message to send a signal to the remote process. However, you're probably using OpenSSH for either the client or the server or both, and OpenSSH doesn't implement the signal message. So the OpenSSH client can't send the message, and the OpenSSH server won't act on it.

There is an SSH extension to send a "break" message which is supported by OpenSSH. In an interactive session, the OpenSSH client has an escape sequence that you can type to send a break to the server. The OpenSSH server handles break messages by sending a break to the PTY for the remote session, and unix PTYs will normally treat a break as a SIGINT. However, breaks are fundamentally a TTY concept, and none of this will work for remote sessions which don't have a PTY.

Community
  • 1
  • 1
Kenster
  • 23,465
  • 21
  • 80
  • 106
  • 2
    Hot off of the presses: There's a bug report to add "signal" message support to OpenSSH and according to reports (which I have not verified), OpenSSH 7.9 (released Oct 2018) and onwards supports receiving signals (though not sending from the client, that may require additional implementation) https://bugzilla.mindrot.org/show_bug.cgi?id=1424 – Guss Dec 13 '18 at 15:30
1

Short answer:

ssh -t fs "stty isig intr ^N -echoctl ; trap '/bin/true' SIGINT; sleep 1000; echo f" > foo

and stop the program by CTRL+N.

Long explanation:

1.You must use stty option intr to change your server or local interrupt character to not collide with each other.In the command above I've changed the server interrupt character to CTRL+N. You can change your local interrupt character and leave the server's one without any changes.

2.If you don't want the interrupt character to be in your output (and any other control character) use stty -echoctl.

3.You must assure that control characters are switched on on the server bash invoked by sshd . If you don't you can end up with processes still hanging around after you logout. stty isig

4.You actually catch SIGINT signal by trap '/bin/true' SIGINT with empty statement. Without the trap you will not have any stdout after SIGINT signal on your end.

But without -t option that cannot be quit with a signal to the process that runs over the terminal.

Harini
  • 551
  • 5
  • 18