parallel
[Top][All Lists]
Advanced

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

Re: How to disable SIGTERM


From: Martin d'Anjou
Subject: Re: How to disable SIGTERM
Date: Thu, 09 Apr 2015 23:23:19 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0

On 15-04-08 05:47 PM, Ole Tange wrote:
On Tue, Apr 7, 2015 at 6:06 PM, Martin d'Anjou
<martin.danjou14@gmail.com> wrote:

GNU Parallel intercepts SIGTERM. The program I call needs to receive
SIGTERM. How do I disable SIGTERM's interception by GNU Parallel?
SIGTERM signals GNU Parallel to stop spawning more jobs and wait for
running jobs to complete.

If you send SIGTERM twice GNU Parallel will exit immediately.

If this is not what you want, you most likely need to make a wrapper
that saves $$ to you in a file:

     parallel 'echo $$ > {%};sleep {}'  ::: {90000..90009}

If the reason for getting the pid is to kill run-amok processes,
consider looking at --timeout and --memfree. The both send TERM, TERM,
KILL to child processes.


/Ole

Ole,

I decided to work on this problem, to see if and how I could add an option to propagate the TERM signal, because I do not want to have to manage this eternally.

I am posting my work on github, you can see the changes I have made so far:
https://github.com/martinda/gnu-parallel/tree/sigterm-1

Right now I have added debug statements and other modifications for debugging purposes, those will be removed if this work is conclusive.

I decided to do a test driven development. I wrote the tests first, now I am working on the code.

I do not understand how to integrate the test in the Makefile yet, so I run it like this from the top directory of the git repo: PATH=~/git/parallel/src:$PATH testsuite/tests-to-run/parallel-local-signals.sh

One interesting finding, is that job->kill("TERM") sends HUP, not TERM... looks like this line sets send_signals to 1 (one):
my @send_signals = @signals || ("TERM", "TERM", "KILL");

When I fix it, TERM is sent, but to the wrong process IDs. I will continue to work on this tomorrow and see where I can take it.

Feel free to share your thoughts.

Regards,
Martin




reply via email to

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