I have the openldap-data directory backed up but when I restored it and tried a slapcat, I got similar messages. I know little about LDAP, can anyone shed some light on what has happened?_________________"Ship me somewheres east of Suez, where the best is like the worst,
Where there ain't no Ten Commandments an' a man can raise a thirst"
from "Mandalay" by Rudyard Kipling

I found an old slapcat dump file and deleted the databases and reload from the ldif. Not very satisfactory but at least it's running with slightly old data. Always take a slapcat backup before upgrading openldap!_________________"Ship me somewheres east of Suez, where the best is like the worst,
Where there ain't no Ten Commandments an' a man can raise a thirst"
from "Mandalay" by Rudyard Kipling

Nevermind, fixed this. I ran /etc/init.d/slapd --debug start which gave me a lot of output but while combing through it I realized that I restored using slapadd as root, so the db was owned by root. I changed the ownership of the files inside my data directory and I'm good to go.

I just ran into the same problem (can't start slapd after updating open-ldap). I've had to recover ldap before, and know how to delete the db and restore it from an ldif dump, but this time I can't even run 'ldapdelete...' to clear the db. The attempt produces the following:

Is there something else perhaps that I need to kick before I can attempt the ldapdelete command? The openldap update came on the heels of the recent PAM update, if that matters. I'm always a little leary of rebooting when this kind of thing happens because I'm never sure I'll be able to get into the system again after the reboot if things are *really* off-kilter.

Update: I'm fairly well hosed at this point. I can't start slapd and I can't get ldapdelete to bind so that I can attempt to clear (and then restore) the database (on the assumption that the original message about the db being broken was correct).

The output from ldapdelete is in the previous post. Basically it just keeps saying: "ldap_bind: Can't contact LDAP server (-1)". I've re-emerged openldap, nss_ldap, openssl. I rebooted, which made no difference.

I don't know what to try at this point. Having the db wedged and requiring a recovery from ldif file was the worst I've had to deal with prior to this, so I don't have any tricks to use.

(note: I'm double-posting this from another thread that had a nearly identical ldap problem)

[SOLVED] well... if completely deleting the bdb folder and reconstructing the ldap db is 'solving' the problem.

I couldn't get any of the berkely tools to behave or apparently do anything constructive, so I just wiped the /var/lib/openldap-data folder, re-emerged openldap (just for good measure), and used slapadd to do a full repopulation of the ldap db from a nightly slapcat dump (ldif file).

Had this been a higher traffic production system, I'd probably be pissed. Though I now officially hate ldap. This is like the 4th or 5th time I've wasted hours recovering from some arcane breakage of what is proving to be an annoyingly fragile tool.

Although I didn't try it, it's very possible that if slapd is hosed, slapcat won't work to produce a proper ldif file either and the only solution would be to build openldap against a previous bdb version, dump, rebuild openldap against the current bdb version, and import. Otherwise, a bdb dump would have to be done, either as per Robin Johnson's comment in the cited bug, or as per the instructions at https://forums.gentoo.org/viewtopic-p-4487066.html#4487066 .

I used db4.2_dump to dump the db data and then db4.5load to reconstitute it. This seemed to work OK.

That was exactly the situation I was in -- slapd was totally inoperable. Clearly that prevents the creation of a new ldif dump using slapcat. Had I not already possessed nightly snapshots of the ldap db (in ldif format) I'd have been forced to pursue the db_dump/load approach described by bobcatt and fmouse.