bahamas10_

If Unix were invented today, with all of the knowledge and understanding we have now, and with no obligation to support any of the software currently written, would the process inheritance model stay the same? Would it make more sense for processes to be owned to the next available parent, or is the current mechanism of straight-to-the-top the superior model? and why?

Explanation

Currently, when a child of a child process becomes orphaned (its parent dies), the child is owned to the top-level process, typically init as pid 1 (though in the case of zones this is slightly different as there is a shared process space). Would it make more sense for the child to be owned to the next available parent and not just go straight up the chain?

Say there is a chain like:

p1 -> p2 -> p3 -> p4

If p3 dies, then p4 will be owned straight to p1 with no regard for p2 in the inheritance chain. It seems like it would make more sense for p4 to be owned to p2 in this event, as p2 is the next available parent in this chain, and has the closest relation to p4.

Many service management frameworks encounter this "problem" and have unique ways of solving it: Illumos has contracts, others use ptrace, and Upstart flat out says it can't track this. Note that the solutions usually require some sort of mechanism in the kernel to track processes, and cannot effectively and efficiently be implemented solely in the userland.

Thanks, it's nice to know I am not the only one who questioned the reparenting logic that is taken as a given in most systems.

Contracts are definitely the best way I've seen to deal with this, but if you were to rewrite Unix today for a brand new world, would you change the inheritance/reparenting logic? or is contracts the proper method to control/follow collections of processes?