views:

879

answers:

4

I have a program running on a remote machine which expects to receive SIGINT from the parent. That program needs to receive that signal to function correctly. Unfortunately, if I run that process remotely over SSH and send SIGINT, the ssh process itself traps and interrupts rather than forwarding the signal.

Here's an example of this behavior using GDB:

Running locally:

$ gdb
GNU gdb 6.3.50-20050815 (Apple version gdb-1344) (Fri Jul  3 01:19:56 UTC 2009)
...
This GDB was configured as "x86_64-apple-darwin".
^C
(gdb) Quit
^C
(gdb) Quit
^C
(gdb) Quit

Running remotely:

$ ssh foo.bar.com gdb
GNU gdb Red Hat Linux (6.3.0.0-1.159.el4rh)
...
This GDB was configured as "i386-redhat-linux-gnu".
(gdb) ^C
Killed by signal 2.
$

Can anybody suggest a way of working around this problem? The local ssh client is OpenSSH_5.2p1.

Thanks.

A: 

Can you run a terminal on the remote machine and use kill -INT to send it the signal?

Carl Norum
A: 

Try signal SIGINT at the gdb prompt.

Martin v. Löwis
In my case the remote program is not GDB - I'm just using that example to illustrate the behavior. Sorry that was not clear. (The actual remote process is a server playing chess over standard IO.)Thanks.
Matt
A: 

It looks like you're doing ctrl+c. The problem is that your terminal window is sending SIGINT to the ssh process running locally, not to the process on the remote system.

You'll have to specify a signal manually using the kill command or system call on the remote system.

or more conveniently using killall

$killall -INT gdb
Mike
Unfortunately, the behavior is the same whether I write a ^C to the terminal or I send SIGINT to the ssh process using kill.
Matt
You have to send SIGINT to the process you want to receive it, not your ssh session.
Carl Norum
+4  A: 
$ ssh -t foo.bar.com gdb
...
(gdb) ^C
Quit
ephemient
Perfect. That's it.Thanks.
Matt