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.
- 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