On Fri, 2005-03-04 at 09:47 +0000, Nigel Wade wrote: > Daniel Durgin wrote: > > Hi, > > > > I been running this ldap server for about a month now. > > Last night it died for some reason. So I restarted > > the service. No errors on start up. > > > > But, now I can't connect with any client. Here's the > > kicker. The slapd is running, but port 389 and 636 > > are closed. I used nmap, those ports open. Telneting > > into those ports was also futile. > > > > This should not be a firewall issue. I have already > > opened the ports and have been using ldap for about a > > month. > > > > I also tried starting slapd manually with all debug > > info. I haven't seen any errors yet. > > > > I have check /var/log/messages too, nothing. > > > > Any Ideas? > > > > - Dan > > > > P.S. FC3, standard ldap rpm: openldap-2.2.13-2 > > > > > I think that's an indication of the backend database hanging. First, shut > down slapd. Make a complete backup of /var/lib/ldap. Then remove the files > in /var/lib/ldap which begin with __ (most likely __db.001, __db.002 etc.). > Try starting slapd again. > > I think it's something to do with persistent locks which get messed up if > the backend database isn't shutdown properly. > > If this fails you may need to re-build the backend database from an ldif > source (you have an ldif backup, I hope). ---- removing __db.00* files seems to be a bit expedient and may be fatal to a db that is cached and checkpointed but doesn't have changes written to db. There are db tools for that - db_verify - db_recover. I would probably suggest that someone 'cd /var/lib/ldap && db_verify && db_recover' instead. I stopped using openldap from Red Hat and started compiling from source so I tend to use db log files and DB_CONFIG files to optimize my setup and don't know what Fedora does in default settings. Of course suggestion to delete __db.00* might be effective in getting ldap running again and recent changes may be less important but that is an OP judgment call. And yes, it's always good to have slapcatted the db to an ldif at regular intervals to handle db_corruption issues proactively. Craig
