failed printer not disabled when printing to class

a42n8k9 at dejazzd.com a42n8k9 at dejazzd.com
Thu Nov 24 16:00:49 PST 2005


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.

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.

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.

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?

> a42n8k9 at dejazzd.com wrote:
> > ...
> > In doing this I discovered that it is by design that failed printers are not disabled when printing to a class or an implicit class.
> >
> > I'm curious as to why this was designed this way.
>
> Because when printing to a class, the backend will not retry and instead
> returns a non-zero exit status.  Without this, backends will keep
> retrying without forwarding the job to the next printer in the class.
>
> --
> ______________________________________________________________________
> Michael Sweet, Easy Software Products           mike at easysw dot com
> Internet Printing and Publishing Software        http://www.easysw.com





More information about the cups-devel mailing list