CUPS Stops Print Queue (should it?)
anonymous at easysw.com
Wed Aug 17 16:59:47 PDT 2005
> Put simply, we cannot determine whether a file has printed or what
> has caused the error. The only safe course of action is to stop the
> printer until the administrator has resolved the problem.
> > ...
> > It seems that the scheduler should keep trying to print.
> We don't do this by default because we have no way of knowing
> whether a sporadic error has caused the failure or a problem with
> the print file.
What is the worst that could happen? The scheduler enters a retry loop, and the backend fails again. How is this worse than shutting down the queue? The jobs queue up either way. At least with a retry loop, you eliminate the queue shutting down because of recoverable errors. As it stands right now, I had to deploy a Perl script that is triggered by FAM (file access monitor) when the printers.conf file is modified. It scans for queues taken offline and brings them back online via command line.
> You'll be happy to know that CUPS 1.2 adds an error policy attribute
> which allows you to configure how CUPS handles these errors...
Cool. What is the release date? And where is this feature documented?
More information about the cups