Re: [RFC] "biological parent" pid

[Bill Davidsen <davidsen@tmr.com>]

Tim Schmielau wrote:
> The ppid of a process is not really helpful if I want to reconstruct the 
> real history of processes on a machine, since it may become 1 when the
> parent dies and the process is reparented to init.
> 
> I am not aware of concepts in Linux or other unices that apply to this
> case. So I made up the "biological parent pid" bioppid (in contrast to the
> adoptive parents pid) that just never changes.
> Any user of it must of course remember that it doesn't need to be a valid 
> pid anymore or might even belong to a different process that was forked in 
> the meantime. bioppid only had to be a valid pid at time btime (it's
> a (btime, pid) pair that unambiguously identifies a process).

I think you are not only using a hammer to swat a fly, buy the wrong 
fly. Would it not do as well to log reparenting? You could even add that 
as an option to init, although if you are being lazy about tracking the 
original parent a kernel log saying something like
   reparent PID1 from PID2 to PID3
would be best. While I think all current reparenting is done to init, I 
could certainly think of a use for a method to reparent back to the 
grandparent, just to keep the accounting clean.

The init option would be unintrusive, but I doubt many people would feel 
the need for a kernel log feature. On the other hand it doesn't happen 
often, I looked at a system up 172 days and it had nothing but the 
daemons reparented (at the moment).

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me