On Sun, Jun 14, 2015 at 9:59 AM, Didier Kryn <kryn@???> wrote:

>     What happens then? Does the webprinting service crash? Or does it hang
> until Cups is ready? Is it able to detect that it is hanging? The last
> would probably be the most sensible way to handle the dependency :-) A
> professional webprinting service should be able to do that. And this is
> what Cups itself does when a printer is paused.

>

A professional web application should use a task queuing service for
anything that is not directly necessary to return a result to the HTTP(S)
transaction. That task queuing service should in turn attempt to perform
the queued tasks, and if they fail in a manner that is transient - like an
API endpoint not yet responding, or a print spooler not yet ready to take
jobs, they should leave the jobs on the queue. There's still a dependency,
but it's a softer one that no longer requires an explicit ordering of
daemons starting.

A professional service of any sort should have monitoring - the
administrator should be alerted within minutes if a service doesn't start
when it should or goes down when it shouldn't,

Getting a little off topic at this point, but opinions vary as to whether
the monitoring should actually restart the service or not. I'm firmly in
the camp that process supervision is evil, because service failures on a
*nix system should not happen, and when they do they should be a really big
inconvenient deal that wakes people up at 3am - because that's the sort of
thing that gets problems noticed and fixed. Process supervision trivializes
failures, and leads us down a path of *tolerating* them and fixing the
symptoms instead of fixing the problem - a really dangerous path when
exploitable code and malicious input are very common causes of service
failure.