I agree Laurent. Though, even though complete init+supervision systems like Runit exist, it's been nearly impossible to get a foothold with any alternatives to sysvinit and systemd effectively. I think one of the major setbacks has been the lack of ready-to-use script sets, like those included with OpenRC, various rehashes of sysvinit and bsdinit scripts, and systemd units just aren't there ready to go.
Testing and trying to debug in house scripts is a pain and to be honest stalled our work with LFS a while back.
Runit is one of the most complete alternatives out there, but if scripts are what is holding things back, why has this never been accurately addressed?
-Jim
Sent from my Windows Phone
________________________________
From: Laurent Bercot<mailto:ska-supervision_at_skarnet.org>
Sent: 6/16/2015 12:29 AM
To: supervision_at_list.skarnet.org<mailto:supervision_at_list.skarnet.org>
Subject: Re: comparison
On 16/06/2015 04:54, Steve Litt wrote:
> One thing I can tell you is that daemontools and daemontools-encore
> were never intended to be init systems, whereas I'm pretty sure that
> runit, s6 and nosh intended to be part or all of an init system.
You keep saying that, but at least in the case of runit and s6, it is
inaccurate.
runit and s6 are process supervision systems, just like daemontools,
and can be used with any init system. There are documentation pages
that prove it:
http://smarden.org/runit/useinit.html
http://skarnet.org/software/s6/s6-svscan-not-1.html
That's one thing. When you say "s6 is more complex than daemontools",
it's only more complex because there are more binaries, and more
features, but you can use s6 exactly as you use daemontools - just add
s6- prefixes to the daemontools command names and it will pretty much
work the same. You can tell suckless init, or whatever pid 1 you fancy,
to run s6-svscan, or runsvdir, exactly the same way you're telling it
to run svscan.
(The main difference is that daemontools comes with a svscanboot script
that uses the "readproctitle" logging hack, and runit and s6 don't.
As far as s6 is concerned: readproctitle felt too much like a cop-out to
me, and I wanted a proper logging system for logs falling through
s6-svscan's stderr, which is why I'm using a fifo as shown in the
examples/s6-svscanboot script and the
examples/ROOT/img/tmpfs/service/s6-svscan-log service directory.)
Now, the thing is, when you have a process supervision system, it makes
your stock init redundant. init has two jobs:
A. reap zombies
B. maintain at least one other process alive, so that if everything on the
machine is killed (save init itself), it is still possible to recover and
avoid a hard and dirty reboot.
Note that suckless init, or Rich Felker's suggested init in the otherwise
excellent
http://ewontfix.com/14/ article, do not perform B, and so, are
*incorrect*. The error is minute, and probably inconsequential in any real
life situation, but it is still there; and if you want the smallest possible
pid 1 that will keep your machine usable under the most dire circumstances,
you should not use suckless init, you should use runit.
Process supervision systems automatically perform B, that's their very job;
and svscan/runsvdir/s6-svscan automatically reap every zombie they get
because they have to collect their dead supervisor processes. So they
basically do everything init has to do in stage 2! It's then a natural idea
to try and use them as pid 1. And neither I nor Gerrit did it first; the
first one was Paul Jarc, who pioneered the setup using... daemontools.
http://code.dogmap.org/svscan-1/
Yes, daemontools was never intended to be an init system, but even back then
there was interest in running it as such, and Paul's experiments are what
started it all.
The problem with init is that it's not only stage 2, and stage 1 and 3 are
heavily system-dependent; so making svscan work as init is possible, but
requires good hacking skills.
Gerrit recognized that, so he basically forfeited the idea - instead of
using runsvdir as process 1, he created the minimal amount of pid 1 code
necessary to handle stages 1 and 3, as well as any stage 2 (and runsvdir
is the obvious choice for the stage 2 manager). runit is a basic process
supervision system (runsv/runsvdir) with a simple init wrapper (runit).
I did not want to give up on the idea; I designed s6-svscan so that it
would be easier to run as pid 1 than daemontools' svscan, and managed to
get something working reproducibly and in an almost automatable way, but as
you experienced, the setup still requires some hacking skills, and I need
more time to work around the non-portability issues and come up with a full
turnkey init.
In the meantime, if you don't want to get your hands dirty,
you can still use s6-svscan/s6-supervise as a process supervision system
without trying to make it run as an init system, just as you can use
runsvdir/runsv as a process supervision system without using the runit
binary. That is real modularity, that is the main reason why I believe
runit and s6 are better designed than other-init-software-out-there, and
it would be *trivial* to port your "suckless init on Plop" setup from
daemontools(-encore) to runit or s6, even if you don't use every feature
those packages provide.
--
Laurent
Received on Tue Jun 16 2015 - 11:05:29 UTC