On 14/06/2015 11:58, KatolaZ wrote:
> Sorry for asking a silly question, but what's the problem in having
> cups "running" all the time? And better, if you start/stop cups when
> you need it, why should cups notify systemd (or any other init) that
> it is ready to do things? Why should init be informed of the fact that
> a daemon is running or not, except maybe at boot time, and just for
> the sake of allowing parallel boot?

It's not about parallel boot, it's about reliability, even in the case
of sequential boot. It's also not about notifying init, it's about
notifying services that depend on it, which is generally handled by
a centralized service manager - and systemd is such a centralized
service manager that also runs as init.

Say you have an awesome automatic Web printing service; it should
not be activated before CUPS is ready, else it will not work and
clients will complain. How do you make sure you don't start it too
early ? The historical solution is to sleep for a certain amount of
time, but this is ugly, because either you don't sleep enough and
it still fails, or you sleep too much and you waste time. The
correct solution is for CUPS to tell your Web printing service
when it's okay to start - but since CUPS doesn't know what depends
on it, it can only notify its manager, which will then take care of
things.

Of course, you might not have a use for the mechanism, and if Devuan's
only intended audience is desktop PC users who don't care about
reliability, then it does not matter. But readiness notification is
a real engineering issue that needs to be solved.

--
Laurent