Bug 260961 - Print jobs keep status of "processing" when completed
Print jobs keep status of "processing" when completed
Product: Fedora
Classification: Fedora
Component: cups (Show other bugs)
i686 All
medium Severity high
: ---
: ---
Assigned To: Tim Waugh
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2007-08-28 12:55 EDT by Paul Tap
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-08-29 08:41:54 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
ps axfw before printing (8.40 KB, text/plain)
2007-08-29 06:18 EDT, Paul Tap
no flags Details
lp axfw before/while/after/after_cancel printing (40.00 KB, application/x-tar)
2007-08-29 06:22 EDT, Paul Tap
no flags Details
CUPS error log in debug mode (37.95 KB, application/octet-stream)
2007-08-29 07:03 EDT, Paul Tap
no flags Details
"tcpdump -U -s0 -w ipp.pcap tcp port ipp" while printing (113.74 KB, application/octet-stream)
2007-08-29 08:20 EDT, Paul Tap
no flags Details

  None (edit)
Description Paul Tap 2007-08-28 12:55:05 EDT
Description of problem:

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Print a document from any application
2. Wait for the print to be ready
3. Check the printer queue via the applet on the panel (Gnome)
Actual results:

Although the print is ready the status is still processing.

Expected results:

Job completed and removed from the list.

My printer is an Epson ALCX11NF configured with the Epson provide software from
their Linux site (the software is for FC3, but it worked ok for all previous
Fedora versions). 

For now, I just manually remove the job so the next one will print.
Additional info:
Comment 1 Tim Waugh 2007-08-28 13:00:46 EDT
When it is showing 'Processing' but the job has finished, please try this:

1. Run 'lpstat -t' in a terminal window, and show me the output.

2. Select View->Refresh in the queue status window.  Does it still say 'Processing'?
Comment 2 Paul Tap 2007-08-28 14:36:39 EDT
1. Here's the output from lpstat -t:

[paul@cetautomatix ~]$ lpstat -t
scheduler is running
no system default destination
device for ALCX11NF: ipp://
ALCX11NF accepting requests since Tue 28 Aug 2007 08:30:24 PM CEST
printer ALCX11NF now printing ALCX11NF-20.  enabled since Tue 28 Aug 2007
08:30:24 PM CEST
ALCX11NF-20             paul             26624   Tue 28 Aug 2007 08:30:24 PM CEST
[paul@cetautomatix ~]$

2. Executing View->Refresh doesn't change the status.
Comment 3 Tim Waugh 2007-08-29 05:21:30 EDT
So CUPS thinks it's still printing the job.

What does 'ps axfw' say at that point?
Comment 4 Paul Tap 2007-08-29 06:18:51 EDT
Created attachment 178621 [details]
ps axfw before printing
Comment 5 Paul Tap 2007-08-29 06:22:03 EDT
Created attachment 178641 [details]
lp axfw before/while/after/after_cancel printing
Comment 6 Tim Waugh 2007-08-29 06:38:59 EDT
I'd like to see what the CUPS IPP backend is up to at that point.  I'd like to
you try enabling debugging output as follows:

1. Clear out any jobs from the queue

2. Using system-config-printer, go to 'Server Settings' and enable the 'Save
debugging information for troubleshooting' check-box

3. Stop CUPS:

/sbin/service cups stop

4. Clear out the error_log file:


5. Start CUPS again:

/sbin/service cups start

6. Send a print job as before.

Leave it for a few minutes after the job has finished printing, and then please
attach /var/log/cups/error_log as an attachment to this bug report.  Thanks.
Comment 7 Paul Tap 2007-08-29 07:03:48 EDT
Created attachment 178661 [details]
CUPS error log in debug mode

Some additional info: I wanted to switch debugging of, so I stopped cups, but
"forgot" to cancel the test job. Of course the system-config-printer app.
doesn't allow me to change the setting when cups is not running so I had to
start it again before doing such. Surprise, surprise (or not): the job is
printed again!

Comment 8 Tim Waugh 2007-08-29 07:30:23 EDT

What does this command say?:

python -c 'import cups;cups.setServer("");c=cups.Connection();print

(it's all one long line)
Comment 9 Paul Tap 2007-08-29 07:44:59 EDT
I hope I did this as you meant it to be:

[paul@cetautomatix ~]$ python -c 'import
cups;cups.setServer("");c=cups.Connection();print c.getJobs()'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
cups.IPPError: (1030, 'client-error-not-found')
[paul@cetautomatix ~]

Comment 10 Tim Waugh 2007-08-29 08:08:42 EDT
I'd like to see the TCP packets sent between the CUPS machine and the printer. 
Please do this as follows:

1. Clear out any jobs you have.
2. As root, run this command in a terminal window:

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

3. Submit your print job as before.
4. Wait a few minutes, then press Control-C in the terminal window running tcpdump.

Then attach the ipp.pcap file as an attachment to this bug report.  Thanks.
Comment 11 Paul Tap 2007-08-29 08:20:19 EDT
Created attachment 178941 [details]
"tcpdump -U -s0 -w ipp.pcap tcp port ipp" while printing
Comment 12 Tim Waugh 2007-08-29 08:41:54 EDT
The printer is saying the job is still processing; in particular, the IPP
response says that job-state is 5 (which is IPP_JOB_PROCESSING).

So it's not a bug on our side; perhaps the printer has a firmware update that
may solve the problem, or else there may be some reason the printer is not
marking the job as completed.

The printer does have a warning set in the printer-state-reasons attribute list:
'Other warning'. (Not very helpful though.)
Comment 13 Paul Tap 2007-08-29 09:05:37 EDT
Ok, strange that this never happened while running FC3 through 6. It started
when I moved to Fedora 7, so that's why I reported it here. 

The message is due to a wrong page size being send to the printer by my Wife's
Apple which I've not yet been able to change due to Apple "screwing up" their
cups access (or I'm to stupid for the Apple simplicity). Nevermind.

I cleared the messages on the printer, just ot make sure, but that doesn't solve
the problem. I'll check Epson for new firmware.

Comment 14 Tim Waugh 2007-08-29 09:28:06 EDT
Oh, one work-around you could try is to change the CUPS URI for the device to
add '?waitjob=no' to the end, like
'ipp://'.  That way the IPP backend will
not try to wait for the remote job to complete.

However, the printer might not say it's idle in that case, so you might have to
also add '?waitprinter=no'.

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