I am having a hard time understanding how exactly mdb_env_sync should
be used. Suppose I have an environment with MDB_NOSYNC and I do not use
MDB_WRITEMAP. I still want to sync at some points, which is why
mdb_env_sync exists. But I wonder:
- How does it interact with transactions? Is it safe (or necessary) to
call it outside of a transaction? During a read-only transaction?
During a write transaction?
- What about thread safety? Can it be called concurrently with writes?
Can it be called concurrently with another mdb_env_sync in another
I tried to deploy openldap replica on Ubuntu 14.04. I copy database via
slapcat(slapadd) and slapd.conf from another replica(Centos 6.7 with
OpenLDAP: slapd 2.4.40).
After all slaptest errors were fixed slapd service run once, but after 5
minutes without any changes it's failed to start again and currently
it's still doesn't work. I can't find any ldap log.
May be somebody faced with such kind of the problem. Will be very
appreciate for any advices
With Best Wishes
CONFIDENTIALITY NOTICE: This email and files attached to it are
confidential. If you are not the intended recipient you are hereby notified
that using, copying, distributing or taking any action in reliance on the
contents of this information is strictly prohibited. If you have received
this email in error please notify the sender and delete this email.
I am new to use OpenLdap and I want to import/include new .schema file into
my OpenLdap database but I don't how.
Could you please point some useful links dealing with this issue or tell me
how shall I proceede ?
Thanks in advance.
I have a problem appearing where a large (16.6MB approx) value is to be
saved to an attribute (certificateRevocationList).
Prior to the value being this large, ldapmodify had no problems updating
it. However it appears to have crossed some magic threshold where it
will no longer be accepted, and aborts with: ldap_modify: Can't contact
LDAP server (-1)
The ldapmodify operation is being performed on the ldap host machine
using the ldap root user with simple password authentication.
Openldap version is 2.4.30 using back-bdb with Linux OS (2.6.32 64 bit).
There is no replication configured. It's a fairly simple setup.
I've seen a couple of similar threads alluding to the same problme,
however without any solution.
I'm curious to know where the limit is that is causing the sudden
inability for ldapmodify to complete.
Nothing was immediately apparent after a quick look through some of the
Also, if the issue is a known one, was it addressed in a newer release?
I can run the same test on a machine with openldap-2.4.40 to see if it
persists if that is of any help.
I have a few ubuntu 14.04 servers running slapd 2.4.31 installed from
Now I want to upgrade these servers to last openldap version, so I I
have downloaded 2.4.43 and compiled from myself. Since then, whenever I
tri to make a change in the config, slapd crashes with:
Dec 11 08:34:56 canis30 slapd: conn=1000 op=0 RESULT tag=97 err=0
Dec 11 08:34:56 canis30 slapd: conn=1000 op=1 MOD
Dec 11 08:34:56 canis30 slapd: conn=1000 op=1 MOD
attr=olcDbcheckpoint olcDbindex olcDbNosync olcDbcachesize
olcDbidlcachesize olcDbConfig olcDbNosync olcDbshmkey olcDbcachesize
olcDbcheckpoint olcDbidlcachesize olcDbConfig olcDbindex
Dec 11 08:34:56 canis30 slapd: bdb(dc=Telematica): BDB4511 Error:
closing the transaction region with active transactions
Dec 11 08:34:56 canis30 slapd: bdb_db_close: database
"dc=Telematica": close failed: Invalid argument (22)
Dec 11 08:34:56 canis30 slapd: hdb_cf_cleanup: failed to reopen
Dec 11 08:34:56 canis30 slapd: daemon: abnormal condition,
Dec 11 08:34:56 canis30 slapd: slapd shutdown: waiting for 1
operations/tasks to finish
Dec 11 08:34:56 canis30 slapd: conn=1000 op=1 RESULT tag=103
err=80 text=failed to reopen database, rc=22
Dec 11 08:34:56 canis30 slapd: conn=1000 fd=13 closed (slapd shutdown)
Dec 11 08:34:56 canis30 kernel: [ 876.777046] slapd: segfault at
e0 ip 00007f7efcd86ac2 sp 00007ffd843c2fe0 error 4 in
I have tried with my own openldap compilation and with the package
installed from rtandy ppa, with the same results.
Although the upgrade procedure recreate the databases, I have also
tried to completely remove the database (dc=telematica), but it fails too.
I have tried with different ldifs, and the problem seems to happen
whenever a try to make a modification for the olcDbConfig attributes.
Angel L. Mateo Martínez
Sección de Telemática
Área de Tecnologías de la Información
y las Comunicaciones Aplicadas (ATICA)
according to this list a change of a structural object class should work
# ldapmodify -E relax
OID of relax control is 184.108.40.206.4.1.4203.666.5.12, right?
My servers do not advertise this control, do they?
# extended LDIF
# base <> with scope baseObject
# filter: (objectClass=*)
# requesting: +
Do I have to activate the relax control on any way to get this working?
I have a question about mdb_dbi_open and the handles it returns. The
official documentation suggests to me that mdb_dbi_open is supposed to be
called early on and then the obtained handle should just be reused by other
transactions without any further calls to mdb_dbi_open and mdb_dbi_close.
The code in sample-mdb.txt does that (ignoring the final close-all
The sample also uses mdb_txn_abort to end a read-only transaction, which I
take as the recommended way to end read-only transactions. The docs state
that if a transaction aborts, then the associated DBI handles are closed,
and so mdb_dbi_open must be used again to obtain a valid handle, which, as
far as I can tell, requires a process-wide serialization of transactions
with calls to mdb_dbi_open. Which feels contrary to the style described
above, and, more importantly, just wrong with read-only transactions,
because the need to serialize them would negate the benefits of LMDB's
Which probably means I misunderstand something. Can read-only transactions
keep DBI handles reusable? How?
I am looking for advice about how to best handle LMDB transactions and to avoid
pitfalls. Our application is multi-threaded, with several threads accessing
persistent data in a streaming fashion (reading lots of data sequentially). I am
also not sure that it will be practical to stick with one transaction per
thread, so MDB_NOTLS may be needed.
In this scenario, there are few "natural" transaction boundaries, which is why I
am asking when or how often a commit/abort (or reset/renew) should be issued.
Also, is there any issue with multiple individual read transactions being opened
from different places in the application?