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. _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
