Actually to start with, try using the correct db_recover binary while in the data directory. If that fails, then remove the alock file and see if slapd will start. Sadly not uncommon for alock to report problems incorrectly.

But agree, best thing to do after those steps is move to back-mdb on a current release.

--Quanah

On Dec 20, 2016, at 1:41 PM, Clément OUDOT clem.oudot@gmail.com wrote:

2016-12-20 22:35 GMT+01:00 Singley, Norman Norman.Singley@mso.umt.edu:

...

Thanks. Here are the results. I can start googling this result, but I am kind of a newbie at openldap, so if you know something obvious, let me know. Thank you very much.

# service slapd debug slapd: [INFO] Using /etc/default/slapd for configuration slapd: [INFO] Halting OpenLDAP... slapd: [INFO] Can't read PID file, to stop OpenLDAP try: /etc/init.d/slapd forcestop slapd: [INFO] No db_recover done slapd: [INFO] Launching OpenLDAP... slapd: [OK] File descriptor limit set to 1024 5859a359 @(#) $OpenLDAP: slapd 2.4.36 (Apr 8 2014 12:06:19) $ username@itds120.umt.edu:/u01/app/openldap-2.4.36/servers/slapd 5859a359 hdb_db_open: database "dc=umt,dc=edu": alock package is unstable. 5859a359 backend_startup_one (type=hdb, suffix="dc=umt,dc=edu"): bi_db_open failed! (-1) 5859a359 slapd stopped

The database seems corrupted.

You can try to slapcat to get a backup of the data (or try service slapd backup). Then remove all files and reimport data with slapadd (or try service slapd restore).

You should then try to upgrade to 2.4.44 and use LMDB backend.

Clément.