Description of Problem:
LPRng produces sometimes an interupted system call:
[...] Open_gdbm: cannot lock 'db.XXX' - Interrupted system call
Open_gdbm: cannot lock 'db.ps2' - Interrupted system call
The LPRng mailing list suggest to disable the gdbm support. And: Is the
debugging switch really necessary?
I suggest building the LPRng package with the following change:
< Release: 22
> Release: 23
< CFLAGS="-g" ; export CFLAGS
> CFLAGS="$RPM_OPT_FLAGS" ; export CFLAGS
> --disable-gdbm \
On my system this problem shows up once a month when we're trying to print
100-200 pages with invoices. Printing stops after a while. By adding a new
printjob printing resumes. In the log I see a whole buch of "cannot lock 'db.lp'
- Interrupted system call" messages.
BTW. Why do you think disabling gdbm solves the problem?
As I mentioned it above, I read this advice on the LPRng mailing list and since
I did it our company print- and faxserver which serves 6 printers behaves very
well since May 21th without any problems anymore.
We have the same problem on some productions systems. If there are more than 100 Jobs in the queue LPRng stops
printing fopr that queue. After recompiling LPRng with the --disable-gdbm option everything works fine here.
Please give some instructions for rebuilding the packages. Where to make those
Change the spec file of LPRng with the diff information in the first comment and
rebuild the binary package with rpm -bb LPRng.spec (or whatever name you use).
okay, next version.