Red Hat Bugzilla – Bug 63798
LPRng with lpdomatic installation problem
Last modified: 2007-04-18 12:42:09 EDT
Description of Problem: I was trying to install a printer (Samsung ML-1200) using the lpdomatic filter and its ML1200.def printer description file. I kept getting lpdomatic crashes until I explicitly turned off all accounting in lpd.conf. (I added the lines: ar@ and la@.) I suspect you can also do this by adding ":ar@:\" and ":la@:\" to the print queue definition in printcap. The lpdomatic documentation mentions that it subverts LPRng's accounting (the "af" setting) for its own purposes, but it doesn't tell you that LPRng's defaults for local and remote accounting is "TRUE". I found I had to turn them off to prevent LPRng from modifying the ML1200.def script by adding several lines at the end. I was manually editing printcap. But I don't think printconf does this for the user automatically. At least I couldn't find it. Version-Release number of selected component (if applicable): RedHat Linus 7.2 LPRng-3.7.4 lpdomatic (no version number, downloaded 15 Apr 02) How Reproducible: Steps to Reproduce: 1. 2. 3. Actual Results: Expected Results: Additional Information: It would be good to add something, soemwhere in the documentation about this. It might be too specific for Printing-HOWTO. I've suggested to Till Kamppeter that it be added to the lpdomatic instructions. Also, you may want to modify printconf to add these lines to printcap when an lpdomatic filter is being specified.
You've left 'Steps to Reproduce' empty. How can I see this for myself?
Steps to reproduce: 1. Download lpdomatic from http://www.linuxprinting.org/lpd-doc.html and install in in a directory. (It helps to set $debug=1 on line 54 to get a log file at /tmp/prnlog.) 2. Generate and download to a directory an lpdomatic printer description file from http://www.linuxprinting.org/show_driver.cgi?driver=gdi using "Printing system interfaces -> LPD-O-Matic/Direct-O-Matic" and selecting printer "Samsung ML-1210". 3. Configure a print queue in /etc/printcap according to the instructions at http://www.linuxprinting.org/lpd-doc.html for LPNrg using ":if . . . :\" to point to the lpdomatic script and ":filter_options . . . :\ to point to the printer description file. 4. Print to the print queue configured above using lpr. 5. Even though I had no ":af=" in the printcap, LPRng attempted to do local accounting. It added a couple of lines at the end of the printer description file: jobstart '-Hlocalhost.localdomain' '-nroot' '-Pml1200' '- kcfA498localhost.localdomain' '-b193' '-t2002-04-10-16:08:09.000' jobend '-Hlocalhost.localdomain' '-nroot' '-Pml1200' '- kcfA498localhost.localdomain' '-b193' '-t2002-04-10-16:08:09.000' This caused lpdomatic to crash, unable to process the definition file. 6. Setting "la@" and "ar@" in lpd.conf forced LPRng to skip accounting, prevented corrupting the printer decription file, and allowed lpdomatic to operate correctly.
The component name changed on me. Sorry. John
I haven't been able to reproduce this using the current Red Hat Rawhide packages. Does this happen if you use the /usr/sbin/lpdomatic that is supplied by the latest foomatic RPM package for that release (1.1-0.20021218.3)?
Sorry that I haven't been able to spend much time on this. The answer to your question is: no. However, I haven't been able to recreate the situation that started all this. Initially, something added these lines to the end of ML1200.def: jobstart '-Hlocalhost.localdomain' '-nroot' '-Pml1200' '-kcfA498localhost.localdomain' '-b193' '-t2002-04-10-16:08:09.000' jobend '-Hlocalhost.localdomain' '-nroot' '-Pml1200' '-kcfA498localhost.localdomain' '-b193' '-t2002-04-10-16:08:09.000' This caused lpdomatic to fail. Till Kamppeter diagnosed this for me and advised me to remove these 2 lines from ML1200.def and turn off accounting for this queue. Since that cleared up the problem, I thought it would be good to get this in the documentation somewhere in case someone else runs into the problem. Unfortunately, I can't reconstruct how these lines got added, except that I know it was done automatically someplace, maybe in printconf, which I initally used to set up the queues before I edited printcap manually.
Thanks. Well, I'll close this for now since I wasn't able to reproduce the problem. (Perhaps it was a bug that was fixed with the updated packages?)