CUPS Stops Print Queue (should it?)

[Anonymous]

> 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?

Thanks.