Red Hat Bugzilla – Bug 110488
importing new printer is very slow
Last modified: 2007-11-30 17:06:59 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031022
Description of problem:
Our environment has over 500 networked (LPD) printers. There does not
seem to be a way to add a new LPD printer at the command line, so I've
written a Perl script to spit out a settings.xml file with entries for
each of the printers, then I import that file:
printconf-tui --Ximport settings.xml
This works fine, but when I restart the cups daemon, it takes well
over 5 minutes (on a 2.0GHz P4!) to start as it has to generate over
500 ppd files in /etc/cups/ppd/*.ppd
This, too, would be fine if it only happened once, however, if I add
one printer, regenerate and import settings.xml, and restart cups, it
regenerates _all_ the *.ppd files. It regenerates all files
regardless if I use --merge or --force with printconf-tui.
I've tried adding a printer with --merge and only one printer in the
settings.xml file, and I've tried with all 500+ printers in
settings.xml and that doesn't affect it either. As long as an import
was done, all *.ppd files are rebuilt.
Is there a way to only generate *.ppd files for new printers, or
better yet, a way to add LPD printers without having to go through
import/export of the xml file?
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Generate a settings.xml file for new printer
2. Import it with printconf-tui
3. Restart cups and don't hold your breath
Actual Results: Hurry up and wait.
Expected Results: A delay of a few seconds or less.
This is a shortcoming of the design of the redhat-config-printer tool,
and is something that only a re-write can fix. :-((
You *could* add LPD printers via the CUPS web interface,
http://localhost:631/ -- but those printers won't be editable in the
redhat-config-printer tool then.
Closing this as DEFERRED, since it's not really something that an RHBA
or anything can really address -- but it's an issue which a future
release hopefully *will* address.