Bug 323311 - Get-Job-Attributes returning job not found error should result in cups marking job complete
Summary: Get-Job-Attributes returning job not found error should result in cups markin...
Keywords:
Status: CLOSED CANTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: cups
Version: rawhide
Hardware: All
OS: Linux
low
high
Target Milestone: ---
Assignee: Tim Waugh
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: F8Target
TreeView+ depends on / blocked
 
Reported: 2007-10-08 16:58 UTC by Trever Adams
Modified: 2007-11-30 22:12 UTC (History)
0 users

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2007-10-12 16:47:57 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
The capture bziped (113.49 KB, application/octet-stream)
2007-10-10 18:56 UTC, Trever Adams
no flags Details

Description Trever Adams 2007-10-08 16:58:00 UTC
Description of problem:
There are certain "IPP" print servers out there (the guilty will remain
anonymous if they fix the problem) that forget a job as soon as it is completed.
This results in cups stalling "waiting for job to complete..." when printing to
them. Cups should be patched to accept a "job not found" as complete. This is
because the standard defines no minimum time a job id must remain valid after
completion and many foolish people are thinking this means forgetting it
immediately is great and acceptable.

Version-Release number of selected component (if applicable):
cups-1.3.3-1.fc8

How reproducible:
Always

Steps to Reproduce:
1. Get a black box ipp server
2. Print to it from cups via ipp
3. Watch cups stall indefinitely (or until you do some black magic on the black box)
  
Actual results:
"Waiting for job to complete..."

Expected results:
Job is finished and cups recognizes it.

Comment 1 Tim Waugh 2007-10-09 12:41:25 UTC
It already does this:

      if (ipp_status == IPP_NOT_FOUND)
      {
       /*
        * Job has gone away and/or the server has no job history...
	*/

        ippDelete(response);

	ipp_status = IPP_OK;
        break;
      }

Are you able to attach a tcpdump/ethereal trace of the IPP request?  Something
like this will do:

tcpdump -s0 -U -w ipp.pcap tcp port ipp

Comment 2 Trever Adams 2007-10-09 15:35:05 UTC
I will be able to provide this later this evening (+8 hours or so from now).

Comment 3 Trever Adams 2007-10-10 18:55:54 UTC
My apologies for the delay. I was very occupied with the manufacturer of the
device yesterday and just finished it. It was a repackage of another device and
the original manufacturer has EOLed the product. Hence, innocent and decent, but
unable to help.

Attached is the IPP trace as requested. Sent to an Epson C88 through the device
by CUPS on F8test3 (rawhide current) on behalf of a Windows Postscript driver.

Comment 4 Trever Adams 2007-10-10 18:56:53 UTC
Created attachment 223251 [details]
The capture bziped

Comment 5 Tim Waugh 2007-10-12 16:47:57 UTC
Okay, I think this is the queue you're printing to:
  ipp://usr7500-EBA13B.localdomain:631/ipp/ports

This proceeds as follows:
> Get-Printer-Attributes (IPP/1.1)
< IPP 1.1 not supported
> Get-Printer-Attributes (IPP/1.0)
< OK
> Print-Job
< OK, job-id 1234
> Get-Job-Attributes, job-id 1234
< Client-Error-Not-Found
> Get-Printer-Attributes
Printer never responds.

This seems to be a bug in the printer's IPP implementation.  No response is ever
given to the Get-Printer-Attributes request.



Note You need to log in before you can comment on or make changes to this bug.