You can tell REAL FAST if it's the backend database by archiving the database files and starting slapd and then restoring a backup via slapcat or ldapadd. If that works then the database files were corrupted in some way.
-- Puryear Information Technology, LLC Baton Rouge, LA * 225-706-8414 http://www.puryear-it.com Author, "Best Practices for Managing Linux and UNIX Servers" http://www.puryear-it.com/pubs/linux-unix-best-practices Identity Management, LDAP, and Linux Integration Josh M. Hurd wrote: > I haven't found the version of BDB yet. Anyone know an easy way to do > this? > > My DB_CONFIG is basically the example that comes with OpenLDAP: > > # $OpenLDAP: pkg/ldap/servers/slapd/DB_CONFIG,v 1.1.2.3 2006/08/17 > 17:36:19 kurt Exp $ > # Example DB_CONFIG file for use with slapd(8) BDB/HDB databases. > # > # See Sleepycat Berkeley DB documentation > # <http://www.sleepycat.com/docs/ref/env/db_config.html> > # for detail description of DB_CONFIG syntax and semantics. > # > # Hints can also be found in the OpenLDAP Software FAQ > # <http://www.openldap.org/faq/index.cgi?file=2> > # in particular: > # <http://www.openldap.org/faq/index.cgi?file=1075> > > # Note: most DB_CONFIG settings will take effect only upon rebuilding > # the DB environment. > > # one 0.25 GB cache > set_cachesize 0 268435456 1 > > # Data Directory > #set_data_dir db > > # Transaction Log settings > set_lg_regionmax 262144 > set_lg_bsize 2097152 > #set_lg_dir logs > > # Note: special DB_CONFIG flags are no longer needed for "quick" > # slapadd(8) or slapindex(8) access (see their -q option). > > > This was the next thing I was going to look. > > > On Oct 11, 2007, at 2:40 PM, Aaron Richton wrote: > >> If you're binding as the rootdn successfully, it's probably only that >> given bdb backend that's faulty. Can you track down the Sleepycat >> library you're using (perhaps using ldd), and find out what version it >> is? >> >> At risk of my getting shot by Howard, are you caring for your >> Sleepycat log files properly? DB_CONFIGs for autoremove, or are there >> cron jobs for db_archive, etc.? What are your DB_CONFIGs, for that >> matter? (They'd have to be pretty far off to cause this behavior, but >> it's a quick look at least.) >
