Re: ctrl-c gnu parallel and sshlogin

[Ole Tange]

On Wed, May 30, 2012 at 4:15 AM, Nameless Numerologist
<thenamelessnumerologist@gmail.com> wrote:

>   Wonderful software.  GNU parallel is busy changing my life these days.

Happy you like it. I hope it changes your life for the better.

>   I was wondering if I'm missing some obvious flag when it comes to the
> persistence of sshlogin jobs following ctrl-c.

Yeah, the CTRL-C bothered me, too. A couple of years ago I tried
solving it, but failed. I seem to remember the problem boils down to
this:

CTRL-C sends SIGINT (signal 2). You can catch SIGINT (which is a
pre-requisite for doing anything useful with it). But SIGINT is also
sent to all your children, and you cannot block this from happening.

>   Use case: start a bunch of jobs, notice an issue, kill the jobs.
>   Current result: start a bunch of jobs, notice an issue, issue ctrl-c at
> the gnu parallel terminal killing gnu parallel and ssh processes, bash shell
> and jobs are still running remotely.
>   I can demonstrate the issue with the two cases below:
>
>   Case 1:
>   parallel -S localhost sleep ::: 100 100
>   ctrl-c
>   pgrep -fl sleep
>
>   Compare to Case 2:
>   parallel -S : sleep ::: 100 100
>   ctrl-c
>   pgrep -fl sleep

As you clearly are aware GNU Parallel treat ':' very different from
'localhost'. ':' will simply get a fork (technically an open3()),
whereas 'localhost' will get a fork that starts ssh.

So when SIGINT is sent to all children, it does The Right Thing on ':'
since the jobs are direct children of parallel. But when dealing with
'localhost' the signal needs to travel through the SSH connection. It
seems that is not what is happening: SSH shuts down but does not send
SIGINT to its children in the other end.

The problem can be illustrated by:

  ssh localhost sleep 9999 &
  kill -2 $! # This kills the ssh but not the sleep (not what we want)

  sleep 9999 &
  kill -2 $! # This kills the sleep (what we want)

It seems 'ssh -t' can forward the SIGINT but will pollute STDERR with:

  Pseudo-terminal will not be allocated because stdin is not a terminal.

Also I am not sure how new '-t' is in ssh - as you probably know
backwards compatibility is important.

It would be a help if:

* You can find out when '-t' was introduced in ssh or a way to test if
'-t' works. I am not sure if both server and client must support it.
* You can find a way to disable the pollution of STDERR

A workaround for now is:

  parallel -S 'ssh -t localhost' sleep ::: 100 100


/Ole
-- 
https://www.gnu.org/software/parallel/merchandise.html
¿ǝsıpuɐɥɔɹǝɯ lǝllɐɹɐd ∩N⅁ ɹnoʎ pǝɹǝpɹo noʎ ǝʌɐH