Messages in this thread | | | From | Bill Davidsen <> | Subject | Re: [RFC] "biological parent" pid | Date | Tue, 01 Feb 2005 11:08:43 -0500 |
| |
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |