anyone ever implemented a reparent(pid) syscall?
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
Signature · 4 lines
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]
Quoted 2 lines · Chris Friesen
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.
Quoted 1 line
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
Signature · 3 lines
_________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina [email protected] / /_http://www.almesberger.net/____________________________________________/
Quoted 9 lines · Werner Almesberger
Quoted 2 lines · Chris Friesen
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
Signature · 4 lines
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]
Quoted 2 lines · Chris Friesen
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
Signature · 3 lines
_________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina [email protected] / /_http://www.almesberger.net/____________________________________________/
Quoted 2 lines · Werner Almesberger
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.
Quoted 3 lines
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
Signature · 4 lines
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]