Bug 153065 - Disappearing printjobs/cups backend error handling
Disappearing printjobs/cups backend error handling
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: cups (Show other bugs)
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Tim Waugh
Depends On:
Blocks: 156320
  Show dependency treegraph
Reported: 2005-04-01 03:24 EST by Harry Venema
Modified: 2007-11-30 17:07 EST (History)
0 users

See Also:
Fixed In Version: RHBA-2005-631
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-09-28 12:57:44 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
error_log/debug2 output (30.04 KB, application/octet-stream)
2005-04-01 03:27 EST, Harry Venema
no flags Details

  None (edit)
Description Harry Venema 2005-04-01 03:24:24 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050323 Firefox/1.0.2 Fedora/1.0.2-1.3.1

Description of problem:
When printing to a HP JetDirect or Castelle Lanpress LPD printserver, and the job is not accepted by the printerserver, the print job is canceled and removed by cups.
Browsing through the debug2 output it looks like the printjob is removed from the queue before the exit status of the backend is checked.

Printing works correctly in Fedora Core 3.

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

How reproducible:

Steps to Reproduce:
1. Turn a printer connected to a printserver off. 
2. Send a number of large print jobs to the printserver.


Actual Results:  Print jobs are removed/deleted from queue.

Expected Results:  printer queue should be disabled  when printjob is not accepted by printserver.

Additional info:
Comment 1 Harry Venema 2005-04-01 03:27:04 EST
Created attachment 112574 [details]
error_log/debug2 output
Comment 2 Tim Waugh 2005-04-12 09:49:09 EDT
Please try these packages:


I suspect that the lpd backend has a negative exit status, which throws out the
logic in the scheduler for differentiating backends from filters.
Comment 3 Harry Venema 2005-04-13 02:52:37 EDT
The new packages don't solve the problem, cups keeps canceling the rejected

Part of error_log:

I [12/Apr/2005:16:07:38 +0200] [Job 33] Attempting to connect to host pstest for
printer raw
I [12/Apr/2005:16:07:38 +0200] [Job 33] Connected from port 515...
D [12/Apr/2005:16:07:38 +0200] [Job 33] lpd_command 02 raw
D [12/Apr/2005:16:07:38 +0200] [Job 33] Sending command string (5 bytes)...
D [12/Apr/2005:16:07:38 +0200] [Job 33] Reading command status...
D [12/Apr/2005:16:07:38 +0200] [Job 33] lpd_command returning 1
D [12/Apr/2005:16:07:38 +0200] UpdateJob: job 33, file 0 is complete.
d [12/Apr/2005:16:07:38 +0200] UpdateJob: Removing fd 5 from InputSet...
D [12/Apr/2005:16:07:38 +0200] CancelJob: id = 33
D [12/Apr/2005:16:07:38 +0200] StopJob: id = 33, force = 0
D [12/Apr/2005:16:07:38 +0200] StopJob: printer state is 3
d [12/Apr/2005:16:07:38 +0200] StopJob: Freeing status buffer...
E [12/Apr/2005:16:07:38 +0200] PID 29499 stopped with status 1!

Comment 4 Tim Waugh 2005-04-13 11:37:46 EDT
Ah, I see what you mean quite clearly now.

I have reported this upstream to see what direction they will go to fix this:

In the mean time I will work on a patch to do what I suggested in that report.
Comment 5 Tim Waugh 2005-04-13 12:51:24 EDT
Please try these packages (1.1.17-

Comment 6 Harry Venema 2005-04-14 03:00:21 EDT
With the latest packages the cupsd daeamon just dies. After removing the history
files from /var/spool/cups the cupsd daemon starts. But after submmiting a new
job the cupsd dies again.

Last few lines of debug2 output:

d [14/Apr/2005:08:56:43 +0200] StartJob: Adding fd 4 to InputSet...
d [14/Apr/2005:08:56:43 +0200] add_job_state_reasons(0xb6f1f008[3], 1)
D [14/Apr/2005:08:56:43 +0200] ProcessIPPRequest: 3 status_code=0
d [14/Apr/2005:08:56:43 +0200] WriteClient: Removing fd 3 from OutputSet...
I [14/Apr/2005:08:56:43 +0200] [Job 1] Attempting to connect to host pstest for
printer raw
I [14/Apr/2005:08:56:43 +0200] [Job 1] Connected from port 515...
D [14/Apr/2005:08:56:43 +0200] [Job 1] lpd_command 02 raw
D [14/Apr/2005:08:56:43 +0200] [Job 1] Sending command string (5 bytes)...
D [14/Apr/2005:08:56:43 +0200] [Job 1] Reading command status...
D [14/Apr/2005:08:56:43 +0200] [Job 1] lpd_command returning -1
E [14/Apr/2005:08:56:43 +0200] PID 26387 stopped with status 1!
D [14/Apr/2005:08:56:43 +0200] UpdateJob: job 1, file 0 is complete.
d [14/Apr/2005:08:56:43 +0200] UpdateJob: Removing fd 4 from InputSet...
D [14/Apr/2005:08:56:43 +0200] StopJob: id = 1, force = 0
D [14/Apr/2005:08:56:43 +0200] StopJob: printer state is 3
d [14/Apr/2005:08:56:43 +0200] StopJob: Freeing status buffer...
d [14/Apr/2005:08:56:43 +0200] ReadClient() 3, used=0
D [14/Apr/2005:08:56:43 +0200] CloseClient() 3
d [14/Apr/2005:08:56:43 +0200] CloseClient: Removing fd 3 from InputSet and
Comment 7 Tim Waugh 2005-04-14 11:58:27 EDT
This was due to a change in main.c that I missed.  I have rectified this and can
no longer produce this crash.

Please try these packages (1.1.17-


I hope this time we'll get it!  Thanks for your continued testing.
Comment 8 Harry Venema 2005-04-15 02:35:44 EDT
The 1.1.17- packages do the trick. No more disappearing print jobs.
The only minor thing missing is an error message in the lpstat output that the
print job failed. But I can live with that. 
Comment 9 Tim Waugh 2005-04-15 11:56:25 EDT
Fixed in CVS.  This fix will be included in any future bug-fix update.  Red Hat
Enterprise Linux 4 is not affected.  Thanks again for the report and for testing.
Comment 14 Red Hat Bugzilla 2005-09-28 12:57:44 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


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