linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* anyone ever implemented a reparent(pid) syscall?
@ 2003-05-09 18:54 Chris Friesen
  2003-05-10  9:39 ` Werner Almesberger
  0 siblings, 1 reply; 5+ messages in thread
From: Chris Friesen @ 2003-05-09 18:54 UTC (permalink / raw)
  To: Linux Kernel Mailing List


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: cfriesen@nortelnetworks.com


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: anyone ever implemented a reparent(pid) syscall?
  2003-05-09 18:54 anyone ever implemented a reparent(pid) syscall? Chris Friesen
@ 2003-05-10  9:39 ` Werner Almesberger
  2003-05-12  3:23   ` Chris Friesen
  0 siblings, 1 reply; 5+ messages in thread
From: Werner Almesberger @ 2003-05-10  9:39 UTC (permalink / raw)
  To: Chris Friesen; +Cc: Linux Kernel Mailing List

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         wa@almesberger.net /
/_http://www.almesberger.net/____________________________________________/

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: anyone ever implemented a reparent(pid) syscall?
  2003-05-10  9:39 ` Werner Almesberger
@ 2003-05-12  3:23   ` Chris Friesen
  2003-05-12  7:33     ` Werner Almesberger
  0 siblings, 1 reply; 5+ messages in thread
From: Chris Friesen @ 2003-05-12  3:23 UTC (permalink / raw)
  To: Werner Almesberger; +Cc: Linux Kernel Mailing List

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: cfriesen@nortelnetworks.com


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: anyone ever implemented a reparent(pid) syscall?
  2003-05-12  3:23   ` Chris Friesen
@ 2003-05-12  7:33     ` Werner Almesberger
  2003-05-12 14:03       ` Chris Friesen
  0 siblings, 1 reply; 5+ messages in thread
From: Werner Almesberger @ 2003-05-12  7:33 UTC (permalink / raw)
  To: Chris Friesen; +Cc: Linux Kernel Mailing List

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         wa@almesberger.net /
/_http://www.almesberger.net/____________________________________________/

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: anyone ever implemented a reparent(pid) syscall?
  2003-05-12  7:33     ` Werner Almesberger
@ 2003-05-12 14:03       ` Chris Friesen
  0 siblings, 0 replies; 5+ messages in thread
From: Chris Friesen @ 2003-05-12 14:03 UTC (permalink / raw)
  To: Werner Almesberger; +Cc: Linux Kernel Mailing List

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: cfriesen@nortelnetworks.com


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2003-05-12 13:50 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-05-09 18:54 anyone ever implemented a reparent(pid) syscall? Chris Friesen
2003-05-10  9:39 ` Werner Almesberger
2003-05-12  3:23   ` Chris Friesen
2003-05-12  7:33     ` Werner Almesberger
2003-05-12 14:03       ` Chris Friesen

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).