Bug 47866

Summary: Large number of queued files very slow to print
Product: [Retired] Red Hat Linux Reporter: Chris Dunlop <chris>
Component: LPRngAssignee: Crutcher Dunnavant <crutcher>
Status: CLOSED RAWHIDE QA Contact: Brock Organ <borgan>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.1   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2001-08-29 08:43:38 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:

Description Chris Dunlop 2001-07-08 07:31:17 UTC 
From Bugzilla Helper:
User-Agent: Mozilla/4.77 [en] (X11; U; Linux 2.2.19-7.0.1smp i686)

Description of problem:
With 200 files in the queue, there is an elapsed time of about 25 seconds
(on a PII/233) between the finish of one print and the start of data
transmission to the printer for the next print.

How reproducible:
Always

Steps to Reproduce:
1. Put 200 files in the queue.
2. Wait for them to print.
	

Actual Results:  There is a long delay between each print.

Expected Results:  There should be minimal delay

Additional info:

Using a combination of strace and lsof on the lpd "Server" process shows
it's spending all it's time opening the "hf" queue files, stat'ing the "df"
files and writing to /var/spool/lpd/lp/db.lp.  Over and over and over and
over and over....
Comment 1 Chris Dunlop 2001-07-08 07:47:10 UTC 
If I queue a smaller number (e.g. 10) of the exact same of files there is no
delay between the printing of the files (i.e. the printer runs continuously
until all files are printed).
Comment 2 Helge Skrivervik 2001-08-29 08:43:32 UTC 
We have the same problem, although a lot worse: We're frequently creating print jobs which generate thousands of entries in the spool queue. The 
first 10 or 20 pages come out as expected, then the speed dimishes until reaching zero. In some cases I can get a couple of jobs to print by sending 
off a new job to the queue, but in most cases we have found no way to get the printing restarted (except for deleting the queue and start over with 
small batches). We're seeing references to 'lp.db' not found at times (lpq command) and have also noted that the spooling system consumes lots of 
cpu time. The work around seem to be to make sure the jobs get sent to the queue with approximately the same frequency as they get physically 
printed. A real pain.  I would call this a serious problem which should be given high priority - given the environments into which Linux (RH) is being 
marketed and sold these days...
I guess we can reinstall the old lpr system from 6.2?
Comment 3 Crutcher Dunnavant 2001-10-11 14:45:05 UTC 
This should be cleaned up by a db change in the next release.

try this to fix, or grab LPRng from rawhide:

install the LPRng src rpm.
after the line 'configure --enable-nls \' add this line to LPRng.spec:
  --disable-gdbm \

rebuild the rpms, after adding '.gdbm_off' to the release number.
install the rpms.