[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Revision of GNU Parallel's processing of SIGTERM
From: |
Ole Tange |
Subject: |
Re: Revision of GNU Parallel's processing of SIGTERM |
Date: |
Mon, 13 Apr 2015 21:46:02 +0200 |
On Mon, Apr 13, 2015 at 3:44 PM, Martin d'Anjou
<martin.danjou14@gmail.com> wrote:
> On 15-04-12 07:14 AM, Ole Tange wrote:
:
> I propose two solutions:
> - Change the code to only kill the parent process (existing users will have
> to change their application code to kill children processes themselves)
> - Do not change the default behaviour, but add an option so that only the
> parent job is killed (existing users see no change)
The more I think about it the more I like the:
'kill TERM', wait, 'kill TERM', wait, 'kill KILL', 'kill KILL
@grandchildren_pid'
When will that fail?
GNU Parallel by design tries to do The Right Thing and not assume the
world is perfect. In a perfect world the parent will kill its
children. But if the parent is crappy code (which might be proprietary
or impossible to fix for other reasons), then the parent might not do
so. And would it then not be The Right Thing to kill -9 the
(grand*)children after we kill -9 the parent?
The only situation I can think of where this behaviour is wrong, is in
the weird situation where the parent wants the children to live on,
without explicitly daemonizing the child. And I cannot come up with a
real life scenario where that will ever happen. Can you?
/Ole
PS: I just realized that humans have very different life cycles and
wishes for their children than parents and children UNIX-processes:
humans rarely go around and kill their children or daemonize them.