[Date Prev][Date Next]
Re: SLAPD Locksup...problems with slapcat as well
That indeed turned out to be the fix. I ran db4.1_recover against the
db's and it worked. I have since switched to ldbm instead of the bdb
backend. I do have some questions, what would have caused such a problem
in the first place? Anyone care to comment on which is better bdb or
ldbm? If such a corruption should happen on ldbm what tool is the
db_recover equivalent for the ldbm format?
Thanks for the assistance, I hope this helps someone in the future.
On Tue, 2004-01-06 at 13:51, Quanah Gibson-Mount wrote:
> --On Monday, January 05, 2004 10:39 PM -0700 Jayson Henkel
> <email@example.com> wrote:
> > Hello,
> > For no obvious reason (there were no changes to the directory today) I
> > had slapd stop answering queries today after working flawlessly for the
> > last 8 or so months. I logged into the box and saw at least 10 slapd
> > process running. Attempting the simple reboot process didn't rectify the
> > issue. I attempted to slapcat the entire database out and attempt to
> > reload it. However slapcat seems to lock or more correctly loop forever.
> > Please see slapcat.trace at http://xoa.darktech.org/slapcat.strace which
> > is a strace of the process... the sched_yield() 0 continues looping to
> > infinity. I also attempted debugging an interaction between the server
> > (which starts up fine) and a simple client search done via ldapsearch -x
> > -h localhost, it's located at http://xoa.darktech.org/slapd.strace. I
> > would appreciate any insight into the problem. I am using Debian
> > Unstable on a uniprocessor machine with version 2.1.23-1 of
> > both the slapd server and the ldap-utils and 2.3.2.ds1-10 of libc6.
> Saying what backend you are using would be helpful. If you are using BDB,
> you may wish to try the db_recover command.
> Quanah Gibson-Mount
> Principal Software Developer
> ITSS/TSS/Computing Systems
> ITSS/TSS/Infrastructure Operations
> Stanford University
> GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html