Bug 118707 - (IT_36395_37049_37886) lpd printer occasssionally prints unwanted multiple copies
lpd printer occasssionally prints unwanted multiple copies
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: cups (Show other bugs)
3.0
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Tim Waugh
:
Depends On:
Blocks: 116727 123574
  Show dependency treegraph
 
Reported: 2004-03-19 05:02 EST by Tony Scholes
Modified: 2007-11-30 17:07 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-01-26 06:41:00 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
printers.conf (1.68 KB, text/plain)
2004-05-18 11:55 EDT, wilburn
no flags Details
PostScript file that triggers problem (207.47 KB, application/postscript)
2004-05-18 12:40 EDT, wilburn
no flags Details
/var/log/cups/error_log for 'LogLevel debug2' (874.95 KB, text/plain)
2004-05-19 11:31 EDT, wilburn
no flags Details
Cups Error log (242.28 KB, text/plain)
2004-11-10 10:33 EST, Mary Dempsey
no flags Details

  None (edit)
Description Tony Scholes 2004-03-19 05:02:48 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)

Description of problem:
A customer system has 8 or so lpd attached printers (some directly 
attached via NIC in the printer, some attached to various D-Link 
print servers)..

These are defined as Raw print queues (no ppd file)

They are a variety of DMP's and Lasers, possibly some Inkjets as well

Occasionally, a print job will repeat itself, sometimes just a few 
times, sometimes ad infinitum, consuming vast amounts of paper.. This 
has happened on several of the printers not just one..

When it happens /var/log/cups/error_log contains "Remote host did not 
accept data/control file" The error number is either 4 or 32...

I've serached through reported cups bugs and see 104360 sometimes 
mention multiple copes problems, but can't see a resolution path..

TIA

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

How reproducible:
Sometimes

Steps to Reproduce:
1. Queue print job with lp
2. Watch printer printer multiple unrequested copies!
3.
    

Actual Results:  Multiple copies printed

Expected Results:  only one copy required

Additional info:
Comment 1 wilburn 2004-03-22 14:49:35 EST
I had this problem with RH9, but it was solved by an update. I have
recently switched to RHEL3 and have the problem again. I think it was
the update to cups-1.1.17-13.3.0.3 that fixed it in RH9. See
RHSA-2003:275-07 and you will find the comment

"These packages also fix a problem with the LPD backend that could cause
jobs to be repeated."
Comment 2 Tim Waugh 2004-03-26 07:23:51 EST
I've applied that fix for 3.0E, and hopefully the package will get in
for Update 3.
Comment 3 Tony Scholes 2004-03-26 09:00:10 EST
Hi

I can confirm that the lpd backend in cups-1.1.17-13.3.0.3 for RH9 
seems to fix the problem, I replaced /usr/lib/cups/backend/lpd on the 
RHEL system with that from a fully updated RH9 server and so far (4 
days) they have had no repeat of the problem..

I'm leaving it like this for now and will await the Update 3 RPMS 

Thanks all for help..
Comment 4 Tim Waugh 2004-04-29 11:57:25 EDT
Unsupported previews are here (for the time being)

ftp://people.redhat.com/twaugh/tmp/cups/
Comment 5 wilburn 2004-05-17 17:30:51 EDT
I have installed the previews, but unfortunately I still have the
problem of multiple copies for some jobs.
Comment 6 Tim Waugh 2004-05-18 04:22:49 EDT
With which jobs?  Importantly, which transport type (ipp, lpd, etc)? 
Is it repeatable?  Is it job-specific?
Comment 7 wilburn 2004-05-18 11:53:47 EDT
The transport mechanism is lpd. I'll attach the printers.conf file. I
am using the default printer. Does not happen for every job, but
consistently for the jobs which do cause the problem.
Comment 8 wilburn 2004-05-18 11:55:03 EDT
Created attachment 100300 [details]
printers.conf
Comment 9 wilburn 2004-05-18 12:40:48 EDT
Created attachment 100305 [details]
PostScript file that triggers problem

Test case.
Comment 10 Tim Waugh 2004-05-19 06:17:19 EDT
Excellent -- a repeatable bug, all the better for diagnosing.  What
would be the most useful would be to see the debug output of the lpd
backend.

