Re: BDB Corruption...

[Roy Butler <roy.butler@jpl.nasa.gov>]

Jeff,

At the risk of sounding really foolish, I'm pretty sure there is none. 
Would it help if I created one with some custom settings and put it in 
the database directory?  For reference, my database entries in 
slapd.conf are:

database        bdb
checkpoint      1024    5
cachesize       10000
directory       /var/lib/ldap
index   objectClass     eq


Thanks,
Roy


Jeff Saxton stated:
> What does you DB_CONFIG look like?
>
> Jeff Saxton
> Sr. Support Engineer
> Addamark Technologies, Inc.
> http://www.addamark.com
> mailto:support@addamark.com
> CELL: +1 415-640-6392
>
>
> -----Original Message-----
> From: owner-openldap-software@OpenLDAP.org
> [mailto:owner-openldap-software@OpenLDAP.org] On Behalf Of Roy Butler
> Sent: Tuesday, October 19, 2004 3:28 PM
> To: openldap-software@OpenLDAP.org
> Subject: BDB Corruption...
>
>
> Hello everyone,
>
> I'm running OpenLDAP 2.2.6 on SuSE 9.1 on a dual-Xeon Intel server.  It 
> is set up to provide user, group, netgroup, and automount data.  I do a 
> fair amount of writing on occasion when I repopulate some of these OUs 
> using migration scripts to pull in updated data from a production NIS 
> server.  None of the OUs have more than about 1,000 entries.  I've been 
> running it about a month and twice I've had BDB corruption in which the 
> server stopped responding or could only serve up a portion of its 
> entries without hanging.  Restarting the server had no beneficial 
> effect.  The first time, I just shut down, wiped the LDAP database 
> directory, restarted, and slapadd'ed in a back-up LDIF.  Now that it's 
> happened the second time, I've performed the following to try to get to 
> the bottom of it:
>
> ------------------------------
> ------------------------------
>
> # ps -el | grep slapd
> 1 S    76 21668     1  0  76   0 -  7965 schedu ?        00:00:00 slapd
> (The process always seems to be waiting to be scheduled, as if from 
> input on a file descriptor)
>
> # strace -f -p 21668
> Process 21668 attached - interrupt to quit
> futex(0x40787bf8, FUTEX_WAIT, 21669, NULL
>
> # slapcat
> ...
> (Dumps up to a point, then hangs)
>
> # ldapsearch -b ou=...,dc=... ...=...
> ...
> (Returns some entries, doesn't return others which should be there, and 
> hangs on others)
>
> # vmstat 1 1
> procs -----------memory---------- ---swap-- -----io---- --system-- 
> ----cpu----
>   r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us 
> sy id wa
>   0  0      0 278536 219132 328428    0    0     0     3    1    10  0 
> 0 100  0
> (The CPUs were rather idle the entire time)
>
> # cd /var/lib/ldap; db_recover
> (This appeared to resolve the problem, though I still plan to wipe it 
> out and restore from a back-up LDIF)
>
> ------------------------------
> ------------------------------
>
> Has anyone come across a situation like this before and/or have any tips
>
> on how I might permanently avoid the condition in the future?  On less 
> well-used software I'd expect a possible reentrancy issue, but think 
> that's unlikely to be the case here.  If it's a known issue with there 
> is a patch, I'd be happy to test it.
>
>
> Thanks,
> Roy