Printer shouldn't be paused after "hp" CUPS backend failed

Can you run the command

lpstat -v

in a terminal window and also follow the instructions in the "error_log" section of https://wiki.ubuntu.com/DebuggingPrintingProblems for a print job leading to a "backend failed".

This bug is *not* about the backend failure I'm getting. It's merely about the fact that a backend failure makes the printer go to pause instead of just aborting the current task. So the precise error that happens in my case doesn't matter, and it actually happened while I was away (users hadn't understood why the printer had suddenly stopped working).

I only want to know which backend are you using as backends can have different levels of failure. Only very severe failures, like mis-configurations should stop the queue. An every-day event like a printer not turned on, or run out of paper or toner should not stop the queue. This can be fixed by changing the backend's exit codes. Therefore I am asking you the questions of comment #2. Can you please answer these questions? Thanks.

Ah, sorry. It was the HP backend: I experienced this behavior with a Laserjet 1100 and a Photosmart A612, which presumably didn't fail because of the same kind of problem. But of course the error was more severe than lack of paper: with the latter device, a page wasn't printed correctly.

I confirm the problem with Brother MFC-J615W multi-function printer.

If the printer runs out of paper, you have to go to System/Administartion/Printers and enable the printer. This is a major bug because that means that only the administrator can perform this action. If a laptop is shared among family members, they cannot print until the administrator re-enable the printer.

The printer should remain "enable" despite the problem.

Hans Deragon, can you please report a new bug for your problem? This bug report is about the HP backend which is not used by Brother printers. Please run the command

lpstat -v

in a terminal window and also follow the instructions in the "error_log" section of https://wiki.ubuntu.com/DebuggingPrintingProblems for a print job leading to a "backend failed" and post the results in your new bug report.

Status changed to 'Confirmed' because the bug affects multiple users.

Milan, can you tell which printer error lead to the queue being paused? We especially want to know wghether it is some everyday thingy like paper/toner out, printer not turned on, ... or something severe like a mis-configuration. Please attach also the error_log we have asked you for in comment #1. Thanks.

To the hplip developers at HP: Can you make sure that the "hp" and "hpfax" backends of CUPS issue correct error exit codes, so that the queue gets only stopped for severe problems which need admin intervention and not for simple every-day probles which the user can fix by himself? Thanks.

Sorry, I don't have these printers offhand, and anyway the bug is not easy to reproduce. I think it would be simpler to look at the code and see what error codes lead to suspending the printer. IMHO, there are almost no reasons to stop the printer: if an error occurs, kill the current job, or maybe all jobs waiting in the queue, but don't prevent new tasks from being printed unless you're absolutely sure that will result in serious damage/waste.

There's also an issue that in corporate environments, it's probably OK to suspend printers to avoid people sending jobs that won't work and will waste paper, while in home desktops, people would prefer to be allowed to print, and check the result. This could probably be fixed in the GUI by showing a "Printer is suspended due to failure" notification, with a simple way to resume it if the user has admin rights.

[Expired for hplip (Ubuntu) because there has been no activity for 60 days.]

Hi Till and Milan,

Around Lucid time, the hp backend would indeed respond to a paper or toner outage, or trying to print to a powered-off printer, by pausing the queue. I applied beh to my queues as a workaround.

Those cases have been fixed at least since Precise, but I think the behaviour is still different from other backends in certain situations. For example, if the network connection to the printer is interrupted while printing with the hp backend under Trusty, I see this in syslog:

Apr 29 21:24:32 ubuntu hp[4085]: io/hpmud/jd.c 582: timeout write_channel hp:/net/HP_LaserJet_P2055dn?ip=10.0.254.34
Apr 29 21:24:37 ubuntu hp[4085]: io/hpmud/jd.c 94: unable to read device-id
Apr 29 21:24:37 ubuntu hp[4085]: prnt/backend/hp.c 625: ERROR: 5012 device communication error!

and this in cups' error_log:

D [29/Apr/2014:21:24:37 +0000] [Job 1] prnt/backend/hp.c 625: ERROR: 5012 device communication error!
D [29/Apr/2014:21:24:38 +0000] [Job 1] PID 4085 (/usr/lib/cups/backend/hp) stopped with status 4.
D [29/Apr/2014:21:24:38 +0000] [Job 1] Wrote 1 pages...
D [29/Apr/2014:21:24:38 +0000] [Job 1] PID 4087 (pstops) exited with no errors.
D [29/Apr/2014:21:24:38 +0000] [Job 1] PID 4084 (/usr/lib/cups/filter/pdftops) exited with no errors.
I [29/Apr/2014:21:24:38 +0000] [Job 1] Backend returned status 4 (stop printer)
I [29/Apr/2014:21:24:38 +0000] [Job 1] Printer stopped due to backend errors; please consult the error_log file for details.

