Hide Forgot
Description of Problem: LPRng produces sometimes an interupted system call: [...] Open_gdbm: cannot lock 'db.XXX' - Interrupted system call How Reproducible: 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: 4c4 < Release: 22 --- > Release: 23 73c73 < CFLAGS="-g" ; export CFLAGS --- > CFLAGS="$RPM_OPT_FLAGS" ; export CFLAGS 74a75 > --disable-gdbm \ Take care Andreas
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. Andreas
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 changes. Thanks.
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.