From: Ohad Lutzky <lutzky@...>
Date: 2007-05-29T00:19:45+09:00
Subject: Re: Killing sons (Linux)

Francis Cianfrocca wrote:
> On 5/28/07, Ohad Lutzky <lutzky@gmail.com> wrote:
>>
>>
>> Now, my system also allows a 'kill' command, intended to stop the job in
>> progress. This has been causing me a lot of trouble, and I suddenly
>> (after quite a while the system has been in production, how embarassing)
>> realized why - the PID I'm keeping is of the daemon fork. Killing it
>> doesn't kill all of its sons - it causes bash to get reparented to init!
>>
>> Any idea of a clean, quick way to fix this?
> 
> 
> 
> Make your parent process the leader of its own process group with
> setpgid(0,0). When you fork, add each child to the parent's process 
> group
> with setpgid(0, getppid()). If you fork subchildren, make sure they get
> added to the same process group. Now, to send a signal to the whole 
> group,
> send it to (0 - pid), where pid is that of the parent. If you want them 
> all
> to die without killing the leader, use a signal whose default behavior 
> is
> terminate-process and ignore it in the parent.

Just to be sure - if I run the following Ruby code on a Linux system:

  child = fork do
    Process::setpgid 0,0
    system 'bash -c "sleep 300"'
  end
  Process::kill 9, -child

Then I am guaranteed that no child bash, sleep or ruby process will 
remain? It works, I just want to be sure I can count on that behaviour. 
For contrast, in my original code, bash gets reparented to init:

  child = fork do
    system 'bash -c "sleep 300"'
  end
  Process::kill 9, child

And this code doesn't even work (ESRCH: No such process)

  child = fork do
    system 'bash -c "sleep 300"'
  end
  Process::kill 9, -child

Thank you for your help!

-- 
Posted via http://www.ruby-forum.com/.