Re: How Unix manages processes in userland

[Robert Elz <kre%munnari.OZ.AU@localhost>]

There is no reason that management of daemons, or for that mater,
logins on ttys, needs to be done by process 1.   tty login management
isn't done that way because it has to be, but because it always has been
(and it gives init some work to do, something less morbid than just
being a graveyard for orphans.)

That process 1 inherits orphans is irrelevant - there's no information
content in the death of an orphan except that it happened - there's no
meaningful way to extract identity from them, etc.

If we have switched from a fork & exit paradigm (the "old" way of
starting daemon processes - which makes monitoring using wait()
essentially impossible - to one where daemons are run (as daemons)
by some controlling process, which then (perhaps) cleans up, and restarts
them when they die, then any process at all can be the parent process,
it certainly doesn't need to be process 1.

What's more, there can be lots of different ones - if you like launchd,
you could run it, if you like linux's inittab processing, you can run it.
If you like something different, you can run it - what's more, you can
run all of them in parallel if you like, each managing a particular subset
of the daemons that are best suited to the particular system's management
style.

There's no need to impose anything in particular on anyone, just create
a suitable monitoring program, and add it to pkgsrc - people who like it
can run it.   All that might be needed is to make sure that any daemon
processes that might wan to be run have some kind of "don't fork" option.
Most do, to ease debugging, but I think, not quite all of them.

kre