Bug 732192 - Last print job does not delete after printing and continues to print
Summary: Last print job does not delete after printing and continues to print
Alias: None
Product: Fedora
Classification: Fedora
Component: cups
Version: 15
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Tim Waugh
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2011-08-20 14:28 UTC by Paul Lambert
Modified: 2011-10-03 09:38 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2011-10-03 09:38:46 UTC

Attachments (Terms of Use)
printer troubleshooting text (116.39 KB, text/plain)
2011-08-22 13:50 UTC, Paul Lambert
no flags Details
CUPS error log file (592.19 KB, text/plain)
2011-09-30 18:52 UTC, Paul Lambert
no flags Details
cups error log for 10/1/2011 (345.77 KB, text/plain)
2011-10-01 16:25 UTC, Paul Lambert
no flags Details

Description Paul Lambert 2011-08-20 14:28:31 UTC
Description of problem:  Last print job in queue will go to hold state upon initial completion.  Once the hold state is released the job prints again.  This repeats until manually accessing the print queue and deleting the job

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

How reproducible:

Steps to Reproduce:
Actual results:

Expected results:
I have not experienced this problem on any fedora release back to Fe-11.

Additional info:

Comment 1 Tim Waugh 2011-08-22 10:32:08 UTC
Fixed component.

Please run the printing troubleshooter ("system-config-printer" from a terminal window, then Help->Troubleshoot from the menu bar).

First, clear out the queue by cancelling that held job.

When the troubleshooter asks you to print a test page, print the job you have been printing as before.

Please attach the troubleshoot.txt file to this bug report using the "Add an attachment" link above.

Comment 2 Paul Lambert 2011-08-22 13:50:00 UTC
Created attachment 519283 [details]
printer troubleshooting text

Comment 3 Tim Waugh 2011-08-22 14:15:55 UTC
It looks like you're using a 3rd party driver for CUPS.  Are you able to test printing to a printer that does not require this driver, or using a driver that comes with Fedora?  Do you see the same problem?

Comment 4 Jiri Popelka 2011-08-22 14:32:31 UTC
(In reply to comment #3)
> ... or using a driver that comes with Fedora?
There's experimental support for MX340 and MX360 in latest gutenprint.
Install gutenprint-foomatic package and add a new printer queue in system-config-printer.

Comment 5 Paul Lambert 2011-08-22 14:41:50 UTC
I only have the Canon MX350 printer.  The point is I have used this printer since FE-13 and never experienced this problem.  So why did upgrading to FE-15 did I begin to see this problem?  The point is the printer has not changed but FE has.

I downloaded the RPM from Canon that installs the 350 print driver.  

Comment 6 Tim Waugh 2011-08-22 14:48:44 UTC
Please try using a different driver simply to try to narrow down where the problem is.  Without that information, we're all just guessing.

Software is complicated, and things that worked fine before can easily be hiding bugs that are triggered by a perfectly reasonable change elsewhere.

Comment 7 Paul Lambert 2011-09-19 21:47:13 UTC
I have new information, that for me, indicates this is not a specific driver issue.  It appears that certain system upgrades are causing the printer status to go to "pause."  I then bring up the print manager, login as system manager, and change the status.  The document will print but sometimes only 1/2 page and sometimes more.  After this, the print manager does not delete the document.  Maybe because of an print error, maybe because the printer returns to pause.  After awhile the printer is getting reset and that is when the document reprints.

To get the printer to function correctly, I must delete the document manually and then return the printer state to active by clicking the "on" button.  The printer then stays in the active state.

Installing software upgrades should not alter the "system state" values of the OS which would include the selected default printer.  Is a configuration table getting replaced when CUPS has been updated by chance?

Comment 8 Tim Waugh 2011-09-20 11:26:30 UTC
The printer state will change if the job fails and the printer-error-policy is stop-printer (the default).

So if the cnijnet backend exits with status code 1 (failed) or 4 (stop queue), the queue will change state.  Similarly if one of the filters fails for some reason.

The printer state is stored in-memory when cupsd is running; this state is backed by /etc/cups/printers.conf, which is not overwritten on package upgrades (it is specified as %config(noreplace) in the package manifest).

I think it would be useful if you could run CUPS in debugging mode for a while until you see this problem again -- at that point, please attach /var/log/cups/error_log for inspection.

cupsctl --debug-logging

(To turn off debugging mode: cupsctl --no-debug-logging)

If you re-print a document that had only half-printed, after re-enabling the queue, does it succeed?

Comment 9 Paul Lambert 2011-09-30 18:52:47 UTC
Created attachment 525807 [details]
CUPS error log file

Looks as if CUPS debugging has been on.  The attached error log file would capture the problems reported in this bug.

Comment 10 Paul Lambert 2011-10-01 16:25:55 UTC
Created attachment 525876 [details]
cups error log for 10/1/2011

The problem described in the initial bug occurred again today.  Document prints but stays in queue while printer goes to paused state.  This error log is considerably smaller and captures the exact issue.  Therefore, it should require less effort to sort through the errors and identify the problem.

Comment 11 Tim Waugh 2011-10-03 09:38:46 UTC
It is as described in comment #8:

E [01/Oct/2011:11:04:38 -0400] [Job 860] error occurred while printing
D [01/Oct/2011:11:04:40 -0400] PID 3531 (/usr/lib/cups/backend/cnijnet) stopped with status 1!

So if the cnijnet backend exits with status code 1 (failed) or 4 (stop queue),
the queue will change state.  Similarly if one of the filters fails for some

CUPS is behaving correctly.  The cnijnet backend is failing.

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