Correct, cgroups can be used from any process supervision system.
As for socket activation, this too can be implemented on top of a
traditional supervision system, with no need for it to be baked into the
core. See
http://smarden.org/ipsvd/ for an example implementation. Granted,
this one doesn't have pre-spawning support as systemd's socket activation
does, but there's no reason someone couldn't write a similar shim that did
-- frankly, there's just not a lot of call for the feature.
I do a great deal of work with systemd shop in my day job -- and while it
works reasonably well in the basic cases, I've also hit far more than my
share of bugs and bizarre corner cases. One of the beautiful things about
systemd is its simplicity: It promises a very small number of behaviors,
implements them well, and lets anything additional be implemented
out-of-band.
On Tue, Oct 11, 2016 at 9:36 AM Andy Mender <andymenderunix_at_gmail.com>
wrote:
> Dear Jan, Laurent,
>
> Thank you kindly for answering my questions and clarifications :). I'm
> slowly starting to have a general idea of how to use runit,
> but I will definitely have streams of questions in the nearest future. As
> far as I understood, the point is to avoid extensive scripting hodgepodge
> within run scripts to avoid replicating System V init limitations, correct?
>
> Since dependency resolution is not done by runit, any inter-daemon
> communication is down to the capabilities of individual daemons, right?
> 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?
>
>
> Finally, in the systemd-sphere there is some emphasis on cgroups and socket
> activation. How relevant are those features in your opinion?
> Within the articles I read it was pointed out that cgroups are a kernel
> feature and there is a sizeable section of the kernel .config devoted to
> that.
> Thereby, in theory any init can take advantage of that. Is that correct?
> What about socket activation?
>
> Best regards,
> Andy
>
> On 11 October 2016 at 13:33, Laurent Bercot <ska-supervision_at_skarnet.org>
> wrote:
>
> >
> > >> 2. If several services rely on a common daemon, like dbus or
> > udev/eudev, is
> > >> the said daemon launched multiple times?
> >
> > No. One service directory = one daemon instance. If you have a service
> > directory for dbus-daemon, it will be launched once, no matter how many
> > times you "sv up" that service directory.
> >
> >
> > Runit doesn't track dependencies directly, but it can handle them. This
> is
> >> done by calling sv start $DEP_1 $DEP_2 etc. in the ./run script.
> >>
> >
> > I would advise against starting dependencies in a run script.
> > Idiomatically,
> > a run script should only impact the service it's representing, and
> nothing
> > else; baking in dependencies into run scripts is a slippery slope leading
> > to more problems.
> >
> > The two common approaches to dependencies in supervision suites are:
> >
> > - Do nothing. If all dependencies of a service are up, the service will
> > start normally. If they aren't, the service will fail to start, and the
> > supervisor will automatically make another attempt shortly after.
> > Eventually everything will be up.
> > This approach is reasonable when all dependencies are longrun services
> > (processes that can be supervised) and restarting the processes isn't
> > too costly.
> >
> > - Having a real service manager - like s6-rc, anopa, or OpenRC - handle
> > dependency management. This works in every case, but is the heavier
> > approach.
> >
> >
> > 3. I noticed the ./run scripts are essentially Shell scripts by default.
> >>> Does this resolve the commonly perceived
> >>> limitations of System V init scripts?
> >>>
> >>
> > The limitations of System V scripts does not come from the fact that
> > they're
> > shell scripts. They come from the fact that they don't have a supervision
> > framework to start their daemons in, and thus have to resort to ugly
> hacks
> > to perform what is essentially free with a supervision suite:
> > backgrounding,
> > logging, storing the pid to find the daemon later, etc. Also, they have
> > to work both in the boot scripts' environment and a root shell's
> > environment,
> > and must not inherit anything from that root shell, which leads to a lot
> of
> > dirty boilerplate.
> >
> > All those concerns disappear in a run script, because you don't need a
> pid
> > file, you don't need to background, you don't need to do anything except
> > put your current process into the desired state and execute into your
> > long-running program. The environment a run script is launched in is
> > always the same and there's a lot of infrastructure already in place, so
> > most of the boilerplate disappears. As Jan says, what remains is very
> > simple and very repetitive - it's just about setting the right process
> > state.
> >
> > --
> > Laurent
> >
> >
>
Received on Tue Oct 11 2016 - 14:55:21 UTC