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
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
ldap_initialize( ldaps://localhost:636/??base )
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(a)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
>> 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(a)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.