Re: slapd dying, what next?
--On Monday, February 08, 2010 11:05 AM -0600 Bryan J. Maupin bmau...@uta.edu wrote: 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? Correct Then, I simply gdb /path/to/slapd [options] /path/to/slapd.core? Correct Lastly, do I need to change the slapd log level at all, or will all of the helpful information be in the core file? For now, loglevel is likely unimportant. The core file has all the information necessary. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc Zimbra :: the leader in open source messaging and collaboration
Re: slapd dying, what next?
Well, I went ahead and built just the minimal tcmalloc (and upgraded it to 1.5 while I was at it), since that seemed to be something that needed to be fixed anyway. I installed it to one of our replica servers, and it ran for about 3 days, and then slapd died again this morning. So next I'm gonna upgrade to 2.4.21. I'll probably do it on just one of our replica servers for now. 1. A 2.4.21 replica should work fine with a 2.4.19 master, correct? 2. On the machine I upgrade, can I just stop slapd, upgrade, and start slapd again, or should I slapcat/slapadd? Thanks! Quanah Gibson-Mount escribió: --On Wednesday, January 20, 2010 8:39 AM -0600 Bryan J. Maupin bmau...@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 (b) Fix your tcmalloc build (c) If the problem still occurs, run slapd under gdb so you can get a backtrace of some kind. Make sure your OpenLDAP build, etc, has debugging symbols. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc Zimbra :: the leader in open source messaging and collaboration
Re: slapd dying, what next?
--On Wednesday, January 20, 2010 8:39 AM -0600 Bryan J. Maupin bmau...@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 (b) Fix your tcmalloc build (c) If the problem still occurs, run slapd under gdb so you can get a backtrace of some kind. Make sure your OpenLDAP build, etc, has debugging symbols. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc Zimbra :: the leader in open source messaging and collaboration
Re: slapd dying, what next?
--On Thursday, January 21, 2010 4:20 PM -0600 Bryan J. Maupin bmau...@uta.edu wrote: Using --enable-minimal will only create libtcmalloc_minimal.so, so you're saying that's enough, and we don't need libtcmalloc.so, which is what we're linking to now? Thanks! That's correct. :) --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc Zimbra :: the leader in open source messaging and collaboration