Under the same conditions with the socket backend, the job fails but the backend is not paused:

D [29/Apr/2014:21:29:40 +0000] [Job 2] Error reading back-channel data: Connection reset by peer
E [29/Apr/2014:21:29:40 +0000] [Job 2] Unable to write print data: Broken pipe
D [29/Apr/2014:21:29:40 +0000] [Job 2] Set job-printer-state-message to "Unable to write print data: Broken pipe", current level=ERROR
I [29/Apr/2014:21:29:40 +0000] [Job 2] Waiting for printer to finish.
D [29/Apr/2014:21:29:40 +0000] [Job 2] ATTR: marker-levels=94
D [29/Apr/2014:21:29:40 +0000] [Job 2] new_supply_state=0, change_state=0
D [29/Apr/2014:21:29:40 +0000] [Job 2] new_state=0, change_state=0
D [29/Apr/2014:21:29:40 +0000] [Job 2] PID 4145 (/usr/lib/cups/backend/socket) exited with no errors.
D [29/Apr/2014:21:29:40 +0000] [Job 2] Wrote 1 pages...
D [29/Apr/2014:21:29:40 +0000] [Job 2] PID 4147 (pstops) exited with no errors.
D [29/Apr/2014:21:29:40 +0000] [Job 2] PID 4146 (gs) exited with no errors.
D [29/Apr/2014:21:29:40 +0000] [Job 2] PID 4144 (/usr/lib/cups/filter/pdftops) exited with no errors.
D [29/Apr/2014:21:29:40 +0000] [Job 2] time-at-completed=1398806980
I [29/Apr/2014:21:29:40 +0000] [Job 2] Job completed.

An example where this happened recently was a particular print job that triggered a firmware error (49 error), causing the printer to lock up and stop responding until power cycled.

I don't know whether to consider this a bug in the hp backend or a difference of opinion. For my users I've kept beh on the queues because it's best if they can reset the printer and carry on, and not have to contact an lpadmin to resume the queue.

Can someone of the HPLIP developers at HP have a look into the issue described by Ryan Tandy in comment #12? Thanks.

This bug is still around as of today :(

I have gone through System->Administration->Printing, and solved it.
and rely appreciate and adore for your help in this blog.
tonertree.com

akbar, what did you exactly do in System->Administration->Printing? Which blog do you mean?

We're still experiencing the same bug on multiple computers running 10.04 with HPLIP versions from 3.13.10 up to 3.14.10. Affected printers have been: M1536dnf, HP M125nw and the M1212nf.
The only workaround I've found so far that's susceptible for our end users who don't have admin rights is to run "cupsenable $PRINTERNAME" every few minutes via crontab. A real solution would be very useful.
(beh does not help us as we need the scanning capability of the hplip drivers).
I can provide more information if required.

This is still a problem on Mint 17 and Ubuntu 14.04 with version 3.15.4 of hplip on the M225dn printer.

This issue occurred on a Debian Jessie system today with the following series of errors in the CUPS log while attempting to send print jobs:

E [20/Nov/2015:10:22:41 -0800] [Job 1828] Unable to send data to printer.
E [20/Nov/2015:10:27:46 -0800] [Job 1828] Stopping unresponsive job.
E [20/Nov/2015:10:47:07 -0800] Missing printer-uri, job-uri, or ppd-name attribute
E [20/Nov/2015:10:47:07 -0800] [Client 17] Returning IPP client-error-bad-request for windows-ext (no URI) from 10.0.1.15
E [20/Nov/2015:10:50:07 -0800] Unable to communicate with avahi-daemon: An unexpected D-Bus error occured
W [20/Nov/2015:11:16:25 -0800] CreateProfile failed: org.freedesktop.ColorManager.AlreadyExists:profile id 'HP_LaserJet_1200-Gray..' already exists

To Till Kamppeter above: for me the error was resolved by going to Administration -> Manage Printers -> HP_LaserJet_1200 -> In the dropdown that has "Maintenance" selected by default, select "Resume Printer".

A UI problem is that "Resume Printer" should be a button, not an entry in a menu that otherwise changes screens. Bigger UI problem of course is lack of any indication that a printer is paused outside the "Resume" option appearing hidden in a drop-down menu.

Still present in ubuntu 16.04. Workaround above is not possible in ubuntu. Please fix the issue.

Is this related in any way to bug 1521134?
1521134 is marked fixed in 3.17.4 so I will test and see.