Red Hat Bugzilla – Bug 982335
Printed document remains in print queue after printing, subsequent jobs then don't start
Last modified: 2013-07-12 05:19:43 EDT
Description of problem:
A printed document remains in the print queue (as viewed via system-config-printer) with status "processing" even after the print job is completed. This clogs up the print queue and subsequent print jobs are held in the queue and never start. Cancelling the completed print job allows a queued document to print, but then it remains in the print queue.
Version-Release number of selected component (if applicable):
$ yum list installed | grep cups
bluez-cups.x86_64 4.101-8.fc19 @updates
cups.x86_64 1:1.6.2-12.fc19 @updates
cups-filesystem.noarch 1:1.6.2-12.fc19 @updates
cups-filters.x86_64 1.0.35-2.fc19 @updates-testing
cups-filters-libs.x86_64 1.0.35-2.fc19 @updates-testing
cups-libs.x86_64 1:1.6.2-12.fc19 @updates
cups-pk-helper.x86_64 0.2.4-2.fc19 @anaconda
ghostscript-cups.x86_64 9.07-3.fc19 @anaconda
gutenprint-cups.x86_64 5.2.9-11.fc19 @anaconda
python-cups.x86_64 1.9.63-3.fc19 @anaconda
Every time I print.
Steps to Reproduce:
1. Print a document, e.g. a PDF via Evince
2. Document prints on printer but remains in print queue
3. Cancel "completed" job and next job in queue will print
4. This job prints but stays in the print queue as status "processing"
Document is printed but job remains as "processing" in the print queue thus blocking the queue for subsequent jobs.
Status of completed job changed to "Complete" or similar, removed from list of incomplete jobs, subsequent jobs print without manual intervention.
The printer was found automatically when adding a new printer to the system. It is a HP LaserJet 500 series colour printer model M551dn. The printer is connected directly to the network and has it's own IP address so we are using the internal JetDirect print server. The device URI is stated as:
in the Printer Properties dialogue.
Please run this command:
su -c 'cupsctl --debug-logging'
Now print the job again. Afterwards, run this command:
su -c 'cupsctl --no-debug-logging'
Finally, attach /var/log/cups/error_log to this bug report. Thanks.
Thanks Tim. Will do, but I won't be at my work machine (the F19 install) for a couple of days. I'll come back with the output on Thursday.
Created attachment 772280 [details]
As requested, the cups error log generated whilst --debug-logging was active. Ignore the entries from July 8th - they were in the error log already.
Via Evince I printed a single PDF of a journal article during the debugging. I left it for about 10 minutes post clicking print. Document printed OK but remains in the print queue as "Processing". I turned debug logging off at that point. In a short while, 30 minutes?, I will get a notice that the print job has been cancelled if previous experience is anything to go by.
If you need anything further, let me know.
The job is being sent to the printer over IPP, not JetDirect, and the job is being monitored by CUPS. The printer says the job is still processing.
Some printers have buggy IPP implementations. Try using a different device URI for this printer, e.g. "socket:..." (for JetDirect). To do that, use system-config-printer, double-click on the printer icon for this printer, then click the 'Change...' button next to 'Device URI'.
(In reply to Tim Waugh from comment #4)
> The job is being sent to the printer over IPP, not JetDirect, and the job is
> being monitored by CUPS. The printer says the job is still processing.
> Some printers have buggy IPP implementations. Try using a different device
> URI for this printer, e.g. "socket:..." (for JetDirect). To do that, use
> system-config-printer, double-click on the printer icon for this printer,
> then click the 'Change...' button next to 'Device URI'.
Thanks Tim. That's done the trick. I appreciate your help with this.
OK. Closing as NOTABUG since the real issue is that the printer's IPP implementation is broken.