Bug 323311 - Get-Job-Attributes returning job not found error should result in cups marking job complete
Get-Job-Attributes returning job not found error should result in cups markin...
Product: Fedora
Classification: Fedora
Component: cups (Show other bugs)
All Linux
low Severity high
: ---
: ---
Assigned To: Tim Waugh
Fedora Extras Quality Assurance
Depends On:
Blocks: F8Target
  Show dependency treegraph
Reported: 2007-10-08 12:58 EDT by Trever Adams
Modified: 2007-11-30 17:12 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-10-12 12:47:57 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

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

  None (edit)
Description Trever Adams 2007-10-08 12:58:00 EDT
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):

How reproducible:

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 08:41:25 EDT
It already does this:

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


	ipp_status = IPP_OK;

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 11:35:05 EDT
I will be able to provide this later this evening (+8 hours or so from now).
Comment 3 Trever Adams 2007-10-10 14:55:54 EDT
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 14:56:53 EDT
Created attachment 223251 [details]
The capture bziped
Comment 5 Tim Waugh 2007-10-12 12:47:57 EDT
Okay, I think this is the queue you're printing to:

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.