[cups.general] cups stops itself due to rejected print file

Michael Sweet mike at easysw.com
Tue Jul 11 12:09:58 PDT 2006


Ambrose Li wrote:
> On 11/07/06, Michael Sweet <mike at easysw.com> wrote:
>> Click on "printers", scroll to your printer, click on "Set
>> Printer Options", scroll to the bottom, choose your error
>> policy.
> 
> Thanks. I had gone to that page before, but for some reason
> (I blame the unreadable Unicode font) I missed that whole
> "Policy" section.
> 
>> > 3. I still do not agree with client-error-bad-request stopping the
>> > printer for the following reasons:
>> >
>> > (a) The HTML docs says that "The ErrorPolicy directive
>> > defines the policy that is used when a backend is unable to
>> > send a print job to the printer." The client-error-bad-request
>> > is not about not being able to send a print job, it is (at least
>> > for this case in question) about receiving malformed input.
>>
>> Actually, it is an error that cannot be recovered from.  We don't
>> know why the request was bad, and that error should not occur
>> during normal operations.
>>
>> Since, by default, CUPS does *not* throw away print jobs (we have
>> a lot of customers that depend on reliable printing...), we have
>> to stop the queue since the receiving end is rejecting the job with
>> an unknown/unexpected/unexplained error.
> 
> No, this is a false dilemma: it does not "have to" to either throw away
> the job or stop the queue; it can just as well Hold it and proceed to
> the next job, and the problematic job still would not be lost.

.... except that conditions like these lend themselves to all jobs
getting held, which is just a pain for admins to deal with (releasing
each held job individually...)

> What "reliable printing" means is different to different people. As I
> have mentioned in a previous post some weeks ago, I used to
> work in a place where "reliable printing" does not mean what you
> have in mind.

So be it, for us "reliable printing" means "no print job is lost,
and all jobs are printed correctly".

>> > (b) You cannot configure cups 1.2 to emulate cups 1.1,
>>
>> The default CUPS 1.2 configuration matches the CUPS 1.1
>> behavior.
> 
> It may match the CUPS 1.1 "configuration", but it certainly does
> not match its *behaviour* because of the new way that pstops
> now works. (I.e., it was previously impossible to generate a
> client-error-bad-request error because the application was not
> very careful about following the DSC).
> ...

The contents of a PostScript file will not cause a "bad request"
error.  The error comes from someplace else, and without an
error_log file with debugging enabled from the client and server,
it is impossible to discover the actual cause.

A non-conformant file might cause the printer to crash or
reject a job, but the results have always been undefined for
non-conforming files anyways!

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




More information about the cups mailing list