LMBD questions (stat & copy)
by Bruno Freudensprung
Hi,
I am trying to detect MDB_MAP_FULL based on mdb_stat(txn, dbi, &stat) results and I am wondering if I am on the right track or doing things correctly.
I have a small and simple test program (http://pastebin.com/SPCYgWMC) exhibiting the following behavior (consistent between Windows 7 64-bit and Ubuntu 15.10 64-bit - latest version of lmdb cloned and recompiled on Linux):
* Inserting 20990 key value pairs in a database is OK when using one transaction. Just before commiting the write transaction, mdb_stat(txn, dbi, &stat) shows that the total number of pages (253) is very close the the number of pages of the map (256). Indeed, adding another entry leads to MDB_MAP_FULL. To put it shortly, this scenario looks OK (I am assuming there might be 3 "internal-purpose" pages not shown by mdb_stat) and can be tested by setting the stat_test variable to 0 at line 20 of the test program.
* Inserting same 20990 key value pairs in a database fails (MDB_MAP_FULL encountered at 19357) when using two consecutive write transactions. Just before MDB_MAP_FULL, mdb_stat(txn, dbi, &stat) shows that the total number of pages (232) is "quite far" from the the number of pages of the map (256), leading my MDB_MAP_FULL detection heuristic to fail. It means that only 92% of the total amount of data can be sucessfully added to the database. Other scenarii (with same key/value lengths though) stop at 85% only. This can be tested by setting the stat_test variable to 1 (line 20).
By "total number of pages" I mean ms_branch_pages + ms_leaf_pages + ms_overflow_pages.
Do you think I am on a wrong track? (maybe mdb_stat does not show 24 "internal-purpose" pages in the second case? or I am forgetting something?).
One last remark: it seems that mdb_env_copy(db, copy_dir) is possible during a write transaction on Windows (like stated in the documentation), but not on Linux (the test program seems to be stopped on a mutex at line 62). This can be tested by changing the copy_test variable to 1 at line 19. Is it expected given my program?
Best regards,
Bruno.
7 years, 11 months
slapd dies
by BÖSCH Christian
hi,
i have two openldap servers 2.4.43 on freebsd 10.2 with multimaster replication.
if i add on one node a dynamicobject, the other node dies immediatly.
has anybody an idea?
regards,chris
---
added this:
dn: uid=vkw-guest,ou=people,o=abc.net
sn: VKW Guest
objectClass: organizationalPerson
objectClass: person
objectClass: dynamicObject
objectClass: inetLocalMailRecipient
objectClass: inetOrgPerson
objectClass: top
uid: vkw-guest
cn: VKW Guest
the log says:
Jan 13 13:08:40 openldap2 slapd[75017]: daemon: activity on 1 descriptor
Jan 13 13:08:40 openldap2 slapd[75017]: daemon: activity on:
Jan 13 13:08:40 openldap2 slapd[75017]: 30r
Jan 13 13:08:40 openldap2 slapd[75017]:
Jan 13 13:08:40 openldap2 slapd[75017]: daemon: read activity on 30
Jan 13 13:08:40 openldap2 slapd[75017]: daemon: select: listen=6 active_threads=0 tvp=zero
Jan 13 13:08:40 openldap2 slapd[75017]: daemon: select: listen=7 active_threads=0 tvp=zero
Jan 13 13:08:40 openldap2 slapd[75017]: daemon: select: listen=8 active_threads=0 tvp=zero
Jan 13 13:08:40 openldap2 slapd[75017]: daemon: select: listen=9 active_threads=0 tvp=zero
Jan 13 13:08:40 openldap2 slapd[75017]: daemon: select: listen=10 active_threads=0 tvp=zero
Jan 13 13:08:40 openldap2 slapd[75017]: connection_get(30)
Jan 13 13:08:40 openldap2 slapd[75017]: connection_get(30): got connid=0
Jan 13 13:08:40 openldap2 slapd[75017]: =>do_syncrepl rid=021
Jan 13 13:08:40 openldap2 slapd[75017]: =>do_syncrep2 rid=021
Jan 13 13:08:40 openldap2 slapd[75017]: do_syncrep2: rid=021 cookie=rid=021,sid=001,csn=20160113120840.025550Z#000000#001#000000
Jan 13 13:08:40 openldap2 slapd[75017]: syncrepl_message_to_entry: rid=021 DN: uid=vkw-guest,ou=people,o=abc.net, UUID: 2074bc1e-4e3a-1035-92a1-ed72d2e7074a
Jan 13 13:08:40 openldap2 slapd[75017]: >>> dnPrettyNormal: <uid=vkw-guest,ou=people,o=abc.net>
Jan 13 13:08:40 openldap2 slapd[75017]: <<< dnPrettyNormal: <uid=vkw-guest,ou=people,o=abc.net>, <uid=vkw-guest,ou=people,o=abc.net>
Jan 13 13:08:40 openldap2 slapd[75017]: >>> dnPretty: <cn=admin,o=xyz.net>
Jan 13 13:08:40 openldap2 slapd[75017]: <<< dnPretty: <cn=admin,o=xyz.net>
Jan 13 13:08:40 openldap2 slapd[75017]: >>> dnNormalize: <cn=admin,o=xyz.net>
Jan 13 13:08:40 openldap2 slapd[75017]: <<< dnNormalize: <cn=admin,o=xyz.net>
Jan 13 13:08:40 openldap2 slapd[75017]: >>> dnPretty: <cn=admin,o=xyz.net>
Jan 13 13:08:40 openldap2 slapd[75017]: <<< dnPretty: <cn=admin,o=xyz.net>
Jan 13 13:08:40 openldap2 slapd[75017]: >>> dnNormalize: <cn=admin,o=xyz.net>
Jan 13 13:08:40 openldap2 slapd[75017]: <<< dnNormalize: <cn=admin,o=xyz.net>
Jan 13 13:08:40 openldap2 slapd[75017]: >>> dnPretty: <uid=vkw-guest,ou=people,o=abc.net>
Jan 13 13:08:40 openldap2 slapd[75017]: <<< dnPretty: <uid=vkw-guest,ou=people,o=abc.net>
Jan 13 13:08:40 openldap2 slapd[75017]: >>> dnNormalize: <uid=vkw-guest,ou=people,o=abc.net>
Jan 13 13:08:40 openldap2 slapd[75017]: <<< dnNormalize: <uid=vkw-guest,ou=people,o=abc.net>
Jan 13 13:08:40 openldap2 slapd[75017]: >>> dnPretty: <cn=Subschema>
Jan 13 13:08:40 openldap2 slapd[75017]: <<< dnPretty: <cn=Subschema>
Jan 13 13:08:40 openldap2 slapd[75017]: >>> dnNormalize: <cn=Subschema>
Jan 13 13:08:40 openldap2 slapd[75017]: <<< dnNormalize: <cn=subschema>
Jan 13 13:08:40 openldap2 slapd[75017]: syncrepl_entry: rid=021 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
Jan 13 13:08:40 openldap2 slapd[75017]: => mdb_search
Jan 13 13:08:40 openldap2 slapd[75017]: mdb_dn2entry("o=abc.net")
Jan 13 13:08:40 openldap2 slapd[75017]: => mdb_dn2id("o=abc.net")
Jan 13 13:08:40 openldap2 slapd[75017]: <= mdb_dn2id: got id=0x1
Jan 13 13:08:40 openldap2 slapd[75017]: => mdb_entry_decode:
Jan 13 13:08:40 openldap2 slapd[75017]: <= mdb_entry_decode
Jan 13 13:08:40 openldap2 slapd[75017]: => access_allowed: search access to "o=abc.net" "entry" requested
Jan 13 13:08:40 openldap2 slapd[75017]: <= root access granted
Jan 13 13:08:40 openldap2 slapd[75017]: => access_allowed: search access granted by manage(=mwrscxd)
Jan 13 13:08:40 openldap2 slapd[75017]: search_candidates: base="o=abc.net" (0x00000001) scope=2
Jan 13 13:08:40 openldap2 slapd[75017]: => mdb_filter_candidates
Jan 13 13:08:40 openldap2 slapd[75017]: EQUALITY
Jan 13 13:08:40 openldap2 slapd[75017]: => mdb_equality_candidates (entryUUID)
Jan 13 13:08:40 openldap2 slapd[75017]: => key_read
Jan 13 13:08:40 openldap2 slapd[75017]: mdb_idl_fetch_key: [5ec43656]
Jan 13 13:08:40 openldap2 slapd[75017]: <= mdb_index_read: failed (-30798)
Jan 13 13:08:40 openldap2 slapd[75017]: <= mdb_equality_candidates: id=0, first=0, last=0
Jan 13 13:08:40 openldap2 slapd[75017]: <= mdb_filter_candidates: id=0 first=0 last=0
Jan 13 13:08:40 openldap2 slapd[75017]: mdb_search_candidates: id=0 first=0 last=0
Jan 13 13:08:40 openldap2 slapd[75017]: mdb_search: no candidates
Jan 13 13:08:40 openldap2 slapd[75017]: send_ldap_result: conn=-1 op=0 p=0
Jan 13 13:08:40 openldap2 slapd[75017]: send_ldap_result: err=0 matched="" text=""
Jan 13 13:08:40 openldap2 slapd[75017]: syncrepl_entry: rid=021 be_search (0)
Jan 13 13:08:40 openldap2 slapd[75017]: syncrepl_entry: rid=021 uid=vkw-guest,ou=people,o=abc.net
Jan 13 13:08:40 openldap2 slapd[75017]: slap_queue_csn: queueing 0x846348780 20160113120840.025550Z#000000#001#000000
Jan 13 13:08:40 openldap2 slapd[75017]: ==> unique_add <uid=vkw-guest,ou=people,o=abc.net>
Jan 13 13:08:40 openldap2 slapd[75017]: => access_allowed: manage access to "uid=vkw-guest,ou=people,o=abc.net" "entry" requested
Jan 13 13:08:40 openldap2 slapd[75017]: <= root access granted
Jan 13 13:08:40 openldap2 slapd[75017]: => access_allowed: manage access granted by manage(=mwrscxd)
Jan 13 13:08:40 openldap2 slapd[75017]: unique_add: administrative bypass, skipping
Jan 13 13:08:40 openldap2 slapd[75017]: => mdb_entry_get: ndn: "ou=people,o=abc.net"
Jan 13 13:08:40 openldap2 slapd[75017]: => mdb_entry_get: oc: "dynamicObject", at: "(null)"
Jan 13 13:08:40 openldap2 slapd[75017]: mdb_dn2entry("ou=people,o=abc.net")
Jan 13 13:08:40 openldap2 slapd[75017]: => mdb_dn2id("ou=people,o=abc.net")
Jan 13 13:08:40 openldap2 slapd[75017]: <= mdb_dn2id: got id=0x3
Jan 13 13:08:40 openldap2 slapd[75017]: => mdb_entry_decode:
Jan 13 13:08:40 openldap2 slapd[75017]: <= mdb_entry_decode
Jan 13 13:08:40 openldap2 slapd[75017]: => mdb_entry_get: found entry: "ou=people,o=abc.net"
Jan 13 13:08:40 openldap2 slapd[75017]: <= mdb_entry_get: failed to find objectClass dynamicObject
Jan 13 13:08:40 openldap2 slapd[75017]: mdb_entry_get: rc=16
7 years, 11 months
add sortvals after database loaded?
by Phil Pishioneri
Environment:
slapd: openldap-ltb-2.4.42-1.el6.x86_64
config: slapd.conf (file)
database: mdb
After a database has been loaded, can the sortvals option be
added/changed without having to dump and reload the database? The
slapd.conf (and slapd-config) man page doesn't mention any need for a
reload, but wanted to verify.
-Phil
7 years, 11 months
Removing olcAccess entry
by Katherine Faella
For the life of me I can not figure out the syntax for performing this.
Here is my snippet of config.ldif:
dn: olcDatabase={1}hdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcHdbConfig
olcDatabase: {1}hdb
olcSuffix: dc=sakai,dc=uri,dc=edu
olcAccess: {0}to * by peername.ip="131.128.1.0%255.255.255.0" +0 break by
peername.ip="131.128.122.0%255.255.255.0" +0 break by peername.ip="158.123
.255.8%255.255.255.248" +0 break by peername.ip="127.0.0.1" +0 break
olcAccess: {1}to * by dn.regex="^URIEduauthid=.+,dc=sakai,dc=uri,dc=edu$$"
read by * auth
olcAddContentAcl: FALSE
olcLastMod: TRUE
olcMaxDerefDepth: 15
olcReadOnly: FALSE
olcRootDN: cn=Manager,dc=sakai,dc=uri,dc=edu
.....
I need to remove the olcAccess {0} as we need to access this server from
new ips. We are using a firewall to protect the server going forward.
I have created the file removeips containing:
dn: olcDatabase={1}hdb,cn=config
changetype: modify
delete: olcAccess
olcAccess: {1}
Running the command
ldapmodify -W -x -h antons.uri.edu -D "cn=admin,cn=config" -f
/root/ldapscripts/removeips
gives me:
modifying entry "olcDatabase={1}hdb,cn=config"
ldap_modify: No such attribute (16)
additional info: modify/delete: olcAccess: no such attribute
What am I doing wrong?
Thanks,
Kathy
--
Katherine Faella tel: (401) 874-4469
Senior Technical Programmer kmf(a)uri.edu
University of Rhode Island
University Computing Systems(UCS)
210 Flagg Road
Kingston, Rhode Island
7 years, 11 months
lmdb VL32 high virtual address usage
by Jeremiah Morrill
This sort of coincides with ITS issue 8347 I just reported.
With ldmb VL32, I’ve noticed that it can eat up a lot of memory space. Sometimes ~500mb for an 800mb db after reading every record, one by one using the same readonly transaction/cursor. I found that modifying MDB_ERPAGE_SIZE from 16384 to 256 brought virtual memory usage down substantially (~30megs). I have not noticed any adverse effects from this change or MDB_MAP_FULL. The mapped address spaces to seem to get deallocated on the close of the environment, not the transaction, which sounds like its being cached in the env->me_rpages for reasons explained in mdb_rpage_get comments.
Is the mem map cache supposed to be this aggressive by design, or just because this area of the code is so new...or simply a usage error on my part? If it’s by design, could there be a consideration to make MDB_ERPAGE_SIZE a #define’able value in the public lmdb.h so one could tweak the behavior?
-Jer
7 years, 11 months
Re: what databases are to be replicated for a slave?
by Jephte Clain
2015-12-29 20:38 GMT+04:00 Quanah Gibson-Mount <quanah(a)zimbra.com>:
> --On Tuesday, December 29, 2015 12:48 PM +0400 Jephte Clain
> <jephte.clain(a)univ-reunion.fr> wrote:
>
>
>
>>> No. Replicas do not accept writes. Replicas do not have a master
>>> configuration for cn=config. Replica's do not have server IDs.
>>
>> ok I guess I understand. this is the reason why I usually call them
>> "slaves", not replicas (but I messed things up and called them replicas
>> this time ^^)
>> I also have replicas that only replicate data (or a subset of data) for
>> some services
>
>
> No. The terms replica and slave are interchangeable. As are master and
> provider. Given the very negative connotations of the concept of masters
> and slaves, the preferred terms are "provider" instead of "master" and
> "replica" instead of "slaves".
Aaargh, now I can't help thinking about "providers" whipping
"replicas". slapd can be so cruel sometimes :-)
And in case you wonder, here in reunion island we have a (relatively)
long history of slavery. We even have a day to commemorate abolition
of slavery: december 20th
>
>
>> the slaves are there in case of catastrophic failure of both masters (we
>> had one of these failure for another service due to a problem with the
>> shared storage. No one want to have this kind of emergency...)
>> If the master(s) crash, I just have to choose a slave as the new master,
>> slapcat the cn=config database, update the provider address, slapadd the
>> updated config, and update the loadbalancer settings. this is a bit of
>> work but at least we can restore service in a (relatively) small amount
>> of time.
>
>
> If they accept writes, they are not slaves/replicas. If you are replicating
> cn=config across all the systems, then they must all be masters. Your
> general description above sounds like you do not correctly understand how
> MMR functions.
OK... I finally understand what was bothering you
My replicas do _not_ accept writes. Sorry to have let you think so
I have two setups:
- a "legacy" one, with one master accessible to the applications that
can write, and two complete replicas (data + cn=config) behind a
loadbalancer for the reads. One of these replicas could become the new
master if the needs arise. And there are a bunch of partial replicas
(only a subset of data) for some specific services. The reason is on
our vmware farm, network access is regularly cut (don't know why, the
system guy neither), and these services cannot reconnect on their
own... piece of #$*! software :(
- a "new" one, with two masters in mirror mode (only one get the
writes at anytime thanks to the loadbalancer), and two replicas (only
data) which get all the reads. I feel like configuring chaining to be
able to write from the replicas, but I have no experience of the
benefits of this configuration...
I have read the admin guide several times, but I am open to any
suggestion to improve my skills
>
>>> Accesslog is unique to a given master.
>>
>> Ok that's what I wanted to know for sure
>>
>> Shouldn't the doc stat this clearly?
>
>
> Please file an ITS noting the docs should be updated on this point.
Ok. I may even provide a patch. I'll do it tomorrow.
Have a nice day/night (don't know where you live ^^)
Regards,
Jephté
--
Jephté CLAIN | Développeur, Intégrateur d'applications
Service Système d'Information
Direction des Systèmes d'Information
Tél: +262 262 93 86 31 || Gsm: +262 692 29 58 24
7 years, 11 months
Out of ideas when troubleshooting TLS negotiation failure
by Graham Allan
This feels like a lame question, but I'm out of ideas, so...
I'm moving samba service between a couple of FreeBSD systems (9.3 to
10.2), and I'm stuck on getting samba on the new machine to connect to
our openldap server over ssl - frustrating since I've been running
samba+ldap for 15 years or so; feel sure I'm missing something basic!
The smbd-to-ldap connection works fine with no encryption, but I get
errors when using either TLS to port 389 ("Failed to issue the StartTLS
instruction: Connect error") or SSL to 636.
However I'm pretty certain it's not a certificate or CA validation
issue. All my other ldap clients on that server are working as expected,
including a simple "ldapsearch -ZZ". Both openssl s_client and
gnutls-cli show the ldap server certificate validating.
Maximum debugging on the ldap server gave me:
connection_read(3): TLS accept failure error=-1 id=1042, closing
conn=1042 fd=3 closed (TLS negotiation failure)
Running smbd under gbd shows ldap_start_tls_s (ldap_struct, NULL, NULL)
in smb_ldap_start_tls is returning -11 (LDAP_CONNECT_ERROR). That
doesn't give me any ideas, sadly!
Capturing the packet exchange between smbd and slapd, I'm seeing the
(smbd) client sends a "decrypt error" (TLS alert code 51) to the ldap
server after receiving the certificate, while the working "ldapsearch
-ZZ" moves on to client key exchange etc.
Besides all my other ldap clients working successfully, I think I'd
expect to see a TLS alert more like 42-48 if it were a cert validation
problem.
I'm not sure where to try looking next for the cause, would welcome any
suggestions...
Thanks, Graham
7 years, 11 months
Knowing free mdb space
by Angel L. Mateo
Hello,
I have recently migrated my openldap server from hdb to mdb. In this
kind of database you configure the maximal database size with maxsize
option.
Although I have configure this option with 8GB, more than the double of
my actual database size, I would like to know if there is any way to
calculate the remaining size.
According to [1] you can get the actual size with a du. But my problem
is that I'm using zfs with a compressed file system, so du reports the
compressed size, not the real one.
Is there any way to get this value? Or my real maximum size is 8GB
after compression?
[1] https://wiki.zimbra.com/wiki/OpenLDAP_Performance_Tuning_8.0
--
Angel L. Mateo Martínez
Sección de Telemática
Área de Tecnologías de la Información
y las Comunicaciones Aplicadas (ATICA)
http://www.um.es/atica
Tfo: 868887590
Fax: 868888337
7 years, 11 months
LMDB ITS 8324 WriteMap performance on Windows
by Victor Baybekov
Hi,
Thanks a lot for ITS#8324! For embedded, not server, use case that change
adds much convenience.
I have tested the master from .NET via P/Invoke and do not see any major
slowdown with default options. To insert 10M <int32,int32> pairs inside a
single transaction v.0.9.14 takes minimum 3400 msec, latest master takes
minimum 3750 msec. This is not scientific, just best result from 10 runs.
Sometimes both timings increase to 5000+ msecs. On average slowdown is
visible but tolerable - from 2.9 Mops to 2.6 Mops (absolute numbers are
still awesome!). With Append and NoSync I could get 3.45 Mops on the same
test with master build.
However, with WriteMap performance of master drops 3x to 10000 msec or just
1 Mops, while for the v.0.9.14 performance with WriteMap improves to 2350
msec or 4.25 Mops.
Is this the cost of convenience or it could be fixed so that WriteMap still
"is faster and uses fewer mallocs" as the docs say?
Best regards,
Victor
7 years, 11 months
2.4.43 "make test" hanging in "test039-glue-ldap-concurrency" on Solaris 10
by Greg Earle
Forgive me if this is the wrong place (maybe openldap-build?).
I've built OpenLDAP 2.4.43 on Solaris 10 1/13 OK, but when I run the
"make test" phase it hangs in the "test039-glue-ldap-concurrency" test:
--
>>>>> Starting test039-glue-ldap-concurrency for bdb...
running defines.sh
Starting slapd on TCP/IP port 9011...
Using ldapsearch to check that slapd is running...
Using ldapadd to populate the database...
Starting slapd on TCP/IP port 9012...
Using ldapsearch to check that slapd is running...
Using ldapadd to populate the database...
Starting slapd on TCP/IP port 9013...
Using ldapsearch to check that slapd is running...
MONITORDB yes
SRCDIR /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/testrun/./testdata
DSTDIR /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/testrun
pwd /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests
Using tester for concurrent server access...
PID=16664 - Read(1000): entry="cn=Barbara Jensen,ou=Information Technology Division,ou=People,o=Example,c=US".
[... blah blah etc. ...]
PID=17066 - Bind(1000): dn="cn=Barbara Jensen,ou=Information Technology Division,ou=People,o=Example,c=US".
PID=17080 - Search(500): base="cn=Monitor" scope=sub filter="(objectClass=*)" attrs=cn (more...).
PID=17096 - Read(1000): entry="cn=Somewhere,ou=Meta,o=Example,c=US".
slapd-bind PID=17066: ldap_sasl_bind_s: Invalid credentials (49)
PID=17102 - Bind(1000): dn="cn=Bjorn Jensen,ou=Information Technology Division,ou=People,o=Example,c=US".
PID=17112 - Search(500): base="cn=Monitor" scope=sub filter="(objectClass=*)" attrs=cn (more...).
PID=17118 - Read(1000): entry="cn=Backend 1,cn=Backends,cn=Monitor".
PID=17135 - Bind(1000): base="ou=People,o=Example,c=US", filter="(userPassword=*)" attr="userPassword".
PID=17135 - Bind base="ou=People,o=Example,c=US" filter="(userPassword=*)" got 3 values.
--
This is the last output I get. "ps" shows several test servers running
as well as the test harness clients; "lsof" shows the clients stuck in
poll() and doing nothing. They all have ESTABLISHED connections to their
servers.
--
zorro:1:1014 [/] # truss -p 17118
pollsys(0x0002CEFC, 1, 0x00000000, 0x00000000) (sleeping...)
^C
zorro:1:1015 [/] # truss -p 17135
pollsys(0x0002C39C, 1, 0x00000000, 0x00000000) (sleeping...)
--
I did a "gcore" and it says it's waiting in ldap_int_select():
--
(dbx) where
[1] __pollsys(0x2c39c, 0x1, 0x0, 0x0, 0xfef523f0, 0x0), at 0xfeede7ac
[2] _pollsys(0x2c39c, 0x1, 0x0, 0x0, 0x0, 0x2bb00), at 0xfeece490
[3] _poll(0x2c39c, 0x1, 0xffffffff, 0xffbfed8c, 0xff3ec2cc, 0x0), at 0xfee74ccc
=>[4] ldap_int_select(ld = 0x289d0, timeout = (nil)), line 1139 in "os-ip.c"
[5] wait4msg(ld = 0x289d0, msgid = 3, all = 1, timeout = (nil), result = 0xffbfef30), line 312 in "result.c"
[6] ldap_result(ld = 0x289d0, msgid = 3, all = 1, timeout = (nil), result = 0xffbfef30), line 117 in "result.c"
[7] ldap_sasl_bind_s(ld = 0x289d0, dn = 0x2ba58 "cn=Barbara Jensen,ou=Information Technology Division,ou=People,o=Example,c=US", mechanism = (nil), cred = 0xffbff080, sctrls = (nil), cctrls = (nil), servercredp = (nil)), line 210 in "sasl.c"
--
Why are these things just sitting here instead of completing and exiting?
BTW I am using the Solaris robust mutex fix patch (it wouldn't build
otherwise) posted a few weeks back. Configured via
./configure --prefix=/opt/openldap --enable-modules --with-ldap-module=dynamic\
--enable-bdb --enable-rlookups --enable-wrappers --enable-dynamic \
--enable-ldap --disable-ipv6 --enable-overlays --with-threads --enable-relay\
--enable-syslog
Puzzled in Pasadena,
- Greg
P.S. Here's the "ps" output if it matters
zorro:1:1011 [/] # ps -ax
PID TT S TIME COMMAND
[...]
4413 pts/5 S 0:00 make test
4414 pts/5 S 0:00 sh -ce cd tests; make test
4415 pts/5 S 0:00 make test
4416 pts/5 S 0:00 make bdb
4418 pts/5 S 0:00 /bin/sh ./run -b bdb all
4429 pts/5 S 0:00 /bin/sh ./scripts/all
13917 pts/5 S 0:00 -sh
13922 pts/5 S 0:00 -csh
16491 pts/5 S 0:00 /bin/sh ./scripts/test039-glue-ldap-concurrency
16502 pts/5 S 0:44 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/servers/slapd/.libs/slapd -s0 -f /usr/local/src/networking/OpenLDAP
16560 pts/5 S 0:05 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/servers/slapd/.libs/slapd -s0 -f /usr/local/src/networking/OpenLDAP
16604 pts/5 S 2:05 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/servers/slapd/.libs/slapd -s0 -f /usr/local/src/networking/OpenLDAP
16649 pts/5 S 0:00 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/progs/.libs/slapd-tester -P ./progs -d /usr/local/src/network
16668 pts/5 S 0:00 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/progs/.libs/slapd-bind -h localhost -p 9013 -l 1000 -L
16674 pts/5 S 0:00 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/progs/.libs/slapd-bind -h localhost -p 9013 -l 1000 -L
16677 pts/5 S 0:00 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/progs/.libs/slapd-modrdn -h localhost -p 9013 -D cn=Man
16680 pts/5 S 0:00 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/progs/.libs/slapd-bind -h localhost -p 9013 -l 1000 -L
16943 pts/5 S 0:00 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/progs/.libs/slapd-modrdn -h localhost -p 9013 -D cn=Man
16957 pts/5 S 0:00 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/progs/.libs/slapd-modify -h localhost -p 9013 -D cn=Man
16959 pts/5 S 0:00 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/progs/.libs/slapd-addel -h localhost -p 9013 -D cn=Mana
16981 pts/5 S 0:00 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/progs/.libs/slapd-bind -h localhost -p 9013 -l 1000 -L
17005 pts/5 S 0:00 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/progs/.libs/slapd-search -h localhost -p 9013 -D cn=Man
17017 pts/5 S 0:00 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/progs/.libs/slapd-read -h localhost -p 9013 -D cn=Manag
17033 pts/5 S 0:00 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/progs/.libs/slapd-bind -h localhost -p 9013 -l 1000 -L
17047 pts/5 S 0:00 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/progs/.libs/slapd-search -h localhost -p 9013 -D cn=Man
17061 pts/5 S 0:00 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/progs/.libs/slapd-read -h localhost -p 9013 -D cn=Manag
17066 pts/5 S 0:00 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/progs/.libs/slapd-bind -h localhost -p 9013 -l 1000 -L
17080 pts/5 S 0:00 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/progs/.libs/slapd-search -h localhost -p 9013 -D cn=Man
17096 pts/5 S 0:00 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/progs/.libs/slapd-read -h localhost -p 9013 -D cn=Manag
17102 pts/5 S 0:00 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/progs/.libs/slapd-bind -h localhost -p 9013 -l 1000 -L
17112 pts/5 S 0:00 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/progs/.libs/slapd-search -h localhost -p 9013 -D cn=Man
17118 pts/5 S 0:00 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/progs/.libs/slapd-read -h localhost -p 9013 -D cn=Manag
17135 pts/5 S 0:00 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/progs/.libs/slapd-bind -h localhost -p 9013 -l 1000 -L
7 years, 11 months
