Error Reading Back-channel Data Connection Reset By Peer Cups
Contents |
Status Importance Assigned to Milestone HPLIP Edit Confirmed Undecided Sarbeswar Meher Edit You need to log cups resume printer in to change this bug's status. Affecting: HPLIP Filed here by: backend returned status 1 (failed) Till Kamppeter When: 2011-10-17 Confirmed: 2014-04-30 Assigned: 2014-05-12 Target Distribution Baltix BOSS Juju Charms Collection /usr/lib/cups/backend/lpd failed redhat Elbuntu Guadalinex Guadalinex Edu Kiwi Linux nUbuntu PLD Linux Tilix tuXlab Ubuntu Ubuntu Linaro Evaluation Build Ubuntu RTM Package (Find…) Project (Find…) Status Importance Confirmed Undecided
Avahi-daemon
Assigned to Me Sarbeswar Meher (sarbeswar-meher) Comment on this change (optional) Email me about changes to this bug report hplip (Ubuntu) Edit Confirmed Medium Unassigned Edit You need to log in to change this bug's status. Affecting: hplip (Ubuntu) Filed here by: Milan Bouchet-Valat When: 2010-12-20 Confirmed: 2011-12-17 Target Distribution Baltix BOSS Juju Charms Collection Elbuntu Guadalinex Guadalinex Edu Kiwi Linux nUbuntu PLD Linux Tilix tuXlab Ubuntu Ubuntu Linaro Evaluation Build Ubuntu RTM Package (Find…) Project (Find…) Status Importance Confirmed Medium Assigned to Nobody Me Comment on this change (optional) Email me about changes to this bug report Also affects project (?) Also affects distribution/package Nominate for series Bug Description Binary package hint: cups When printing fails for some reason ("backend failed" message), printer is paused, and won't resume automatically, even after a reboot. This is silly because there's no notice about that in the print dialog nor in the print queue: you have to go to System->Administration->Printing, and be very clever to understand how to re-enable the printer. In most cases, the fact that something failed doesn't mean other documents won't print, and generally users will figure the error better by themselves than with a paused printer. This is in Lucid, cups 1.4.3-1ubuntu1.3 (not sure it'
apple ! com [Download message RAW] [Attachment #2 (multipart/alternative)] On Mar 9, 2011, at 2:55 PM, Matt LaPlante wrote: > We're having problems printing to some Ricoh printers via cups (1.4.5). The \ > printers will stay online, but files in the associated cups queue printing to them \ > will intermittently get hung with a job (often a PDF) sitting in 'processing' \ > status forever. The error log seems to indicate a failure writing to the \ > connection. > ... > D [09/Mar/2011:17:21:13 +0000] [Job 1612] Error reading back-channel data: \ > Connection reset by https://bugs.launchpad.net/bugs/692568 peer D [09/Mar/2011:17:21:13 +0000] [Job 1612] Set \ > job-printer-state-message to "Unable to write print data: Broken pipe", current \ > level=ERROR D [09/Mar/2011:17:21:13 +0000] [Job 1612] Print file sent, waiting for \ > printer to finish... These messages indicate that the printer is dropping the connection prematurely. \ There are a bunch of possible reasons for this (including firmware bugs, ACLs not \ allowing the CUPS http://marc.info/?l=cups&m=129971182231274 system to connect to the printer, an idle timeout that is too \ short, etc.), so getting a network trace with Wireshark is probably the first thing \ to look at. > The job never goes through. The filters are not failing, and you can find the job, \ > including filter, sitting in the process list. An strace of the \ > socket://printer-name process shows what appears to be back-channel* traffic over \ > and over again. The queue gets backed up because the job never stops or goes away \ > until an administrator steps in and cancels it. I'm open to this being a Ricoh \ > firmware problem, but I'd like to know of I can at least get some insight into what \ > *should* be happening here. Is the back channel data actually capable of failing a \ > print job, or is it a red herring? Is it normal for the same values to be repeated \ > over and over again? The prtMarkSupplies stuff is the SNMP supply/status checking code. You can add \ "*cupsSNMPSupplies: False" to the PPD file for the printer to disable it if you like. ________________________________________________________________________ M
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: