[cups.general] queues stop themselves

[David Schlenk]

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