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: 1. 2. 3. Actual results: Expected results: I have not experienced this problem on any fedora release back to Fe-11. Additional info:
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.
Created attachment 519283 [details] printer troubleshooting text
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?
(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.
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. http://software.canon-europe.com/software/0038682.asp?model=
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.
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?
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?
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.
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.
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 reason. <== CUPS is behaving correctly. The cnijnet backend is failing.