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.

[AdrianOsica]

@michaelrsweet

Explore-logs-2024-10-04 12_27_57.txt

[thomasmerz]

Hi @michaelrsweet , I'm also facing this problem… how or with wich version is or will it be solved because you closed this issue without any more details. Thanks! Sometimes some print jobs fail due to "The page setup information was not valid" and these jobs should be deleted due to ErrorPolicy abort-job in my cupsd.conf - but they block/stop my printing system and won't get deleted 🤷‍♂

Using cups-2.4.11-lp156.313.1.x86_64 on OpenSUSE 15.6

[michaelrsweet]

@thomasmerz We have not made any changes because of this issue, particularly because the original reporter had not responded but because most problems turn out to be the printer or a network issue causing the backend to return the "stop" status code. Without this, if you used an "abort-job" policy then you could very quickly lose all your print jobs just because of an error in the backend.

If you are using a backend that is not supplied with CUPS ("driverless", "implicitclass", "gutenprint", etc. are third-party backends), it is entirely possible that they are incorrectly using the stop-printer status code (4) and that should be fixed in that software vs. having an option/mode to ignore what the backend reports.