Prev: waitpid == -1 and errno == ECHILD
Next: Joy of C source code
From: Chris Friesen on 3 Dec 2009 14:22
On 12/03/2009 10:47 AM, junky_fellow(a)yahoo.co.in wrote:
> On Dec 3, 8:43 pm, David Schwartz <dav...(a)webmaster.com> wrote:
>> On Dec 3, 5:56 am, Ralf Fassel <ralf...(a)gmx.de> 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.
>>
>> You can call 'getppid' on startup and check if it changes or is
>> equivalent to one. I guess this creates a narrow window in which your
>> parent could die, you could get reparented to something other than
>> init, and then you call getppid the first time.
>
> Guys, thanks a lot for your suggestions.
> However, all the solutions suggested require regular polling, which I
> want to avoid. Is there any way, where I can do this without polling?
> Isn't this a very common requirement ?

We had a similar requirement to enable a "supervisor" monitoring process
to keep track of a bunch of unrelated app processes. We ended up
writing some custom code in the kernel to allow a process to be sent an
arbitrary signal when any of a customizable set of events happened to an
arbitrary list of tasks.

If you did something like this the kids could request to be sent a
SIGTERM (or some other signal) when the parent dies.

Chris
From: Kenneth Brody on 3 Dec 2009 17:20
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?

--
Kenneth Brody
From: David Schwartz on 3 Dec 2009 17:24
On Dec 3, 8:47 am, "junky_fel...(a)yahoo.co.in"
<junky_fel...(a)yahoo.co.in> wrote:

> Isn't this a very common requirement ?

No. In fact, it seems fundamentally broken to me. Why do you think you
need/want to do this?

DS
From: Chris Friesen on 3 Dec 2009 17:57
On 12/03/2009 04:24 PM, David Schwartz wrote:
> On Dec 3, 8:47 am, "junky_fel...(a)yahoo.co.in"
> <junky_fel...(a)yahoo.co.in> wrote:
>
>> Isn't this a very common requirement ?
>
> 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.

Chris
From: David Schwartz on 3 Dec 2009 18:16
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?

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