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

openldap23 w/ bdb43 entryCSN eq index prob



I am having problems indexing entryCSN.  It appears whenever I shutdown
slapd and then restart it, my bdb database is getting corrupt.  I am
running freebsd 5.4 with openldap 2.3.4 and bdb 4.3.28.  This happens with
both bdb and hdb backends, I haven't tried any others.

Here is what happens.

First, I turn up slapd and do an import of 4 entries (keeping it small for
testing).  Then I shutdown slapd (using the startup script).  When I
restart slapd, it shows that slapd is started in the logs, however, the
process isn't actually running.  Then when I try to start again I get bdb
errors in the logfile.  A db_recover isn't enough to fix the db.

I ran this in full debug (-1) to see what was happening.

This is after I imported the 4 entries and then shut it down.

bdb_modify: updated id=00000001 dn="dc=mydomain,dc=com"
send_ldap_result: conn=-1 op=0 p=0
send_ldap_result: err=0 matched="" text=""
====> bdb_cache_release_all
slapd destroy: freeing system resources.
slapd stopped.

When I restart in debug mode, I get a segmentation fault.

=> bdb_entry_get: found entry: "dc=mydomain,dc=com"
bdb_entry_get: rc=0
=> bdb_search
bdb_dn2entry("dc=mydomain,dc=com")
search_candidates: base="dc=mydomain,dc=com" (0x00000001) scope=2
=> bdb_dn2idl("dc=mydomain,dc=com")
=> bdb_filter_candidates
        AND
=> bdb_list_candidates 0xa0
=> bdb_filter_candidates
        GE
=> bdb_inequality_candidates (entryCSN)
=> key_read
Segmentation fault

Running this in non-debug mode, shows a different picture - using loglevel
256 in slapd.conf

after adding the 4 entries.
Jun 25 01:15:37 ldapm slapd[15411]: daemon: shutdown requested and
initiated.
Jun 25 01:15:37 ldapm slapd[15411]: slapd shutdown: waiting for 0 threads
to terminate
Jun 25 01:15:37 ldapm slapd[15411]: slapd stopped.

starting back up, shows it starts, but the process isn't actually running.

Jun 25 01:16:08 ldapm slapd[15437]: @(#) $OpenLDAP: slapd 2.3.4 (Jun 24
2005 17:42:54) $
root@ldapm.lab.soc.int:/usr/ports/net/openldap23-server/work/openldap-2.3.4/servers/slapd

try starting again

Jun 25 01:16:23 ldapm slapd[15451]: bdb_db_open: unclean shutdown
detected; attempting recovery.

notice the error and run db_recover in the openldap-data dir and try again

Jun 25 01:17:15 ldapm slapd[15465]: @(#) $OpenLDAP: slapd 2.3.4 (Jun 24
2005 17:42:54) $
root@ldapm.lab.soc.int:/usr/ports/net/openldap23-server/work/openldap-2.3.4/servers/slapd
Jun 25 01:17:15 ldapm slapd[15466]: bdb_db_open: unclean shutdown
detected; attempting recovery.
Jun 25 01:17:15 ldapm slapd[15466]: bdb_db_recover: Database cannot be
recovered. Restore from backup!
Jun 25 01:17:15 ldapm slapd[15466]: bdb_db_open: DB recovery failed.
Jun 25 01:17:15 ldapm slapd[15466]: backend_startup_one: bi_db_open
failed! (-1)

Even if I run db_recover before the initial restart, I get the same
problem.

So, I removed the entryCSN equality index, delete all the db files,
slapd.d files, etc and start over.  Now it restarts fine, but I get the
following warning in the logfile.

Jun 25 01:18:31 ldapm slapd[15520]: @(#) $OpenLDAP: slapd 2.3.4 (Jun 24
2005 17:42:54) $
root@ldapm.lab.soc.int:/usr/ports/net/openldap23-server/work/openldap-2.3.4/servers/slapd
Jun 25 01:18:31 ldapm slapd[15521]: <= bdb_inequality_candidates:
(entryCSN) index_param failed (18)
Jun 25 01:18:31 ldapm slapd[15521]: slapd starting

Everything works at this point, but the entryCSN is not indexed as
suggested in the admin guide for replication using syncrepl.

Here is relevant slapd.conf config.  The entryCSN is commented out on this
copy/paste.

database        bdb
suffix          "dc=mydomain,dc=com"
rootdn          "cn=root,dc=mydomain,dc=com"
rootpw          secret
directory       /var/db/openldap-data
# Indices to maintain
index   objectClass     eq
index   uid             eq
index   entryUUID       eq
#index  entryCSN        eq

cachesize       10000
idlcachesize    30000
checkpoint      1024 5

overlay syncprov
syncprov-checkpoint     100 10
syncprov-sessionlog     100

Any ideas?  Need more info?  Is it correct to index entryCSN for syncrepl?

Thanks

Dusty Doris