[lkml]   [2005]   [Feb]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC] "biological parent" pid
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 (
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:10    [W:0.106 / U:11.080 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site