>Reading the abovementioned link, I still can't figure out exactly what
>"service management" is. The part about "bring all services up" and
>"bring all services down" sound to me like rc scripts. Is that correct?
It would be more accurate to say that rc scripts are the old,
traditional way of implementing service management. sysvrc is a
primitive service manager. OpenRC is a better service manager (although
far from perfect).
Service management is the thing that brings your machine from the
initial "nothing's running" state to the full "my machine is properly
configured and running everything it needs to be running" state, and
vice-versa at shutdown time. rc scripts are one way of doing that; but
they suck, and their suckage is one of the reasons why systemd rose to
power.
>the part about "change services' states" sounds like (in runit) the sv
>command. Is that correct?
Yes, partially. For longruns, "sv up" is indeed an appropriate way
of setting the service to the "up" state. For oneshots, however, since
there is no daemon to maintain, the service manager cannot rely on the
process supervision suite to handle the service, so it must bring it
up itself in some way.
>You mention that services can be oneshots or longruns. To make it a
>longrun, would you just call it with the equivalent of runit's runsv,
>from inside the rc file?
No, if you run a supervisor as a scion of the service manager, it does
not provide a reproducible launch environment. The supervision tree
should
be spawned by process 1, prior to any invocation of the service manager,
and the service manager should send commands such as "sv up" when
appropriate so longrun services can be started by the supervision tree.
The implementation of "s6 support" in OpenRC does that exact mistake:
they start s6-svscan as a service managed by OpenRC itself. Instead,
they should assume that a supervision tree already exists, independently
from OpenRC. (That is how s6-rc operates.)
>Isn't the proper way to do a runit oneshot to run it from one of the rc
>scripts (/etc/runit/1 or /etc/runit/2)?
Yes, it is. But then it adds ordering constraints: it means you have
to run all your oneshots before starting your process supervisor, i.e.
before running any supervised longrun. This is not flexible enough: for
instance, there are a lot of oneshots that rely on udevd being running;
and udevd is a longrun. Because of that, people who want to run udevd
with runit often simply do not supervise it. (I'm not sure what Void
does; my guess is that they indeed do not supervise it.)
This is a limitation of runit - and of any supervision suite without a
service manager, really: you cannot order your services exactly how you
want, you cannot express real dependencies, you're forced into a
pattern that does not necessarily fit your needs.
When you have a real service manager, you can mix-n-match oneshots and
longruns, have oneshots depend on longruns and vice-versa, and still
have
all your longruns supervised.
>The world needs more explanations like the one you give in this
>slideshow. One thing I'd like to see is a definitive set of definitions
>for service managers and supervision suites. Each definition should
>come with plenty of examples and enough redundancy that even the most
>unfamiliar can understand exactly what you're talking about.
Yeah, I only had 15 minutes so I just couldn't get into any details.
In future presentations I hope to have more time, to dive a little
deeper and explain better.
>Which do you like more: Anopa, or s6-rc?
I'm obviously partial to s6-rc since it's the one I wrote :) and I'm
especially proud of the fact that it runs oneshots with the same
reproducible launch guarantees that it runs longruns with - something
*no* other service manager does (except integrated init systems since
those get everything started by pid 1 anyway).
But anopa also does a few things s6-rc does not, so both have their
uses.
Go check them out yourself and see which one you prefer!
--
Laurent
Received on Mon Feb 06 2017 - 22:44:07 UTC