[cups] Re. Why do filter failures stop jobs instead of aborting them? (Bryan Mason)

[Kurt Pfeifle]

On Fri, Aug 11, 2017 at 9:00 PM, <cups-request at cups.org> wrote:

[....]
>    2. Why do filter failures stop jobs instead of aborting them?
>       (Bryan Mason)

[....]
> Message: 2
> Date: Fri, 11 Aug 2017 10:48:06 -0700
> From: Bryan Mason <bmason at redhat.com>
> To: cups at cups.org
> Subject: [cups] Why do filter failures stop jobs instead of aborting
>         them?
> Message-ID: <1502473686.8115.8.camel at redhat.com>
> Content-Type: text/plain; charset="UTF-8"
>
> Hello,
>
> Please consider the following situation that is occurring at one of my
> customers' sites (and reproduced in my test lab):
>
>   * A "two-tier" server configuration (local CUPS service "client"
>     sending jobs to a remote CUPS print "server".
>
>   * A filter failure on the master print server causes the job to
>     fail.  The job is put into "processing-stopped" state.  This
>     allows additional jobs to be processed in the queue on the master
>     print server.  However . . .
>
>   * The IPP backend on the client never exits because the job isn't
>     canceled, aborted, or completed on the server.  As a result, the
>     queue on the client is stuck -- no more jobs can be processed on
>     the client even though the job on the server is able to accept new
>     jobs.
>
> This leads me to the following questions:
>
>  a) Why are jobs "stopped" instead of "aborted" when a filter fails?
>
>  b) Depending on the answer to the above would it be possible to
>     "abort" the job (set the state to IPP_JOB_ABORTED) when a filter
>     failure occurs?  This would allow the client IPP backend to exit
>     and the queue to become un-blocked.
>
> The definition of the "processing-stopped" state in RFC 2199 says that
> jobs in the "stopped" state will resume processing as soon as the
> reasons for the stoppage are no longer present.  This seems to imply
> that "processing-stopped" is a temporary state that will correct
> itself.  Most of the filter failures that I've seen are caused by a
> missing file (hpijs/foomatic/etc.), by a bug in one of the filters, or
> by a malformed input file (bad PDF, etc.).  All of these require some
> sort of corrective action and you need to resubmit the print job after
> the problem is corrected.
>
> To me, setting the state to "aborted" when a filter fails seems to make
> more sense.  I admit that I'm probably looking at this through a pretty
> narrow lens right now, so I understand if there are broader reasons for
> not doing this.
>
> Thanks in advance for any help you can provide.
>
> Bryan Mason
> Senior Software Maintenance Engineer
> Red Hat, Inc.
>
Have you checked the configuration of your queue(s)? There is a setting for
each queue, where you can define ErrorPolicy: there is a choice of abort-job
or retry-current-job or retry-job or stop-printer.

You can set the wanted policy for a queue (unless you want to keep the
default) with lpadmin -o printer-error-policy=<name> -p printername [...].

Cheers,
Kurt
​