Bug 118707 (IT_36395_37049_37886)
| Summary: | lpd printer occasssionally prints unwanted multiple copies | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 3 | Reporter: | Tony Scholes <tonys> | ||||||||||
| Component: | cups | Assignee: | Tim Waugh <twaugh> | ||||||||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | |||||||||||
| Severity: | medium | Docs Contact: | |||||||||||
| Priority: | medium | ||||||||||||
| Version: | 3.0 | CC: | mary.dempsey, tao, wilburn | ||||||||||
| Target Milestone: | --- | ||||||||||||
| Target Release: | --- | ||||||||||||
| Hardware: | i686 | ||||||||||||
| OS: | Linux | ||||||||||||
| Whiteboard: | |||||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||||
| Doc Text: | Story Points: | --- | |||||||||||
| Clone Of: | Environment: | ||||||||||||
| Last Closed: | 2005-01-26 11:41:00 UTC | Type: | --- | ||||||||||
| Regression: | --- | Mount Type: | --- | ||||||||||
| Documentation: | --- | CRM: | |||||||||||
| Verified Versions: | Category: | --- | |||||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||||
| Embargoed: | |||||||||||||
| Bug Depends On: | |||||||||||||
| Bug Blocks: | 116727, 123574 | ||||||||||||
| Attachments: |
|
||||||||||||
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." I've applied that fix for 3.0E, and hopefully the package will get in for Update 3. 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.. Unsupported previews are here (for the time being) ftp://people.redhat.com/twaugh/tmp/cups/ I have installed the previews, but unfortunately I still have the problem of multiple copies for some jobs. With which jobs? Importantly, which transport type (ipp, lpd, etc)? Is it repeatable? Is it job-specific? 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. Created attachment 100300 [details]
printers.conf
Created attachment 100305 [details]
PostScript file that triggers problem
Test case.
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. 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. Created attachment 100345 [details]
/var/log/cups/error_log for 'LogLevel debug2'
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? 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? Yes, it's possible. Do you know which version-release of cups avoids the problem? cups-1.1.17-13.3.0.3 on RH9 does not show this problem. Please try cups-1.1.17-13.3.10, available at: ftp://people.redhat.com/twaugh/tmp/cups/ 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! 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. Yes please, I need the /var/log/cups/error_log contents. Thanks. We are experiencing the problem , even after updating to cups-1.1.17- 13.3.10 Please attach the contents of /var/log/cups/error_log. Thanks. Created attachment 106419 [details]
Cups Error log
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. *ping* Mary, please reply to comment #34. |
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: