[cups.bugs] [LOW] STR #1601: socket backend stops the queue on connection reset

[Pawel Salek]

[STR New]

It happens now and then that some of the queues on the departamental print
server switched to a "Stopped" state. It turned out that when a printer
resets a connection, socket backend returns with an error code, and
scheduler decides to stop the entire queue. 

I believe that in such a case (connection was estabilished but later the
printer decides to close the connection because of eg. out of memory
condition), it would be better if the queue was still active but perhaps
only the faulty job was put on hold.

Example log files:

--- cut here ---
D [19/Apr/2006:20:09:09 +0200] ReadClient: 13 POST /printers/bwduplex
HTTP/1.1
D [19/Apr/2006:20:09:09 +0200] ProcessIPPRequest: 13 status_code=0
E [19/Apr/2006:20:09:09 +0200] [Job 23149] Unable to send print file to
printer: Connection reset by peer
E [19/Apr/2006:20:09:09 +0200] PID 22583 stopped with status 1!

--- cut here ---
D [12/Apr/2006:15:05:27 +0200] ReadClient: 10 POST /printers/color
HTTP/1.1
D [12/Apr/2006:15:05:27 +0200] ProcessIPPRequest: 10 status_code=1
E [12/Apr/2006:15:05:36 +0200] [Job 22815] Unable to send print file to
printer: Connection reset by peer
E [12/Apr/2006:15:05:36 +0200] PID 25249 stopped with status 1!
--- cut here ---
This happens with a Fedora version cups-1.1.23-30.2. It comes with a
number of patches but at the *first* sight, none of them affect the code
in question.

Link: http://www.cups.org/str.php?L1601
Version: 1.1.23