[cups.general] queues stop themselves

[Helge Blischke]

David Schlenk wrote:
> 
> On Feb 8, 2005, at 11:35 AM, Klaus Singvogel wrote:
> 
> > Bernd Schubert wrote:
> >> Klaus Singvogel wrote:
> > [...]
> >>>
> >>> But in general, I doubt that this is a good idea. Think... what
> >>> happens, if the CUPS server is still sending jobs to such a
> >>> problematic printer? In many cases the print job gets lost and this
> >>> is no choice for a large company, e.g. getting lose of your bank
> >>> account statements or your payroll isn't fun. :)
> >>
> >> But there are  no lost jobs, the printers just don't accept new print
> >> jobs
> >> until new paper is filled in. I don't know anything about the IPP
> >> protocol,
> >> but I guess there will be something that will tell the cups server,
> >> that
> >> printing the job has finished or at least accepted by the printer.
> >> There's
> >> absolutely no need to stop a queue. Also, filling the queues is still
> >> possible, cups just doesn't try to send something to the printer. I
> >> don't
> >> see a reason why it should stop to try sending the job to the printer.
> >
> > Lets explain it in this way: there are only a few, generic backends
> > distributed with CUPS (one for every connection type) to process your
> > jobs. You are lucky and your printer isn't dropping the data, if there
> > is a problem at the printer. But the CUPS system can't be sure that
> > other printers are so nice either. So the CUPS system is designed to
> > be more conservative in this state and disables the printer as soon
> > as a problem came up.
> >
> > But CUPS is OpenSource...
> >
> > As it is the result that that these queues get disabled, as soon as
> > the backend returns here a non zero exist code. So, its up to you to
> > write / modify an existent backend for your necessities. Have a closer
> > look at the CUPS Software Design Description (sdd.pdf) and the CUPS
> > Software Programmers Manual (spm.pdf), when writing this backend.
> >
> > Have a lot of fun... :-)
> 
> I think most people are upset that this feature just sort of showed up
> one day somewhere after 1.1.20 (which is what I run, because the
> auto-stopping "feature" makes our environment basically unusable).
> Announcing that the default behavior changed and making it configurable
> (on, with configurable timeout, or off entirely) seems to be a better
> way to implement it, as there are obviously people out there that were
> entirely happy with the old behavior.  Just my $.02.
> --
> David Schlenk
> Operating Systems Analyst
> Bethel University
> Saint Paul, Minnesota
> david-schlenk at bethel.edu

I think this problem is mainly due to the status information most
printers
pass back through the whatever (serial, parallel, USB) interface. If the
printer just signals to be inoperable without more detailed information
(system failure versus paper tray empty), there is not much you can do
but
stop the queue.

What we did at our site (nearly all printers are network printers
equipped with
JetDirect cards or equivalent) is using the hpnpf backend ane let that
wait ad infinitum if necessary.

Helge

-- 
Helge Blischke
Softwareentwicklung
SRZ Berlin | Firmengruppe besscom
http://www.srz.de
tel: +49 30 75301-360