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

Re: Corrupt LDAP DB ...

On Sunday 06 November 2005 02:38, Jose Ildefonso Camargo Tolosa wrote:

> > I use Red Hat, but I use the Mandriva packages (which I maintain)
> > rebuilt on Red Hat (RHEL3 and RHEL4, our RHEL2.1 boxen still have
> > packages based on the RH 2.0.27 packages from RHEL3 but heavily
> > modified). My 2.3.11 packages for RHEL are available ...
> Yep, but that makes you loose the "warranty" over the packages.

RHs support of OL 2.0.27 on RHEL2.1 and RHEL3 wasn't good enough to warrant 
keeping their packages to be "supported" when we could build our own packages 
and not need support.

> As I 
> said: I don't use RedHat since version 8.0 (RedHat 8.0) and I tried
> Fedora Core 1 and 2, then I decided no to waste my time using them.
> RHEL gives a "warranty" over the binaries, but only if you use the
> "repository" packages, when you install a 3th party package, you loose
> the warranty over the packages you replace and the packages wich
> depends on them.

You'll notice my packages don't replace any RH packages. They install in 
parallel. No other packages will be affected.

> > I assume that by "berkley" you actually mean OpenLDAP on bdb ...
> Nope, everything that uses berkley requrires a DB enviroment
> configuration, whether you configure it with "DB_CONFIG", or you "hard
> code" it, you *have* to configure your DB enviroment.

Well, ldbm with Berkeley DB doesn't require a DB_CONFIG file or DB 
configuration (besides the dbcachesize etc) or run with a Berkely DB 
environment, and any other software using "berkely" is off-topic for this 

> > This sounds very much like your slapd is being stopped badly, and not
> > having database recovery run for its databases.
> Please, read correctly: clean shutdowns (exit with signal 15, not 9,
> nor power fail, nor system crash).  I have had this problem even with
> a "no shutdown" database, just sit there, an uptime of 23 days, and
> then you have some database problems, I have experienced this
> (recently) in gentoo, at the moment debian sarge is just fine.  This
> is most likely caused by "locks", or something like that (the thing is
> that, when you take a look at the DB locks, you are not out of locks!,
> but then you shutdown openldap and run db_recovery, and everything
> works fine again).

Well, as I said, other distros run database recovery in their init scripts, 
which it seems would solve this problem for you (and is probably the reason 
it is working on Debian). If you run into a problem like this when the 
database is up, it's likely that you've run out of database environment 
space, bump up the cache size ... 

> > Note that 2.3.x recovers databases at startup, but for 2.1.x and 2.2.x
> > manual db_recover is needed if it is likely that slapd could not
> > cleanly close all its databases. Debian's init script does this (I
> > think you may have to configure it to do so in /etc/default/slapd),
> > Mandriva's init script does this by default for 2.2.x (can't remember
> > for old 2.1.x packages).
> Once again, read completly

I did, which is exactly why I mentioned these facts (to explain why you see 
problems on one distro and not on the other).

> , I have already said that Debian Sarge's 
> OpenLDAP works just fine.  I was playing around with gentoo, and just
> saw that problem, and i'm trying to isolate it (just to contribute
> with an usefull bug report).

The problem is them using 2.2 and 2.1 without running database recovery in the 
initscript, or your DB_CONFIG.


Buchan Milne
ISP Systems Specialist

Attachment: pgpjnwDKyHelf.pgp
Description: PGP signature