ldapsearch hang on OpenLDAP 2.3

[William Jojo <w.jojo@hvcc.edu>]

Now I know that 2.4 is the recommended level, however, this system is not ready to be converted (yet).

It's running 2.3.39 on AIX 5.3 (BDB 4.4.20 with all patches) and in the master in a master/slave (slurpd) environment. I could upgrade to 2.3.43 (if you think it will help), but we are planning moving it to 2.4 soon.

We had an issue with an ldapsearch that would not finish - it connected, but failed to return information.

When I "truss"-ed the pid, it was switching between threads but acted like 

The slapd daemon responded to kill -HUP and stopped successfully. db_recover was:

[svc1:/ldap/db/database] # /opt/pware/bin/db_recover -v -h .
Finding last valid log LSN: file: 545 offset 8672731
Recovery starting from [545][8672586]
Recovery complete at Wed Sep  9 15:22:45 2009
Maximum transaction ID 8005cffa Recovery checkpoint [545][8672731]


Then we ran a script that stops the DB and does an export (which looks good) and tars up the db files and log file. Shortly thereafter searching for the same entry cause a hang, but slapd stopped successfully. Then ran db_recover again:

[svc1:/ldap/db/database] # db_recover -v -h .
Finding last valid log LSN: file: 545 offset 8900926
Recovery starting from [545][8900781]
Recovery complete at Wed Sep  9 15:29:37 2009
Maximum transaction ID 800000ad Recovery checkpoint [545][8900926]

Unfortunately we had the log level set to 0, so we never saw the details in syslog. Is 256 the correct value (which logs quite a bit of stuff) for a busy server?

Is this a corrupt environment? Corrupt index? Should we remove the environment and reindex the database? We are trying to avoid reloading from the export, if possible.

Again, we are just trying to breathe some life into this server for the short term as moving to 2.4 right this minute has other implications we just can't change at the moment.

Appreciate any ideas on this.


Cheers,
Bill