Comment 12 for bug 692568

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.