On Sun, Apr 16, 2017 at 09:57:38PM -0400, Steve Litt wrote:
> 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.

Thank you for this eloquent and extensive statement of principle.

-- hendrik