HELP: ldap comes to screeching halt

Craig White craigwhite at azapple.com
Tue Feb 1 16:08:57 UTC 2005


On Tue, 2005-02-01 at 09:47 -0600, Brian Fahrlander wrote:
> On Tue, 2005-02-01 at 08:08 -0700, Craig White wrote:
> > cd /var/lib/ldap #or wherever your ldap *.dbd files are located
> > db_recover
> 
>     It was strangely quiet. I tried it in /var/lib/ldap and in the
> directory where my data's located....very quiet. Shouldn't it report
> something?
----
it might log something in syslog or other log  -  otherwise proof is in
the pudding - service ldap restart either works or doesn't work. Of
course, it may not be damaged dbd files at all - see other message about
logging...logging is your friend and typically the way to find out what
is wrong.
----
> > does your slapd.conf use ldbm or dbd? - that may be an important
> > question
> 
>     It's bdb.  Lucky I changed to that, I suppose.
----
yes, helps to log (dbd logs are different from ldap logging) and
checkpoint - make db_recover much more effective
----
>     
> > grep ldbm /etc/openldap/slapd.conf
> > grep dbd /etc/openldap/slapd.conf
> > 
> > one of those is going to tell you this
> > 
> > and db_recover - I'm not sure how/if it works with ldbm
> 
>    Well I sure appreciate your help; I'd otherwise have no recourse, I
> suppose...
----
Set up ldap to log as per previous. Start ldap service - look at logs -
problem should be evident

If dbd files are hosed, then delete them - perhaps only an index or two
are hosed, you can delete those files and re-index (slapindex) fix the
permissions, start ldap and you're on your way. If the main db is
damaged and can't be fixed by db_recover, then you will have to toast
the files and reload from your last slapcat (you do slapcat once in a
while don't you?)

Craig




More information about the fedora-list mailing list