On Sun, 16 Apr 2017 19:22:36 -0400
Hendrik Boom <hendrik@???> wrote:

> On Sun, Apr 16, 2017 at 05:04:18PM -0400, Hendrik Boom wrote:
> > On Sun, Apr 16, 2017 at 09:59:36PM +0200, Enrico Weigelt, metux IT
> > consult wrote:

> > > By the way: maybe we should write an RFC draft for the whole
> > > issue ...
> >
> > Looked for a relevant RFC. But found only this:
> > https://lists.ubuntu.com/archives/kernel-team/2008-December/003628.html
> > [RFC] [PATCH] notify init daemon when children are reparented to it
> >
> > But this doesn't seem to be quite what we want, and I can't say I
> > have enough context to understand it.
>
> That so-calledRFC seems to be very much in the style of
> requiring the init process to be intimately involved in process
> supervision actions, which is a strong constraint on what init
> systems can be chosen. And, I suspect, an init system that is so
> involved is a potential tool to gradually take over the entire OS, as
> systemd has done.

And, in fact, being written in 2008, that so called rfc might have been
either the excuse or the inspiration for systemd.

The "rfc" suffers from a perfectionism related to bikeshedding. Heaven
forbid there's ever a zombie or a process with a 'T' in the ps status
field! We simply MUST make a perfect init or supervisor system: Nothing
less will do. And while we're indulging our perfection, it's important
to remember that simplicity not be a priority at all. We will remain
oblivious to the fact that complexity and lack of encapsulation
creates flaws far worse than the flaws we're moving heaven and earth
to get rid of. And for gosh sakes, let's forget the facts:

THE FACTS

* sysvinit is perfectly workable for the vast majority of users, or at
least it was until the systemd people influenced the "upstreams" to
build in code to fail with sysvinit.

* sysvinit plus daemontools is perfectly workable for almost all users
who are capable of writing a short run file and creating a symlink.
Daemontools suffers from none of the problems hand-wrung by the
"rfc", and indeed in a daemontools world (or at least as a runit
world which I assume is the same), the only process whose parent is
PID1 is runsvdir (equivalent of daemontools svscanboot). On my
computer, the executables reparented to PID1 are all stuff spawned by
dmenu or UMENU, as well as the gvim executable, which doubleforks
itself automatically. More on this later...

* sysvinit plus OpenRC is perfectly workable for most users who don't
want daemon respawning.

* sysvinit plus OpenRC plus daemontools is perfectly workable for users
who want some daemons respawnable.

* A PID1 consisting of an rc file that somehow respawns the virtual
terminals, background-runs any daemons necessary, and then ends in a
loop that listens for and handles signals to PID1, is perfectly
workable for a person operating a small, special purpose computer. If
I knew how to respawn virtual terminals I'd do just that as a
demonstration, but respawning gettys is incredibly difficult: It
often kills the process that tried to respawn it.

* The 83 line Suckless Init spawning an rc file is perfectly workable
for someone wanting simplicity and the ultimately simple PID1.

Bottom line, all this bikeshedding perfectionism is unnecessary unless
you're a big commercial company trying to turn Free Software into a
cash cow by complexifying it. All the problems were solved long ago, or
are easily solvable by simple, user space addons needing no
modification to the likes of sysvinit, daemontools, runit, s6, Epoch,
OpenRC and the like.

For instance, I have a real problem with zombies and T status processes
created by my use of dmenu and UMENU. It wouldn't be particularly
difficult for me to build a userspace daemontools analog, where one
process parented to PID1 (my analog of svscanboot) would spin around
listening for commands and/or scripts to run in such a way that IT was
the parent, or perhaps via analogs of svscan that don't respawn. I
could then modify dmenu and UMENU to message my daemon in order to run
commands. Notice the idea in this paragraph requires not one
modification to whatever "init system" you're using. And it's simple
enough that even I could implement it, given the time.

There's no need to search for the perfect init or supervisor. Long ago
we got a bunch of them that are all good enough, and can be combined to
fill almost any need. This continuing search for a perfect init is just
wheel spinning, or perhaps an excuse for profit-driven complexification.

SteveT

Steve Litt 
April 2017 featured book: Troubleshooting Techniques
     of the Successful Technologist
http://www.troubleshooters.com/techniques