[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: slapd stability problems with add/change operations



--On Wednesday, August 17, 2005 3:56 PM +0200 Adrian Gschwend <adrian.gschwend@bfh.ch> wrote:

Quanah Gibson-Mount wrote:

I'm not quite sure what you mean here.

Are you:

1) set up slapd configuration
  leave slapd off
  slapadd database


yes, sorry for the confusion. I do this but it locks *after* slapdadd
finished properly and I start the DB. So I think it's your 3) if I
understand you correctly:

3) set up slapd configuration
  leave slapd off
  slapadd database


     start slapd

do more adds via ldapmodify 

via the perl-interface to LDAP from our metadatabase that is. (btw, can
that be a problem?)


I wouldn't think so...

On debian we even migrated from kernel 2.4 to 2.6 because we thought it
might be a native thread problem, but same game. I definitely want to do
a dump with the debug-version tomorrow, but as I said I need some hints.
I know how to build it and I know how to attach to the process with GDB,
but what exactly do I have to deliver after that? Would be nice if you
could give me some hints so I can do that tomorrow.

Attached are two files, the first is the slapd log with the add that
actually hangs the machine, the second is the same timeframe with strace.
Note the sched_yield() at the end, that goes on like this forever. More
details hopefully tomorrow with the friendly support of gdb... :)


Generally, what you do, is attach to slapd via gdb:

gdb <path to slapd with debug symbols> <process id>

like

gdb /usr/local/lib/slapd 206

Once you are in gdb, then the easiest thing to do is to get a backtrace of where you are at:

thr apply all bt

will do a back trace of where all the existing threads are currently at.

--Quanah

--
Quanah Gibson-Mount
Principal Software Developer
ITSS/Shared Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html