Remote IPP job hangs

David Newall cups at davidnewall.com
Fri Jan 7 01:51:47 PST 2011


My computer (running linux) uses IPP to communicate with the printer, which has recently started rebooting for no apparent reason (let's just imagine that incredibly stupid users are tending the printer.)  Often, when this occurs, the CUPS print queue hangs sending a job, and a process remains, e.g.:

   $ ps axuw|grep ipp
   root     30153  0.0  0.3   5304  1800 ?        S    14:53   0:00 ipp://myprinter/printers/printername 147488 user (stdin) 1 finishings=3 job-hold-until=no-hold job-priority=50 number-up=1 job-sheets=none,none job-uuid=urn:uuid:9188fd47-3959-3015-5b54-be9f659660a7 /var/spool/cups/d147488-001

The system also shows an active TCP connection to port 631 on the printer, with 0 bytes in the TCP send queue.  I've let it sit for a few hours but the process doesn't exit and subsequent jobs aren't transmitted.

Using gdb I see the running process is blocked in recv() called from httpGets() in the ipp backend:

  (gdb) where
  #0  0x0012d402 in __kernel_vsyscall ()
  #1  0x001ef821 in recv () from /lib/libpthread.so.0
  #2  0x00143788 in httpGets () from /usr/lib/libcups.so.2
  #3  0x001438a7 in httpUpdate () from /usr/lib/libcups.so.2
  #4  0x00155de8 in cupsDoIORequest () from /usr/lib/libcups.so.2
  #5  0x0015614c in cupsDoFileRequest () from /usr/lib/libcups.so.2
  #6  0xb7f8c3d3 in main () from /usr/lib/cups/backend/ipp

Killing the ipp process is sufficient to restore normal operation.

I deduce that the printer receives a request from the computer but reboots before sending the response; and as a result the ipp process waits forever for a reply that will never be sent.

I don't want to be called upon to kill a process every time this occurs.  Is there a way to configure a time-out so that the job can be automatically retried, or must I execute all of those imagined users?




More information about the cups mailing list