[cups.general] cups does not respect error policy

Johannes Meixner jsmeix at suse.de
Wed Jan 16 03:17:12 PST 2013


Hello,

On Jan 16 10:18 Jan.Dreyer at bertelsmann.de wrote (excerpt):
> On errors when calling _backends_ the error policy is still respected,
> and also with errors running filters _from_ a backend.
> But when calling a pre-filter, the error policy does not work.
> Just the job itself gets stopped.
>
> It's no showstopper for us; maybe we can modify the filter
> to disable the printerqueue from within (don't "exit 1"
> but "cups-disable").
>
> Nevertheless this is not the behavior that is documented.
> The documentation does not difference between "normal"
> filters and prefilters.

Can you point to the documentation that describes error policy
for filters so that I know which particular documentation you mean.

As far as I found in the documentation, the error policy is
only specified for backends but not for filters.

E.g. see

http://www.cups.org/documentation.php/doc-1.3/ref-printers-conf.html
-------------------------------------------------------------------------
ErrorPolicy
....
The ErrorPolicy directive defines the policy that is used when a
backend is unable to send a print job to the printer.
-------------------------------------------------------------------------

http://www.cups.org/documentation.php/doc-1.3/ref-cupsd-conf.html
-------------------------------------------------------------------------
ErrorPolicy
....
The ErrorPolicy directive defines the default policy that is used when a
backend is unable to send a print job to the printer.
-------------------------------------------------------------------------

http://www.cups.org/documentation.php/doc-1.3/man-backend.html
versus
http://www.cups.org/documentation.php/doc-1.3/man-filter.html

The manual page for filter(7) does not mention the error policy
and it also does not mention any special exit codes.

As far as I understand how the CUPS filtering system is meant to work,
any sudden death of a filter via something like "exit 1" could cause
more or less random behaviour for subsequent filters and the backend.

As far as I understand it, the only clean way for filters to deal
with errors is to report them via "LOG MESSAGES" as described in
the filter(7) manual page but then the filter should not simply
give up via "exit 1" and leave the mess for subsequent filters
and the backend. Instead in case of errors the filter should try
to somehow clean up the mess so that subsequent filters and
the backend still get reasonable data as far as possible.

As far as I know, there is no way in CUPS that filters can somehow
directly signal the backend to cancel the job, retry the job,
or stop the queue.

But there are "Filter and Backend APIs" so that filters and backends
can communicate to a certain extent, see
http://www.cups.org/documentation.php/doc-1.3/api-filter.html
but I have no personal experience with the cupsBackChannel
and cupsSideChannel functions.

A more descriptive documentation regarding "Filter and Backend Programming"
is available e.g. for CUPS 1.5 at
http://www.cups.org/documentation.php/doc-1.5/api-filter.html
where the basic ideas should also apply to CUPS 1.3
but for the actual cupsBackChannel and cupsSideChannel functions
in CUPS 1.3 see
http://www.cups.org/documentation.php/doc-1.3/api-filter.html

Furthermore see
http://en.opensuse.org/SDB:Using_Your_Own_Filters_to_Print_with_CUPS
and
http://en.opensuse.org/SDB:Using_Your_Own_Backends_to_Print_with_CUPS


Kind Regards
Johannes Meixner
-- 
SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany
HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer





More information about the cups mailing list