Failed to start sldap

Discuss your pilot or production implementation with other Zimbra admins or our engineers.
Post Reply
GANECA
Posts: 5
Joined: Mon Sep 07, 2020 2:35 am

Failed to start sldap

Post by GANECA »

I got a problem with my Zimbra after restarting the machine.

When I run 'zmcontrol start', an error message appears
Failed to start slapd. Attempting debug start to determine error.
6096c2b8 hdb_db_open: database "": db_open(/opt/zimbra/data/ldap/hdb/db/id2entry.bdb) failed: Invalid argument (22).
6096c2b8 backend_startup_one (type=hdb, suffix=""): bi_db_open failed! (22)
6096c2b8 bdb_db_close: database "": alock_close failed
Then I try run db_recover -vc, here's the results
db_recover: file unknown has LSN 136/8019471, past end of log at 136/3529981
db_recover: Commonly caused by moving a database from one database environment
db_recover: to another without clearing the database LSNs, or by removing all of
db_recover: the log files from a database environment
db_recover: file unknown has LSN 136/8019471, past end of log at 136/3529981
db_recover: Commonly caused by moving a database from one database environment
db_recover: to another without clearing the database LSNs, or by removing all of
db_recover: the log files from a database environment
db_recover: file unknown has LSN 136/8019471, past end of log at 136/3529981
db_recover: Commonly caused by moving a database from one database environment
db_recover: to another without clearing the database LSNs, or by removing all of
db_recover: the log files from a database environment
db_recover: file unknown has LSN 136/8019471, past end of log at 136/3529981
db_recover: Commonly caused by moving a database from one database environment
db_recover: to another without clearing the database LSNs, or by removing all of
db_recover: the log files from a database environment
db_recover: file unknown has LSN 136/8019471, past end of log at 136/3529981
db_recover: Commonly caused by moving a database from one database environment
db_recover: to another without clearing the database LSNs, or by removing all of
db_recover: the log files from a database environment
Recovery complete at Sun May 9 00:20:16 2021
Maximum transaction ID 80002618 Recovery checkpoint [136][3529981]
at the end of line, its say 'Recovery Complete', but sldap still not running :(

zmcontrol -v
Release 7.2.0_GA_2669.RHEL6_64_20120410002025 CentOS6_64 FOSS edition.
please help me find solution,
thanks
GANECA
Posts: 5
Joined: Mon Sep 07, 2020 2:35 am

Re: Failed to start sldap

Post by GANECA »

found this helpful article, now my Zimbra alive following those step :D

thanks tcg.com
https://www.tcg.com/blog/emergency-reco ... -openldap/
As root run:

/etc/init.d/zimbra stop

cd /opt/zimbra/data/ldap/hdb/db/
/opt/zimbra/bdb‑4.7.25.4/bin/db_recover ‑v

/opt/zimbra/libexec/zmfixperms –extended

/etc/init.d/zimbra start

If that doesn’t work, db_recover has a “catastrophic” mode:

/opt/zimbra/bdb‑4.7.25.4/bin/db_recover ‑cv

However, if “catastrophic” mode returns errors like:

db_recover: Commonly caused by moving a database from one database environment
db_recover: to another without clearing the database LSNs, or by removing all of
db_recover: the log files from a database environment

then to get the logs happy, you may need to dump and re-import some specific databases (typically the id2entry.bdb file which is very active):

cd /opt/zimbra/data/ldap/hdb/db/
/opt/zimbra/bdb/bin/db_dump id2entry.bdb > foo.txt
cp id2entry.bdb id2entry.bdb.bak
cat foo.txt | /opt/zimbra/bdb/bin/db_load id2entry.bdb

With all of this, I was able to get LDAP (slapd) up and running. Oddly enough, after a couple of minutes slapd would PANIC (using that word in zimbra.log) and shutting down with a BDB inconsistency. Fortunately because I was able to get it to run for a couple of minutes, I used that time to perform a full LDAP dump and restore. In addition, this is a great way to conduct periodic backups of LDAP to speed recovery in the future (so if you are running the community version of Zimbra, add the backup command to a cron job!). To create a live dump of LDAP while it is running, run:

su — zimbra
/opt/zimbra/libexec/zmslapcat /opt/zimbra/backup

Then, to restore (or fully reconstruct) the LDAP database:

su — zimbra
# stop zimbra
zmcontrol stop
# Make the DB directories
mv /opt/zimbra/data/ldap/hdb /opt/zimbra/data/ldap/hdb.old
mkdir /opt/zimbra/data/ldap/hdb
mkdir ‑p /opt/zimbra/data/ldap/hdb/db \
/opt/zimbra/data/ldap/hdb/logs
cp /opt/zimbra/data/ldap/hdb.old/db/DB_CONFIG \
/opt/zimbra/data/ldap/hdb/db/DB_CONFIG
# Restore the backup you made to create a nice and clean BDB set
/opt/zimbra/openldap/sbin/slapadd ‑q ‑b “” ‑F \
/opt/zimbra/data/ldap/config ‑cv ‑l /opt/zimbra/backup/ldap.bak
# Start zimbra
zmcontrol start

Once I performed this step of backup and recovery, LDAP finally behaved correctly.

I hope this saves you time (and stress)!
Post Reply