From Bugzilla Helper:
User-Agent: Mozilla/4.76 [en] (X11; U; Linux 2.4.2-2 i686)

Description of problem:
Occasionally lpr will stop sending spool files to the printer. if you spool
up 100 files or so you can see it many times.. i just saw it five times.
Anyway, it almost looks to my untrained eye like a race condition.. in the
lpr log you get something like..

2001-06-04-22:06:30.777 yucca1 [11632] (Server)  hplj2200: Open_gdbm:
gdbm_lock fd 87
2001-06-04-22:06:30.777 yucca1 [11632] (Server)  hplj2200: Open_gdbm:
locking 87
2001-06-04-22:06:30.778 yucca1 [11632] (Server)  hplj2200: setstatus: msg
'hplj2200: Open_dgbm: open of DB file 'db.hplj2200' failed, File open
error'
2001-06-04-22:06:30.778 yucca1 [11632] (Server)  (ERR) hplj2200: Open_dgbm:
open of DB file 'db.hplj2200' failed, File open error
2001-06-04-22:06:30.781 yucca1 [11632] (Server)  hplj2200: cleanup: done,
exit(33)

If you restart lpd it will continue printing usually. I'm not sure how to
dig around for  deeper information, so that's all i could find so far. lpr
was called from a bash command like 
for i in *.2 ; do groff -man $i | lpr ; done 
which put 120 files in the queue rather quickly. I haven't tried it slowly
yet cause i'm not very patient..

How reproducible:
Always

Steps to Reproduce:
1. submit a bunch of jobs to lpr
2. sit back and watch the log file
3. There is no step three.
	

Actual Results:  2001-06-04-22:06:30.777 yucca1 [11632] (Server)  hplj2200:
Open_gdbm: gdbm_lock fd 87
2001-06-04-22:06:30.777 yucca1 [11632] (Server)  hplj2200: Open_gdbm:
locking 87
2001-06-04-22:06:30.778 yucca1 [11632] (Server)  hplj2200: setstatus: msg
'hplj2200: Open_dgbm: open of DB file 'db.hplj2200' failed, File open
error'
2001-06-04-22:06:30.778 yucca1 [11632] (Server)  (ERR) hplj2200: Open_dgbm:
open of DB file 'db.hplj2200' failed, File open error
2001-06-04-22:06:30.781 yucca1 [11632] (Server)  hplj2200: cleanup: done,
exit(33)


Expected Results:  It should have kept on printing.. should i be filling
these fields in still?

Additional info: Uhm... none, really.