CUPs Printer stays paused after Error occurs in CUPs version 2.4.7

[fred1dodd]

Describe the bug When An Error Occurs in the printer (printer door is open when trying to print media) printer becomes paused and must be manually resumed through CUPS back to 'idle' from 'paused', no matter what the Error-policy option is (retry-job, abort-job, retry-current-job or stop-job).

Details:

• OS version Ubuntu 24.04
• CUPs version 2.4.1 and higher (This error did not occur in versions 2.3.x)
• Tried on both Citizen and Dai Nippon printers (so not a printer driver issue)
• this issue is not present in CUPs version 2.3.1

To Reproduce Steps to reproduce the behavior:

1. Set default option of error policy to retry-current-job in either Cups browser or cups.conf
2. Open door of Printer
3. Click on 'Print test page' through maintenance tab in browser
4. Printer will be Paused as door is open
5. Close the printer door so that all errors are clear.
6. Click on 'Print test page' through maintenance tab in browser

Expected behavior I would expect the printer to return to normal and print both jobs left in the queue if in 'retry-current-job' in the Error Policy. However Neither are printed unless the printer is resumed through the admin panel. I would assume that the printer would exit paused mode automatically.

[michaelrsweet]

Can you attach a debug "error_log" file (run cupsctl --debug-logging and then reproduce the issue) so we can see what is happening? Thanks!

[AdrianOsica]

HI, i have similar issue with ipp. CUPS 2.4.1 Ubuntu 22.04.3 LTS. Now i enable debug and wait for next occured

[henrybetts]

In our case this turned out to be because the gutenprint driver was returning a CUPS_BACKEND_STOP rather than a CUPS_BACKEND_FAILED.

For now we've patched the driver. I wonder though if it would be worth having an option in cups to ignore CUPS_BACKEND_STOP exit codes, or at least respect the error policy in those cases. In some environments it's never desirable to stop the queue.

[Sprinterfreak]

it's never desirable to stop the queue.

Is exactly the issue I also face. Needing an admin to fix the backend after each paper-jam isn't exactly desirable if the set policy is specifically retry-job.