failed printer not disabled when printing to class

Michael R Sweet mike at easysw.com
Fri Nov 25 05:50:50 PST 2005


a42n8k9 at dejazzd.com wrote:
> I understand that the backend returns the non-zero exit status.
> However, what I'm seeing is that even though the printer failed and
> the class tries the next printer, the failed printer is not
> disabled... thus that failed printer is tried again the next time
> around.

which is entirely appropriate - a connection or open failure is not
fatal and is ordinarily retried by the backend, so there is no reason
to disable the queue.

> I see in the code that the class will pick an available printer, one
> that is idle.  Since the failed printer is still marked as idle it is
> tried every time.

If it is the only idle printer, yes.  And it will retry until the job
gets printed...

> We noticed this in experimenting with the ftp backend script.  This
> script has an incrementing delay built in and tries 7 times.  It was
> interesting to explain the nearly 2 minute delay in every other print
> job when printing to the class and one of the physical printers was
> offline.

Your ftp backend script should only retry if the CLASS environment
variable is not defined.

> Wouldn't you still want that individual printer queue to be stopped
> so that jobs that follow the failure don't have to keep trying to
> print to the downed printer in a class?

There are very few failure modes that justify stopping the queue
without a retry.  The CUPS 1.1 backend interface doesn't offer a
way to differentiate between different kinds of failures - you
only get success (exit status 0) or failure (exit status 1).

CUPS 1.2 adds several new exit codes to allow backends to tell the
scheduler what to do.  The CUPS_BACKEND_STOP exit code (defined in
<cups/backend.h> as the value 4) can be used for this purpose, even
with classes, to force the print queue to be stopped.  The standard
CUPS backends only use this exit code for absolutely fatal conditions
such as bad URIs and other errors that require the administrator/user
to manually fix the problem.

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com
Internet Printing and Publishing Software        http://www.easysw.com




More information about the cups mailing list