(ITS#4333) crash in back meta

[bgmilne@staff.telkomsa.net]

Full_Name: Buchan Milne
Version: 2.3.17
OS: Linux 2.6 (RHEL 4)
URL: http://www.zarb.org/~bgmilne/bgmilne-20060112.txt
Submission from: (NULL) (196.25.124.11)


I have been seeing instability in our 2.3 deployment, which for some reason has
only affected our slaves (which run RHEL4, thus 2.6 kernel). Our masters
(clustered) which run RHEL3 (thus 2.4 kernel) have been unaffected, but this may
be because the slaves are the only ones to see the situation of a bind to an dn
in the meta backend.

The deployment runs syncrepl, with the relevant aspects of slapd.conf:

database        bdb
suffix          "dc=cybertrade,dc=co,dc=za,dc=isp"
rootdn          cn=Manager,dc=telkomsa,dc=net

directory       /var/lib/ldap2.3/cybertrade
cachesize 10000
idlcachesize 30000
checkpoint 1024 5

syncrepl rid=123
        provider=ldap://192.168.3.100
        type=refreshAndPersist
        searchbase="dc=cybertrade,dc=co,dc=za,dc=isp"
        scope=sub
        retry="60 10 300 10"
        schemachecking=off
        bindmethod=simple
        binddn="cn=thebe,ou=Hosts,ou=internal,dc=telkomsa,dc=net"
        credentials="nottherealpass"
updateref       ldap://192.168.3.100

index   entryCSN,entryUUID                      eq

index   objectClass,uid,uidNumber,gidNumber,memberuid   eq
index   cn,mail,surname,givenname               eq,subinitial

# indexes for qmail etc:
index infranetPoid                              eq,sub
index mailAlternateAddress,mailMessageStore     eq,sub


[...]

database meta
suffix "dc=cybertrade,dc=co,dc=za"
uri     ldap://localhost/dc=cybertrade,dc=co,dc=za
lastmod off
suffixmassage "dc=cybertrade,dc=co,dc=za" "dc=cybertrade,dc=co,dc=za,dc=isp"



The meta backend is there mainly for convenience at present, but the mail
servers have been (mis)configured to bind as a dn under the meta suffix
(dc=cybertrade,dc=co,dc=za) and search on the "real" suffix
(ou=mail,dc=cybertrade,dc=co,dc=za,dc=isp)

With this situation, we have been seeing crashes every 3 days to 3 weeks on both
slaves. The master has not been affected at all.

It seems at least one cause for instability is the bind to the meta backend,
since I have been able to reproduce this only when binding with the dn in the
meta suffix.

Stack trace is available at http://www.zarb.org/~bgmilne/bgmilne-20060112.txt .
gdb session currently open on the machine (but, we have a scheduled power cut
coming up over the weekend ...).