[Date Prev][Date Next]
Re: two problems when migrating from 2.1.30 to 2.2.15
I have applied patch which you have mentioned in your email. I have
applied it to Berkeley DB 4.2.52-no-cryptography-patch2 and
openldap-2.2.15. "make test" of openldap fails like this:
backend_startup: starting "o=OpenLDAP Project,l=Internet"
bdb_db_open: o=OpenLDAP Project,l=Internet
bdb_db_open: db_open(./testrun/db.1.a) failed: Unknown error: 512 (512)
backend_startup: bi_db_open failed! (512)
slapd shutdown: initiated
slapd shutdown: freeing system resources.
bdb(o=OpenLDAP Project,l=Internet): Database handles open during
bdb_db_destroy: close failed: Invalid argument (22)
connections_destroy: nothing to destroy.
Do you know if it is expected result? Or am I doing something wrong? It
seems that you prepared patches against CVS head for both openldap and
Actually, I am looking for using openldap-2.2.15 because it allows to
specify "limits" via groups. I also can not allow myself to accomulate
log files as I get 100s of them. If it is such a big problem for me to
get 2.2.x to work properly, would it be realistic from your point of
view to get that "limits" functionality from 2.2.x in 2.1.30? Of course,
a patch for this from openldap.org would be best solution -:)
Thanx a lot and best regards, vadim tarassov.
On Mon, 2004-09-06 at 03:55, Howard Chu wrote:
> vadim wrote:
> > Hallo everybody,
> > I am trying to move from 2.1.30 to 2.2.15. I've met two problems, which
> > I can not identify as mine at the moment, and I want to know what do you
> > think about it ...
> > 2) I had string "set_flags DB_LOG_AUTOREMOVE" in my DB_CONFIG file. This
> > was making berkeley db to remove all unused log files after next
> > checkpoint. With 2.2.15 this parameter in DB_CONFIG does not make any
> > effect, log files remain on file system. Do you know if something has
> > changed?
> Yes, in order to fix a locking problem in back-bdb the cache code was
> changed to use a long-lived transaction per slapd thread to handle
> read-only operations. Unfortunately BDB 4.2.52 has a bug where these
> long-lived transactions prevent the DB_LOG_AUTOREMOVE option from
> working. They also prevent db_archive from doing anything useful.
> I posted a patch to BDB 4.2.52 that will allow it to work properly when
> a special option flag is used in the back-bdb code. 4.3 already works
> correctly by default, so no special option is needed there, but I don't
> believe it has been released yet.
> There was a long discussion of this problem on the -devel list, you can
> get some of it here:
> The patches are in this message:
> Keep in mind that if you use these patches, you will need to undo the
> patch to back-bdb when you migrate to BDB 4.3.