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

Re: slapd dying, what next?

Quanah Gibson-Mount escribió: 
--On Wednesday, January 20, 2010 8:39 AM -0600 "Bryan J. Maupin" 
<bmaupin@uta.edu> wrote:

  
We're running on RHEL 5.4, with Heimdal 1.2.1-3, OpenSSL 0.9.8k,
Cyrus-SASL 2.1.23, BDB 4.7.25 (with patches), libunwind 0.99 (for Google
tcmalloc), Google tcmalloc 1.3.
    

libunwind is not required for tcmalloc, you must be building it incorrectly.

  
1. Is there any useful information that can be obtained from these log
entries, or do we simply need to change to a more verbose log level and
wait for slapd to die again?
2. If we need to change our log level, what is a suggested level?  Right
now we're using "loglevel sync stats".  Would it be wise to change the
log level to -1 (any)?  These are production servers, and I imagine
that'd be a huge performance hit.
3. Also, we're logging asynchronously at the moment.  Should we disable
this while debugging?
    

I would suggest you

(a) Upgrade to 2.4.21
done
(b) Fix your tcmalloc build
done
(c) If the problem still occurs, run slapd under gdb so you can get a 
backtrace of some kind.
problem still occurring
Make sure your OpenLDAP build, etc, has debugging symbols.
I've never done this, so just to be sure, to do this I need to pass CFLAGS="-g -O0" when running configure, then make install STRIP="" when it's time for that step, correct?

Then, I simply "gdb /path/to/slapd [options] /path/to/slapd.core"?

Lastly, do I need to change the slapd log level at all, or will all of the helpful information be in the core file?

Thanks.
--Quanah

--

Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra ::  the leader in open source messaging and collaboration