On Wed, May 30, 2012 at 4:15 AM, Nameless Numerologist <[email protected]> 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
