parallel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: how does gnu parallel handle SIGINT/SIGQUIT?


From: Ole Tange
Subject: Re: how does gnu parallel handle SIGINT/SIGQUIT?
Date: Thu, 9 Apr 2015 00:06:23 +0200

On Tue, Apr 7, 2015 at 6:03 PM, Martin d'Anjou
<martin.danjou14@gmail.com> wrote:

> GNU Parallel "wraps" the execution of other programs, just like shells
> do. I'd like to understand how exactly GNU Parallel behaves itself
> when it gets SIGINT/SIGQUIT. The reason I ask is because I have a
> program that performs special actions on SIGINT (a bit like emacs does
> but not quite).

When pressing CTRL-C the shell sends SIGINT to all child processes in
the foreground. So GNU Parallel cannot intercept these, but exits
instead. You can see that with:

parallel -uq perl -e '$SIG{INT}=sub {print "Got INT\n"};sleep 1000' ::: 1
<CTRL-C>
Got INT

Things get a bit more tricky when running remotely.

parallel -S server -uq perl -e 'open(A,">","/tmp/ged");$SIG{INT}=sub
{print A "Got INT\n"};sleep 1000' ::: 1
<CTRL-C>
ssh server cat /tmp/ged
<nothing>

But:

parallel -S server -uq perl -e 'open(A,">","/tmp/ged");$SIG{HUP}=sub
{print A "Got HUP\n"};sleep 1000' ::: 1
<CTRL-C>
ssh server cat /tmp/ged
Got HUP

The reason for this weirdness is described in 'man parallel_design'
under "Remote Ctrl-C and standard error (stderr)".

Nothing has been done to deal with SIGQUIT: It is not intercepted in
any way. On my system it dumps core.


/Ole



reply via email to

[Prev in Thread] Current Thread [Next in Thread]