Re: Replication bug with modrdn changetype (ITS#1562)

[enigma@apu.edu]

On Tue, 29 Jan 2002, Pierangelo Masarati wrote:

> enigma@apu.edu wrote:
> > 
> > Full_Name: Christoph Neumann
> > Version: 2.0.21
> > OS: Linux (RedHat 7.1)
> > URL: ftp://ftp.openldap.org/incoming/
> > Submission from: (NULL) (216.86.200.213)
> > 
> > I noticed that our replicated server was crashing.  As soon as I
> > restarted the slave server, I would recieve an error very similar to
> > the following in the rejection log:
> > 
> > ERROR: No such object
> > replica: auth2:0
> > time: 1012261024.0
> > dn: uid=lkhan,ou=Students,ou=People,dc=apu,dc=edu
> > changetype: modrdn
> > newrdn: uid=lraza
> > deleteoldrdn: 0
> > 
> > The most curious thing is: if I do a base search on the slave for the
> > old DN *or* the new  DN, the record is returned.  However, the dn is
> > reported as still being the old DN.
> > 
> > ldapsearch -LLL -h auth2.apu.edu -D "cn=admin,dc=apu,dc=edu" -W -x -b
> > "uid=lkhan,ou=Students,ou=People,dc=apu,dc=edu" -s base '(objectclass=*)'
> > 
> > It is almost as if the replicated server was in the middle of the
> > update and crashed in an inconsistent state.
> 
> Well, the old dn2id is deleted before the ned dn2id is created; of
> course
> there's no guarantee that the db is synced, but I'd expect none of the 
> changes to take place if the crash occurs before they're synced.
> 
> Do you mean a search with either the old or the new dn as base
> yields the SAME entry with the OLD dn? Odd.

Yes.  I can search with either the OLD or the NEW and it yeilds the same
entry.  The dn for that entry is reported as being the OLD dn.  It's really
bizzare!  It only happens with the replicated server, not the master.

> > The master LDAP server does not crash.  It is not in an inconsistent
> > state.  Only the slave ldap server.
> 
> A backtrace of the slave, to determine why it crashed, would help.  
> Is the problem repeatable (same/analogous entry, same/analogous 
> change resulting in the same disaster)?

How do I perform a backtrace?  Is it possible to get the backtrace after
the server has crashed?  There doesn't seem to be a core dump.

The problem is repeatable.  Issuing a modrdn request, whether or not I 
specify a newsuperior, will always cause the replicated server to crash in 
an unstable state.

More Hardware/Software Issues:
* Intel PII, SMP with 2 processors
* RedHat 7.1
* OpenLDAP 2.0.21 (built from source)
* db3-3.1.17-7 (from stock RedHat 7.1 RPM)

./configure             \
  --enable-syslog       \
  --with-cyrus-sasl     \
  --with-readline       \
  --with-threads        \
  --with-tls            \
  --enable-cleartext    \
  --enable-crypt        \
  --enable-spasswd      \
  --enable-wrappers     \	
  --enable-slurpd