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

slave slapd crashes on MOD by slurpd (ITS#2527)



Full_Name: Allan Streib
Version: 2.0.27
OS: RedHat Linux 7.3
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (156.56.117.79)


Original message posted to OpenLDAP-Software:

> Both master and slave running OpenLDAP 2.0.27/ldbm.
>
> A change is trying to be replicated to the slave, and the slave crashes.
> Slave log shows:
>
> May 19 14:53:54 xxxxxx slapd[2409]: conn=3 op=4 MOD
dn="iuEduUPID=f5e016cc9bdb465620b8975f215b0c07,ou=people,dc=iu,dc=edu"
> May 19 14:53:54 xxxxxx slapd[2409]: idl_insert_key: idl_fetch_one returned
NULL
>
> That is the last log entry.
>
> The dbb files were recently rebuilt (< 3 days ago) using slapadd from a
> slapcat dump due to suspected indexing problems.  Since this operation
> succeeded on the master, why did it fail on the slave?
>
> I can query the slave entry without error, and slapd restarts without
> error.  But if I then restart slurpd the slave immediately crashes again
> on the same operation.  Suggestions?

Follow-up by Howard Chu:

> There is a patch in CVS that may address this problem. It was never released
> since no one provided any feedback about whether it fixed their problem or
> not.
>
> I suggest you file an ITS for this problem, then try pulling from the last
> rev of servers/slapd/back-ldbm/idl.c from the 2.0 branch:
>        cvs upd -r OPENLDAP_REL_ENG_2_0 idl.c
>
> and report back with your results.

I have rebuilt slapd using the 2.0.27 release with with idl.c v 1.29.2.16 and it
passed all the self-tests.  I will report back if it is observed that this
problem seems to be corrected in our production installation.