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

Solved?!? Help, please! My OpenLDAP server stopped working!



Ok, I'm back in business I guess. What I did was:
1) /etc/init.d/openldapd stop (was actually already down)
2) cp -a openldap-data openldap-backup
3) cd openldap-data
4) db_recover -e
5) for i in *.bdb; do db_dump $i > d; rm $i; db_load $i < d; rm d; done
6) db_archive | xargs rm
7) /etc/init.d/openldapd start

All .bdb files besides id2entry.bdb and dn2id.bdb gave the following
error before db_dump/db_load:
enterprise# db_verify  oid.bdb
db_verify: Page 2: database has different custom hash function; reverify
with DB_NOORDERCHK set
db_verify: DB->verify: oid.bdb: DB_VERIFY_BAD: Database verification
failed

The LDAP server including all the data seems to be back up now. Question
is whether this is the right approach.  Comments?

--nk

On Fri, 2003-03-07 at 05:20, Howard Chu wrote:
> A hang probably indicates a locking conflict, but might also indicate a
> memory shortage. You should read the Berkeley DB documentation, look into the
> db_stat command, and examine the memory usage, cache effectiveness, all other
> statistics of your database environment. If you copied the raw database files
> directly from a running server directory to another directory, including the
> __db.* environment files, then you may have duplicated the images of some
> active locks, even though those locks aren't "live" in your new copy.
> Obviously, this is not the correct way to duplicate a slapd database - slapd
> must be shut down before you do anything to the raw database files.
> 
> "not really knowing what to do" - *always* read the documentation first.
> Taking action blindly seldom resolves anything.
> 
> You should never use OpenLDAP (or any other software package, for that
> matter) without reading both its docs *and* the docs for the database (and
> any other) library that you're using. Learn about all the pieces that went
> in, don't just slap 'em together, type "make" and forget about it.
> Sleepycat's BDB documentation is very thorough. Information is all at your
> fingertips, there's no excuse for ignorance.
> 
>   -- Howard Chu
>   Chief Architect, Symas Corp.       Director, Highland Sun
>   http://www.symas.com               http://highlandsun.com/hyc
>   Symas: Premier OpenSource Development and Support
> 
> > -----Original Message-----
> > From: owner-openldap-software@OpenLDAP.org
> > [mailto:owner-openldap-software@OpenLDAP.org]On Behalf Of
> > Norbert Kiesel
> > Sent: Friday, March 07, 2003 4:25 AM
> > To: openldap-software@OpenLDAP.org
> > Subject: Help, please! My OpenLDAP server stopped working!
> >
> >
> > Hi,
> > I'm at a complete loss.  We are using OpenLDAP for about 6 month now
> > with good results (currently 2.1.10 / bdb.4.1.25 on Solaris7).  Since
> > 2 days the server got suddenly very slow (30 sec for 1 sublevel search
> > with (objectClass=*).  Not really knowing waht to do, I compiled a new
> > 2.1.14 using gcc-2.95, and copied the openldap-data/* files to the new
> > server and started it.  The server starts fine, but on login hangs in
> > login:
> > do_bind: version=3 dn="cn=Manager,o=tbdnetworks.com" method=128
> > conn=0 op=0 BIND dn="cn=Manager,o=tbdnetworks.com" method=128
> > ==> bdb_bind: dn: cn=Manager,o=tbdnetworks.com
> > bdb_dn2entry_rw("cn=manager,o=tbdnetworks.com")
> > => bdb_dn2id_matched( "cn=manager,o=tbdnetworks.com" )
> >
> > I also tried to reindex the data using slapindex, but this also hangs
> > (both under 2.1.10 and 2.1.14):
> > slapindex startup: initiated.
> > backend_startup: starting "o=tbdnetworks.com"
> > bdb_db_open: o=tbdnetworks.com
> > bdb_db_open: dbenv_open(/opt/OpenLDAP-2.1.14/var/openldap-data)
> > indexing id=000000ea
> > => bdb_tool_entry_reindex( 234 )
> > entry_decode: "o=tbdnetworks.com"
> > <= entry_decode(o=tbdnetworks.com)
> > => bdb_tool_entry_reindex( 234, "o=tbdnetworks.com" )
> > => bdb_dn2id_add( "o=tbdnetworks.com", 0x000000ea )
> >
> > Any ideas?  I'd really hate to switch back to i-Planet :-(
> >
> > --nk
> >
> >
-- 
Norbert Kiesel <nkiesel@tbdnetworks.com>
TBD Networks