I've got some other developers wanting some way for a process to be notified on
the death of another process. Now I understand that if all the processes are
forked by a main one, then the main one will get a SIGCHILD on the death of the
other processes.
The problem with this is that if the main one dies, then all the other ones get
reparented to init. I would like some way for the main one to restart, read the
list of pids out of a file that it conveniently stashed away, and reparent the
pids back to itself (the same way that they were reparented to init in the first
place) so that it gets SIGCHILD when they die.
Once I have this ability, then it becomes simple for arbitrary processes to
register with it so that others can be notified in some standard way if they die.
Has anyone ever done this? Is there any reason why it is a particularly bad idea?
Thanks,
Chris
--
Chris Friesen | MailStop: 043/33/F10
Nortel Networks | work: (613) 765-0557
3500 Carling Avenue | fax: (613) 765-2986
Nepean, ON K2H 8E9 Canada | email: [email protected]
Chris Friesen wrote:
> I would like some way for the main one to restart, read the
> list of pids out of a file that it conveniently stashed away,
[...]
And until it has done this, any child death will still only be seen
by init. So you either didn't have a problem with this in the first
place, or you can make sure your children don't die while their
parents are changing, or you've just designed yourself a race
condition.
A design where the parent simply doesn't die would be much better.
> Has anyone ever done this?
You could use ptrace to pretty much this effect. Of course, this
only works if the child processes don't already use ptrace for
some other purpose, and your parent now needs to respond whenever
a child gets a non-terminal signal (in addition to the terminal
ones).
- Werner
--
_________________________________________________________________________
/ Werner Almesberger, Buenos Aires, Argentina [email protected] /
/_http://www.almesberger.net/____________________________________________/
Werner Almesberger wrote:
> Chris Friesen wrote:
>
>> I would like some way for the main one to restart, read the list of pids
>> out of a file that it conveniently stashed away,
> And until it has done this, any child death will still only be seen by init.
> So you either didn't have a problem with this in the first place, or you
> can make sure your children don't die while their parents are changing, or
> you've just designed yourself a race condition.
Sure. So the monitorer starts up, attempts to watch a pid, gets an error saying
that it doesn't exist, and handles it.
In the particular case that I'm planning for, the processes in question are
long-running ones which should never die except for upgrades (which could be
designed for).
The general case would be trickier.
Chris
--
Chris Friesen | MailStop: 043/33/F10
Nortel Networks | work: (613) 765-0557
3500 Carling Avenue | fax: (613) 765-2986
Nepean, ON K2H 8E9 Canada | email: [email protected]
Chris Friesen wrote:
> Sure. So the monitorer starts up, attempts to watch a pid, gets an error
> saying that it doesn't exist, and handles it.
You'd still have a PID reuse race. Of course, you could also
cover this by checking the process' start time ...
But just designing the parent to be simple enough to be reliable
and/or generic enough that it doesn't even need to be upgraded
still looks like a more promising approach to me.
- Werner
--
_________________________________________________________________________
/ Werner Almesberger, Buenos Aires, Argentina [email protected] /
/_http://www.almesberger.net/____________________________________________/
Werner Almesberger wrote:
> You'd still have a PID reuse race. Of course, you could also
> cover this by checking the process' start time ...
Good point. It is unlikely this will happen in our scenario (very long-lived
processes), but we should certainly cover that case.
> But just designing the parent to be simple enough to be reliable
> and/or generic enough that it doesn't even need to be upgraded
> still looks like a more promising approach to me.
That would be the simple solution. However, it doesn't cover the case of a
cosmic ray causing a segfault, or the OOM killer coming along, or root
accidentally doing a kill -9 on the wrong pid, or other similar issues.
Chris
--
Chris Friesen | MailStop: 043/33/F10
Nortel Networks | work: (613) 765-0557
3500 Carling Avenue | fax: (613) 765-2986
Nepean, ON K2H 8E9 Canada | email: [email protected]