Re: comparison

From: Steve Litt <slitt_at_troubleshooters.com>
Date: Tue, 16 Jun 2015 07:34:31 -0400

On Tue, 16 Jun 2015 09:29:15 +0200
Laurent Bercot <ska-supervision_at_skarnet.org> wrote:

> 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

Yes but:

http://smarden.org/runit/replaceinit.html#sysv
http://skarnet.org/software/s6/s6-svscan-1.html

There's no way I've found to do
init=/any/file/of/daemontools(-encore)

>
> 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,

That's what I meant. s6 is a superset of daemontools, making it a
little harder *for me, personally* to find my way around. Also, IIRC I
couldn't compile s6 the last time, but the last time I knew nothing
about the whole idea of init, so let me suspend saying it's more
complicated until I've logged some time actually using s6.

[snip]

> Now, the thing is, when you have a process supervision system, it
> makes your stock init redundant. init has two jobs:
> A. reap zombies

Do you include "listen for and handle relevant signals" in "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.

Yes. Someday I might change Suckless Init so that it *respawns*
(supervises, whatever you want to call it) /bin/rc.init. I would also
need a way that such a modified Suckless Init can pass along the
information that this isn't the first time this boot, in case there are
tasks I don't want to redo in /bin/rc.init.
 
[snip]
> 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/

I'd forgotten about that article. Last time I read it, I didn't
understand it at all. This time, when I read it, it reminded me that my
simple /bin/rc.shutdown stage 3 means I'm short circuiting the logs
during final shutdown.

>
> 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.

Also, even after you get into stage 2, those "services" that do system
initialization require 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.


I'll be doing an s6 install in the next few weeks.

Thanks,

SteveT

Steve Litt
June 2015 featured book: The Key to Everyday Excellence
http://www.troubleshooters.com/key
Received on Tue Jun 16 2015 - 11:34:31 UTC

This archive was generated by hypermail 2.3.0 : Sun May 09 2021 - 19:44:19 UTC