>> 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 - 11:33:59 UTC