Re: slapd keeps crashing

[Dan White <dwhite@olp.net>]

On 05/25/12 16:52 -0400, David Massie wrote:
> we have narrowed the problem to this: every time we add a value to a
> multivalued attribute for a particular dn, slapd dies. And the attribute
> value does not get added.
>
> Below is the output from a wrapper we use for ldapmodify.
>
> Could this be db corruption? The particular attribute is not indexed.

If you suspect a libdb issue, you could run db_recover within your
db directory; remove and re-add that particular dn; or slapcat/slapadd
your database.

To be safe, you should backup the contents of your db directory and/or
slapcat your db before attempting recovery.

> [root@aaaprod-master log]# do_ldapmod -cred=file:AUA -port=636 -v
> /var/tmp/dba.ldif
> ldap_initialize( ldaps://localhost:636/??base )
> add guemailboxalternate:
>        2024252367@mms.att.net
> modifying entry "uid=ncs-dba-alerts,ou=Aliases,dc=georgetown,dc=edu"
> ldap_result: Can't contact LDAP server (-1)
>
> On Fri, May 25, 2012 at 12:25 PM, Dan White <dwhite@olp.net> wrote:
>
> > On 05/25/12 11:20 -0400, David Massie wrote:
> >
> > > Here are the versions:
> > >
> > > openldap 2.4.31
> > > db4.x86_64                         4.7.25-16.el6
> > > openssl.x86_64                     1.0.0-20.el6
> > > cyrus-sasl-lib.x86_64              2.1.23-13.el6
> > >
> > > Will setting the logging to DEBUG provide anything?
> >
> > I think that would depend on how the section of code which generates the
> > abort is coded. If it produces debug output just prior to calling abort,
> > then you should see that.
> >
> >
> >  Also, I have a question  about debugging a corefile. Our production
> > > version
> > > fo slapd does not have debug symbols compiled in. If, on a non-production
> > > machine, we were to compile another instance, when the same libraries,
> > > etc., but, with debugging turned on could we run gdb against the corefile
> > > we dropped in production against this executable?
> >
> > I don't know the answer to that.
> >
> >  On Wed, May 23, 2012 at 6:22 PM, Dan White <dwhite@olp.net> wrote:
> > > > Which versions of slapd, libssl, berkeleydb, and libsasl are you running?
> > > >
> > > > SIGABRT implies that the process ended due to an unexpected condition
> > > > occurring within either a library or slapd itself. Were any core dumps
> > > > generated? If not, enable core dumps and get a backtrace from within gdb.
> > > > It should point you to the section of code which is triggering the abort.

--
Dan White