On 11/10/2014 11:59 AM, Orion Poplawski wrote:
On 11/06/2014 10:35 AM, Orion Poplawski wrote:
> On 11/06/2014 03:14 AM, Rich Megginson wrote:
>> Try to reproduce the problem while using gdb to capture stack traces every few
>> seconds as in
http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-hangs
>> Ideally, we can get some stack traces of the server during the time between
>> the BIND and the ABANDON
>
> Thanks, I'll give it a shot. The gdb command line is a little incorrect
> though, I think you want:
>
> gdb -ex 'set confirm off' -ex 'set pagination off' -ex 'thread
apply all bt
> full' -ex 'quit' /usr/sbin/ns-slapd `pidof ns-slapd` >
stacktrace.`date
> +%s`.txt 2>&1
>
> - added % in date format, drop trailing ``
gdb ended up aborting while trying to do the stack trace when the problem
occurred (
https://bugzilla.redhat.com/show_bug.cgi?id=1162264) so I haven't
had any luck there.
What platform are you using? Can you provide an example of the gdb output?
It seems to be a problem with one of my servers only. I've shut it down and
the user can authenticate fine against our backup server. I tried restoring
from backup with bak2db but that didn't appear to help. Is there a more
restore from scratch procedure I should try next to see if it some kind of
corruption?
I don't know. I'm not sure how db corruption could be causing this
issue. The best way to restore is to completely rebuild the database
e.g. db2ldif then ldif2db - then reinit all of your replicas.