>the point is to avoid extensive scripting hodgepodge
>within run scripts to avoid replicating System V init limitations,
>correct?
The point of supervision is to provide a reliable environment for
running long-lived processes. The fact that most of the scripting
hodgepodge can be avoided is a natural consequence of that goal - it
wasn't the goal itself, it's just a nice benefit.
See
http://skarnet.org/software/s6/overview.html ; it was written for
s6,
but the "Process supervision / Concept" part applies to runit too.
>Since dependency resolution is not done by runit, any inter-daemon
>communication is down to the capabilities of individual daemons, right?
Yes; it's really the case with any init system. systemd is kind of an
exception because it wants to centralize a lot of features which are
really not the job of an init system.
>Case in point, if a specific daemon "talks" to another daemon via dbus,
>none of the runit programs care about this, because the daemon
>should know how to "do the talking" itself, right?
Exactly.
>Finally, in the systemd-sphere there is some emphasis on cgroups and
>socket
>activation. How relevant are those features in your opinion?
cgroups: it really depends on what you want to do. Most of the time,
you
can forget about them and live a happy life. There are a few cases, like
if you're developing a container implementation, where cgroups are
useful;
but chances are you don't need to worry about cgroups.
socket activation: this is systemd-speak for a mix of several things at
the
same time - superservers, socket pre-opening, and fd-holding. You can
read
the details in the mail and forum post linked at the beginning of
http://skarnet.org/software/s6/socket-activation.html .
runit doesn't provide you with superservers, but runit's author also
has
a package for this, if you like:
http://smarden.org/ipsvd/ . s6 also
comes with a Unix domain superserver and a separate package with a
TCP superserver.
No supervision suite will perform socket pre-opening for you.
runit doesn't provide a fd-holding mechanism. However, s6 does, and you
can use the s6-fdholder* programs together with a runit supervision
infrastructure, if you like.
But generally speaking, if you're moving away from systemd and towards
runit (which you are to be commended for!), then you can more or less
forget about socket activation, which is in most cases a lot of
complexity
for very minor benefits.
The systemd-sphere loves hyping cool, new things because they're cool,
new
things, and when they're not that (superservers and fd-holding are not
new
at all), it slaps cool, new words onto them and can pretend they're
cool,
new things. Don't fall for the hype: simplicity is cooler. :)
--
Laurent
Received on Tue Oct 11 2016 - 15:18:58 UTC