[prev in list] [next in list] [prev in thread] [next in thread] 

List:       suse-linux-e
Subject:    [SLE] BDB Corruption...
From:       Roy Butler <roy.butler () jpl ! nasa ! gov>
Date:       2004-10-19 23:37:27
Message-ID: 4175A537.8050409 () jpl ! nasa ! gov
[Download RAW message or body]

SuSE,

I'm having the problem described below with your openldap2-2.2.6-37.22 
package.  Please consider upgrading to 2.2.17 or backporting the 
relevant patch.


Thanks,
Roy


-------- Original Message --------
Subject: Re: BDB Corruption...
Date: Tue, 19 Oct 2004 16:13:07 -0700
From: Howard Chu <hyc@symas.com>
To: Roy Butler <roy.butler@jpl.nasa.gov>
CC: openldap-software@OpenLDAP.org
References: <417594DE.3090507@jpl.nasa.gov>

Yes, there is a patch - upgrade to the current (2.2.17) release.

Roy Butler wrote:

> 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
>
>


-- 
  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support



-- 
Check the headers for your unsubscription address
For additional commands send e-mail to suse-linux-e-help@suse.com
Also check the archives at http://lists.suse.com
Please read the FAQs: suse-linux-e-faq@suse.com


[prev in list] [next in list] [prev in thread] [next in thread]