On Sun, Apr 16, 2017 at 09:57:38PM -0400, Steve Litt wrote: > On Sun, 16 Apr 2017 19:22:36 -0400 > Hendrik Boom <hend...@topoi.pooq.com> 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 _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
