Am Sonntag, 14. Juni 2015 schrieb Laurent Bercot:
> 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.
>

And I thought the historic solution would be to give your web printing service an id higher than cups, eg.:

/etc/rc*/S04cups
/etc/rc*/S99awsomewebprinter

Together with the nightmare from unix museum (aka fork when ready) it simply works.

Nik


--
Please do not email me anything that you are not comfortable also sharing with the NSA.