[cups] Broken Pipe, work arounds causing report surprise restarts midstream

[Helge Blischke]

Am 09.07.2014 um 14:42 schrieb Smith, Ed:

> Greetings,
>
> A long print job on our HP8150 was in an "abort" status this  
> morning. Formerly, jobs ended in a 'stopped' status.  This time the  
> printer continued to print subsequent reports.I found a report that  
> only printed 200 of 800 pages, so that's when I went back to find  
> it.  I did a reprint and we were off and running.  This is a new  
> scenario.  It was less visible because we didn't know we had a  
> problem until we reviewed the printed reports, whereas we used to  
> know we had a problem because the printer would stop. "
>
> Prior to this, we had been experiencing broken pipe errors so I  
> worked around it by setting RetryInterval=1h and Timeout 3600 in  
> cupsd.conf, and printer-error-policy=retry-job  instead of stop-job   
> in printers.conf. this is eliminated the broken pipe error. ( The  
> broken pipe error was often caused or correlated to a paper fault of  
> some kind, but in the case of the printer just restarting a report  
> mentioned above, it was not necessarily started by a paper fault.  I  
> ran a wireshark capture earlier on when we were having the broken  
> pipe error, and it showed that the cups server was keeping the TCP  
> connection open, but the printer was ignoring the server. the cups  
> print server is on a different subnet than the printer, with a low  
> bandwidth connection, so I don't think the printer is being  
> overwhelmed, although the printer does look like it needed a break.  
> Sometimes this was just an out of paper condition).  I need a better  
> understanding of what is going on. I had been running cup
> s 1.2.6 prior to this without any of these issues.  This can occur  
> when the network is not very busy.
>
> Our reports are PostScript coming from the applications, and our  
> printers have hardware postscript installed, so we print raw. This  
> has worked well for many years. We started having probs when we went  
> to the new cups version.
>
> Cups version 1.3.7
> RHEL 5.9
>
> Any insight appreciated.
> Thanks!
>
> Ed J Smith
>

I think your issue is due to two facts:
(1)	The design of this printer (HP 8150) isn't quite recent, and,  
unless forced to report status information
	by specific PJL statements (which CUPS filters do not use), tends to  
close the input connection
	when the whole job has beed read.
(2)	IIRC, the backchannel processing has been introduced with CUPS  
1.3.x, so the said behaviour
	of the printer (see above) causes an error.

You didn't tell how your printer is connected. If you use the socket  
backend, I could send you a
(quite old) backend based on source code HP published years ago which
a) tells the printer to report status information (including logging  
error information to a specific file)
b) exits OK when the connection is closed by the printer.

If you are interested in this piece, e-mail me off the list and ask for
backend hpnpf (source code)
and / or
backend hpnpf (description)

Helge