[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