Description of problem: Version-Release number of selected component (if applicable): 0.7.63.2 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:
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'?
1. Here's the output from lpstat -t: [paul@cetautomatix ~]$ lpstat -t scheduler is running no system default destination device for ALCX11NF: ipp://10.0.2.21/EPSON_IPP_Printer 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.
So CUPS thinks it's still printing the job. What does 'ps axfw' say at that point?
Created attachment 178621 [details] ps axfw before printing
Created attachment 178641 [details] lp axfw before/while/after/after_cancel printing
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: >/var/log/cups/error_log 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.
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! Cheers.
Thanks. What does this command say?: python -c 'import cups;cups.setServer("10.0.2.21");c=cups.Connection();print c.getJobs()' (it's all one long line)
I hope I did this as you meant it to be: [paul@cetautomatix ~]$ python -c 'import cups;cups.setServer("10.0.2.21");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 ~] Regards.
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.
Created attachment 178941 [details] "tcpdump -U -s0 -w ipp.pcap tcp port ipp" while printing
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.)
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. Regards.
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://10.0.2.21/EPSON_IPP_Printer?waitjob=no'. 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'.