Prev: waitpid == -1 and errno == ECHILD
Next: Joy of C source code
From: junky_fellow on 3 Dec 2009 23:57
On Dec 4, 3:20 am, Kenneth Brody <kenbr...(a)spamcop.net> wrote:
> Jens Thoms Toerring wrote:
> > junky_fel...(a)yahoo.co.in <junky_fel...(a)yahoo.co.in> wrote:
> >>   I am writing an application where the parent (daemon) forks few
> >> child processes.
> >> My requirement is that when the parent process exits/killed/crashed,
> >> all its child processes should also exit. Can someone suggest some way
> >> of doing it.
> >> Problematic scenario is the one where the parent crashed or killed
> >> (SIGKILL) and desn't get any chance for cleanup.
>
> > Since the child processes aren't informed about the death of
> > their parent you need to do a bit of extra work. One way to
> > do it would to regularly try to do
>
> > if ( kill( getppid, 0 ) != 0 && errno == ESRCH )
> >    /* Parent process is probably dead */
>
> > But there's a slight chance that the PID of the dead parent
> > process has already been assigned to another, completely un-
> > related process in between. To avoid that you could create a
> > pipe in the parent and pass the write end to the child pro-
> > cesses. Now the child processes write (just a single byte)
> > to the pipe from time to time. If that results in a SIGPIPE
> > signal (or, if SIGPIPE is blocked, write() returns with an
> > error and errno is set to EPIPE) then the parent is dead.
> > Of course, you then also need e.g. a thread in the parent
> > that reads from the pipe from time to time (and throws away
> > what it read) to avoid it becoming full.
>
> Why bother actually writing/reading?  Wouldn't it suffice to select() on the
> pipe within the child, to test whether the other side has been closed or not?
>
Thanks Brody and everyone else. I like this idea of using a select on
the pipe and socket. Hope this should solve the problem.

From: Rainer Weikusat on 4 Dec 2009 06:03
Kenneth Brody <kenbrody(a)spamcop.net> writes:
> Jens Thoms Toerring wrote:
>> junky_fellow(a)yahoo.co.in <junky_fellow(a)yahoo.co.in> wrote:
>>> I am writing an application where the parent (daemon) forks few
>>> child processes.
>>> My requirement is that when the parent process exits/killed/crashed,
>>> all its child processes should also exit. Can someone suggest some way
>>> of doing it.
>>> Problematic scenario is the one where the parent crashed or killed
>>> (SIGKILL) and desn't get any chance for cleanup.
>>
>> Since the child processes aren't informed about the death of
>> their parent you need to do a bit of extra work. One way to
>> do it would to regularly try to do
>>
>> if ( kill( getppid, 0 ) != 0 && errno == ESRCH )
>> /* Parent process is probably dead */
>>
>> But there's a slight chance that the PID of the dead parent
>> process has already been assigned to another, completely un-
>> related process in between. To avoid that you could create a
>> pipe in the parent and pass the write end to the child pro-
>> cesses. Now the child processes write (just a single byte)
>> to the pipe from time to time. If that results in a SIGPIPE
>> signal (or, if SIGPIPE is blocked, write() returns with an
>> error and errno is set to EPIPE) then the parent is dead.
>> Of course, you then also need e.g. a thread in the parent
>> that reads from the pipe from time to time (and throws away
>> what it read) to avoid it becoming full.
>
> Why bother actually writing/reading? Wouldn't it suffice to select()
> on the pipe within the child, to test whether the other side has been
> closed or not?

As long as there aren't multiple descriptors involved (as in
simplified examples), there is not reason to use I/O-multiplexing
routines.
From: Geoff Clare on 4 Dec 2009 08:30
Ralf Fassel wrote:

> On my Opensuse 11.1, getppid() returns 1 (== init) when the parent has
> exited, which could be used as an indicator "parent has gone". The
> manpage says nothing about that scenario so I don't know how portable
> that would be.

POSIX says that when a process terminates:

The parent process ID of all of the existing child processes and
zombie processes of the calling process shall be set to the
process ID of an implementation-defined system process. That is,
these processes shall be inherited by a special system process.

(This is from the description of _exit() which is why it says "calling
process", but the same applies to all forms of termination.)

Traditionally the "special system process" is init, and has PID 1, but
a different PID could be used on non-traditional systems. This makes
parent death harder to detect because, as someone pointed out elsewhere
in the thread, if you repeatedly call getppid() checking whether the
return value has changed there is a chance that the parent has already
died before your first call to getppid(). This problem can be avoided
by having the parent pass its PID to the child.

--
Geoff Clare <netnews(a)gclare.org.uk>

From: Chris Friesen on 4 Dec 2009 13:08
On 12/03/2009 05:16 PM, David Schwartz wrote:
> On Dec 3, 2:57 pm, Chris Friesen <cbf...(a)mail.usask.ca> wrote:
>
>>> No. In fact, it seems fundamentally broken to me. Why do you think you
>>> need/want to do this?
>
>> I can think of some scenarios. Imagine a case where the parent forks
>> off a bunch of child processes to do some work, expecting to get the
>> results back via return codes, pipes, or something else.
>
>> If the parent dies for whatever reason, it would make sense to kill the
>> child processes because any work they do won't be seen by anyone anymore.
>
> Why couldn't they be seen by the parent's parent?

The tasks would be seen, but the results of the work they do may not be
understood by the parent's parent. In that case we may as well arrange
for the kids to die as well since they're effectively doing work for no
purpose.

Chris
From: Rainer Weikusat on 4 Dec 2009 13:21
Geoff Clare <geoff(a)clare.See-My-Signature.invalid> writes:
> Ralf Fassel wrote:
>> On my Opensuse 11.1, getppid() returns 1 (== init) when the parent has
>> exited, which could be used as an indicator "parent has gone". The
>> manpage says nothing about that scenario so I don't know how portable
>> that would be.
>
> POSIX says that when a process terminates:
>
> The parent process ID of all of the existing child processes and
> zombie processes of the calling process shall be set to the
> process ID of an implementation-defined system process. That is,
> these processes shall be inherited by a special system process.
>
> (This is from the description of _exit() which is why it says "calling
> process", but the same applies to all forms of termination.)
>
> Traditionally the "special system process" is init, and has PID 1, but
> a different PID could be used on non-traditional systems. This makes
> parent death harder to detect because, as someone pointed out elsewhere
> in the thread, if you repeatedly call getppid() checking whether the
> return value has changed there is a chance that the parent has already
> died before your first call to getppid(). This problem can be avoided
> by having the parent pass its PID to the child.

Since this is already in the realm of theory: The 'special system
process' could have the same process ID as the original parent
process (at least insofar the quoted text is concerned).

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: waitpid == -1 and errno == ECHILD
Next: Joy of C source code