From Bugzilla Helper: User-Agent: Mozilla/5.0 Galeon/1.2.6 (X11; Linux i686; U;) Gecko/20020830 Description of problem: Berkely DB 4 has a known upstream bug apparently - see here: http://www.openldap.org/lists/openldap-bugs/200208/msg00130.html http://www.openldap.org/its/index.cgi/Software%20Bugs?id=2040 I'm seeing this bug on both RedHat 8 and 9 boxes, since they both have db 4.0.14 (the emails suggest it's fixed upstream?) with db4 in CDB mode. It's a periodic failure for my app - using bsddb3 for Python (version 4.1.3) I get: bsddb._db.DBNoMemoryError: (12, 'Cannot allocate memory -- Lock table is out of available locker entries') A db_recover seems to cure this. [I am also a bit worried that RPM will eventually fall foul of this - that would be disastrous!] If it's fixed upstream could a patch be backported? Alternatively (I know, I'm being lazy) could the db4 maintainer track the Sleepycat bug ID (#6520 as mentioned in the email above) for the fix? Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Run an application on a db4 database (at least in CDB mode) 2. Leave it running 3. You'll get errors about the lockers table being full Actual Results: Application starts crashing with: bsddb._db.DBNoMemoryError: (12, 'Cannot allocate memory -- Lock table is out of available locker entries') Expected Results: Continued running without failures. Additional info: The patch is linked here: http://www.openldap.org/lists/openldap-bugs/200208/msg00131.html ...and a different patch from Sleepycat here: http://www.openldap.org/its/index.cgi/Software%20Bugs?id=2040 I've patched my db4 RPM and will let you know if it stays stable.
The first linked patch does *not* fix the problem - I'm about to re-build the RPM and try the 2nd patch.
FWIW, recent versions of RPM (4.0.5, 4.1.x and 4.2 for sure) do not use the systemwide Berkeley DB any longer -- they use their own private copies instead. (In the case of 4.0.5/4.1.x/4.2, it's a patched db 4.1.24, I think. Check the RPM changelogs/documentation for more information.)
Hmm. The 2nd patch didn't seem to fix it either. It's good to know that RPM doesn't use the system libdb - I'll probably upgrade to the 4.1 track from source in that case and see if it goes away - although I've rolled the machine back to 7.3 now!
Phil says: [I am also a bit worried that RPM will eventually fall foul of this - that would be disastrous!] Nothing like seeing that as the first hit in google. After performing yum install db4-devel (unrelated?) in fedora rawhide, ... ------------------------------------------------------------- rpm -qa rpmdb: Lock table is out of available locker entries error: db4 error(22) from db->close: Invalid argument error: cannot open Packages index using db3 - Cannot allocate memory (12) error: cannot open Packages database in /var/lib/rpm no packages ------------------------------------------------------------- Phil also says "A db_recover seems to cure this." would there be more to the command line than 'db_recover?' I assume this should be opened as a seperate bug? I've had no problems with rpm until I did the install of db4-devel and then this. In fact it got a little further. All of the following worked 1044 yum install db4-devel 1045 yum install gcc-g77 1048 yum install evolution-devel gmp-devel gd-devel 1050 yum install slang-devel gpm-devel then bad news as seen above with 1056 yum install libjpeg-devel libungif-devel libtiff-devel zlib-devel gettext rpm-(-devel)4.3.2-8.x86_64.rpm db4(-devel)4.2.52-6.x86_64.rpm
Filed comment 4 as a new bug. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=134427
From my (recent) exeperience with a db lockers table full problem in rpm, the issue was not closing cursors and databases, causing table overflow eventually. The defaults should be sufficient for general purpose use, that's certainly the case within my rpm experience. If OpenLDAP is an exception that truly needs a larger table, then pleas reopne this bug and get confirmation that, indeed, OpenLDAP needs more table entries.