From: Francis Cianfrocca <garbagecat10@...>
Date: 2007-05-29T01:18:41+09:00
Subject: Re: Killing sons (Linux)

------=_Part_48201_8434506.1180369089182
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 5/28/07, Ohad Lutzky <lutzky@gmail.com> wrote:
>
>  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.



With signals, nothing is ever "guaranteed."

Why are you using signal 9 instead of something more system-friendly? 9
should be your last resort when all else fails, because it doesn't give your
processes a chance to exit cleanly.

I have the uncomfortable feeling that your code is working by accident,
because the subprocesses which the "system" call creates aren't explicitly
added to the process group of the fork child. If you run this program in a
shell, it will probably work, because of the process-group semantics defined
by most shells. However, if you run it as a headless daemon or from a cron
job, it may not work. Try it and see.

When I have to do what you're trying to do, I usually avoid calling system.
Instead I call fork, and in the child I call setpgid(0, getppid()), and then
exec.

------=_Part_48201_8434506.1180369089182--