[cups.bugs] [HIGH] STR #3315: USB process hangs, making further printing impossible

[Eric Bischoff]

DO NOT REPLY TO THIS MESSAGE.  INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.

[STR New]

Using CUPS 1.4.0 (svn 8773) package under Linux (KUbuntu Karmic Koala),
with kernel 2.6.31, and hal 0.5.13:

While printing, a process named
"usb://PRINTERMAKE/Printername?serial=USBID&interface=1" is created. After
printing, this process does not die, which makes further printing
impossible as long as an operator does not kill the process manually.

Removing the job with "lprm" does not help, nor to cupsdisable/cupsenable
the printer, not even restarting cups.

When the "usb://" process is killed manually, the print job cleanly ends
and everything returns to normal. Until a new printing ends, a "usb://"
process hangs, has to be killed, etc.

Several people have reported the same problem
(https://bugs.launchpad.net/ubuntu/+source/cups/+bug/420797 and
https://bugs.launchpad.net/ubuntu/+source/cups/+bug/420015). The problem
seems not to depend on the printer (personally I have an Epson DX 7000F).

A "strace" shows that the "usb://" process keeps polling some file
descriptor in vain:

poll([{fd=0, events=POLLIN}, {fd=4, events=POLLIN}], 2, -1) = 1 ([{fd=0,
revents=POLLHUP}])
(... repeated in infinite loop)

lsof shows that this file descriptor is associated to a UNIX domain
socket:

COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
(...)
usb 9846 lp 4u unix 0xffff88007e521b80 0t0 42632 socket
(...)

My guess is that, after printing, CUPS forgets to close the UNIX domain
socket it uses to pass data to its USB backend. But I did not look at the
source code to confirm this hypothesis.

Link: http://www.cups.org/str.php?L3315
Version: 1.4.0