Please edit /etc/cups/cupsd.conf and change the LogLevel line to:

LogLevel debug2

and then do run 'service cups reload' to get it to re-read its config
file.  Then empty /var/log/cups/error_log with
">/var/log/cups/error_log" in bash, and print the job once (how many
copies do you get?).  Attach /var/log/cups/error_log to this bug
report and we can see what the lpd backend is up to.
Comment 11 wilburn 2004-05-19 11:29:25 EDT
OK, I've done the test suggested above. As far as I can tell, it will
print infinite copies, so I stopped it after a while with 'lprm' and
'rm /var/spool/cups/tmp/*' 3 copies were printed.
Comment 12 wilburn 2004-05-19 11:31:56 EDT
Created attachment 100345 [details]
/var/log/cups/error_log for 'LogLevel  debug2'
Comment 13 Tim Waugh 2004-05-19 13:05:17 EDT
Thanks.  This is the important line:

[Job 88] Remote host did not accept data file (4)

The printer is not RFC 1179 compliant here, as far as I can tell.  In
6.3 it says:

   If a data file length has been specified, the next "Operand 1"
   octets over the same TCP connection are the intended contents of
   the data file.  In this case, once all of the contents have been
   delivered, an octet of zero bits is sent as an indication that the
   file being sent is complete.  A second level of acknowledgement
   processing must occur at this point.

The printer is meant to send a zero octet, and doesn't have the option
of sending '4' (which is what it does).

What sort of printer is it, and does it display an error message on
the side panel?  Perhaps it needs a firmware upgrade?
Comment 14 wilburn 2004-05-19 13:27:14 EDT
The printer is a Tektronix by Xerox Phaser 8200DX. No error messages
are displayed. I can't find any information about firmware upgrades at
xerox.com

This problem isn't triggered by all versions of cups (or other
operating systems). Is it possible the other versions are working
around a bug in some printers?
Comment 15 Tim Waugh 2004-05-19 18:09:20 EDT
Yes, it's possible.  Do you know which version-release of cups avoids
the problem?
Comment 16 wilburn 2004-05-20 11:59:45 EDT
cups-1.1.17-13.3.0.3 on RH9 does not show this problem.
Comment 18 Tim Waugh 2004-05-25 12:49:09 EDT
Please try cups-1.1.17-13.3.10, available at:

ftp://people.redhat.com/twaugh/tmp/cups/
Comment 19 wilburn 2004-05-25 16:03:55 EDT
Installed cups-1.1.17-13.3.10 and printed 3 documents that triggered
the multiple copy problem previously - only one copy of each printed.

The problem appears to be fixed - thanks!
Comment 20 Terje Røsten 2004-06-11 04:16:32 EDT
I am still having problems.
This morning cups got into a loop and the user got 460 copies of the
same document.
Using the the test version: cups-1.1.17-13.3.10 on RHEL3 for x86-64,
client is RH9.
cupsd is running with LogLevel set to debug.
If you want logs give me a hint.
Comment 22 Tim Waugh 2004-06-24 13:26:27 EDT
Yes please, I need the /var/log/cups/error_log contents.  Thanks.
Comment 31 Mary Dempsey 2004-11-10 10:10:22 EST
We are experiencing the problem , even after updating to cups-1.1.17-
13.3.10 
Comment 32 Tim Waugh 2004-11-10 10:12:44 EST
Please attach the contents of /var/log/cups/error_log.  Thanks.
Comment 33 Mary Dempsey 2004-11-10 10:33:58 EST
Created attachment 106419 [details]
Cups Error log
Comment 34 Tim Waugh 2004-11-11 06:12:27 EST
Mary: It looks like 11 jobs are submitted, all of which completed
without problems, within a 15-minute period.

Did you get more than 11 printed jobs?  Or if you expected fewer than
that, how are they being submitted to the CUPS server?

Thanks.
Comment 35 Tim Waugh 2004-11-22 08:14:32 EST
*ping*
Comment 36 Tim Waugh 2004-12-13 07:41:52 EST
Mary, please reply to comment #34.

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