Re: Re[2]: Runit questions

From: Andy Mender <andymenderunix_at_gmail.com>
Date: Tue, 11 Oct 2016 16:36:08 +0200

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:36:08 UTC