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.
--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users
