[Date Prev][Date Next]
Re: Possible bug? (again)
> I would really appreciate some guidance here.
> Whatever is causing this tight loop around time() in slapd doesn't seem
> right, but only someone who knows the innards could verify that for sure.
> I realize that using a directory for authentication services on a busy
> server will cost you in CPU. I do not understand, though, how an idle
> server with no auth going on can have a slapd running at almost 100% CPU
> and suck down hundreds of minutes of CPU time a day.
> I've verified that it is NOT threads, NOT tcp wrappers, and NOT the
> backend DB (tried BerkeleyDB 2.7.7 and gdbm 1.8.0).
> Should I start an ITS ticket? Can I provide more information to help
> debug this? Should I be giving 2.0-devel a test drive?
> Thanks in advance.
> William Yodlowsky
What's your operating system again? Opening a ticket on this sounds
appropriate to me. Do you have a debugger available? Last I recall
you were talking about using truss to view the system calls. With
a debugger you can attach to the process running in the background,
set a breakpoint on the time() call and then back yourself up the
stack until you get to some OpenLDAP slapd code. You ought to be
able to do a "where" from there.
With gdb, it would be "gdb /usr/local/libexec/slapd pid"
where pid is the process id # of slapd.