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

[vek@pharmapartners.nl]

On Tue, 20 May 2003 luca.scamoni@sys-net.it wrote:

> Date: Tue, 20 May 2003 07:43:59 GMT
> From: luca.scamoni@sys-net.it
> To: openldap-its@OpenLDAP.org
> Subject: Re: slave slapd crashes on MOD by slurpd (ITS#2527)
>
> astreib@indiana.edu wrote:
>
> >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.
> >
> >
> FYI we applied this patch in our production environment a few days after
> it came out in March.
> Up till now no problems have been reported. It's deployed on at least 12
> slaves managing about 70k entries with a daily update of about 15k
> (adds, mods and deletes).
>


Is this the patch from ITS#2348?  As far as I can see it _is_ included in
the 2.1.20 and probably also the four or five releases previous to that,
even though I don't see any mention of it in the CHANGES file.

Peopler might still want the ldbm backend, for example if for any reason
they prefer GDBM with a more stable ABI and API over Berkeley DB.

I haven't heard any complaints from our customer after this patch and it
was very bad before.  Number of entries more than 100000.

Villy