Printer error policy seems to be ignored

[philomory]

I've got a printer queue in CUPS on which I've set the error policy stop-printer; but if I send a print job to the printer and it encounters an error, the job ends up in the a held state indefinitely, and the printer queue itself remains in the Idle, Accepting Jobs state. I'd expect a stop-printer policy to disable the printer and cause it to stop accepting new jobs.

Does anyone have any ideas of what other settings I should be looking at other than the printer error policy (and the default ErrorPolicy in cupsd.conf, which I've also set to stop-printer for the time being)?

[zdohnal]

Hi Adam,

it would be great if you provided a list of steps you did and cups debug log from the time frame you did the operation - it can help with explanation. You can enable the debug by cupsctl --debug-logging, do the operation and then logs can be in /var/log/cups or in journal.

Additionally, there is a difference between disabling the queue and rejecting jobs - error policy stop-printer just disables the queue, which doesn't reject any new jobs coming in the queue. IIUC the use case for it is that there is a temporary malfunction on the printer - f.e. isn't turned on, not enough paper or smth - you fix it, enable the queue and reprint - and every job further in the queue are printed as well.

If disabling the queue had rejected new jobs, those jobs would have been lost and have needed to be issued once more.

[jsmeix]

As a side note regarding print queue status meaning
you may also have a look at my rather old text about
"The print queue status is one of the following" in
https://en.opensuse.org/YaST_Printer

[philomory]

OK, I figured it out, and the issue is with Gutenprint (specifically the DNP DS40 backend), not with CUPS (other than perhaps a documentation organization issue). It turns out that the DNP backend returns CUPS_BACKEND_HOLD in situations where it really ought to be using CUPS_BACKEND_FAILED or CUPS_BACKEND_STOP. I'll bring it up with the Gutenprint guys.

The only CUPS issue here might arguably be a documentation issue; the CUPS documentation does mention the different backend exit codes and the effects they have in the backend(7) man page, but that's not really an obvious place to look as an end-user who wants to read about error policies, seeing as it's C API documentation and not e.g. config file documentation or general "using CUPS" documentation.