[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
No, that is not the expected result. I've never seen that before, it
appears that you patched or built things wrong but I don't know what you
might have done. Note that db_open is called before any part of my
patches are run, so it seems your problem is unrelated.
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 -:)
2.1 is now officially dead. There will be no more patches released for 2.1.
Thanx a lot and best regards, vadim tarassov.
On Mon, 2004-09-06 at 03:55, Howard Chu wrote:
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
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.
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
Symas: Premier OpenSource Development and Support