This is the first testing call for OpenLDAP 2.4.54. Depending on the results, this may be the only testing call.
Generally, get the code for RE24:
Extract, configure, and build.
Execute the test suite (via make test) after it is built. Optionally, cd tests && make its to run through the regression suite.
Thanks!
OpenLDAP 2.4.54 Engineering Fixed slapd delta-syncrepl to ignore delete ops on deleted entry (ITS#9342) Fixed slapd delta-syncrepl to be fully serialized (ITS#9330) Fixed slapd delta-syncrepl MOD on zero-length context entry (ITS#9352) Fixed slapd sessionlog to use a TAVL tree (ITS#8486) Fixed slapd syncrepl to be fully serialized (ITS#8102) Fixed slapd syncrepl to call check_syncprov on fresh consumer (ITS#9345) Fixed slapd syncrepl to propagate errors from overlay_entry_get_ov (ITS#9355) Fixed slapd syncrepl to not create empty ADD ops (ITS#9359) Fixed slapd syncrepl replace usage on single valued attrs (ITS#9295) Fixed slapd-monitor fix monitor_back_register_database for empty suffix DB (ITS#9353) Fixed slapo-accesslog normalizer for reqStart (ITS#9358) Fixed slapo-syncprov contextCSN generation with empty suffix (ITS#9015)
Regards, Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
Hello,
On Thu, 1 Oct 2020, Quanah Gibson-Mount wrote:
Optionally, cd tests && make its to run through the regression suite.
On RHEL7, both the test suite and the regression suite completed without errors.
However, on RHEL8, "make its" fails:
Starting its9338 ...
running defines.sh This test checks for pending operations to resume correctly after they were stopped by a writer getting blocked by a full socket output buffer. It uses a search with syncrepl control and multiple modifications to generate enough responses to fill the output buffer.
Starting provider slapd on TCP/IP port 9011... Using ldapsearch to check that provider slapd is running... Using ldapadd to populate the provider directory... Starting persistent search and modifications... (Ignore the "press Enter to continue" that appears below)
Waiting for responses to accumulate, press Enter to continue: PID=149619 - Add/Delete(4000): entry="cn=James A Jones 2,ou=Alumni Association,ou=People,dc=example,dc=com". PID=149619 - Add/Delete done (0). Abandoning msgid 2 ldap_result: Other (e.g., implementation specific) error (80) ldapsearch failed - write waiter didn't resume pending ops
./data/regressions/its9338/its9338 failed (exit 1)
make[1]: *** [Makefile:336: bdb-its-yes] Error 1 make[1]: Leaving directory '/home/vmk/ol/openldap-OPENLDAP_REL_ENG_2_4/tests' make: *** [Makefile:325: regressions] Error 2
best regards, Jokke H.
On Thu, 1 Oct 2020, Quanah Gibson-Mount wrote:
Optionally, cd tests && make its to run through the regression suite.
Second run of "make its" on RHEL8. It seems to me that bdb succeeded this time, but now it is hdb that failed its9338:
Starting its9338 ...
running defines.sh This test checks for pending operations to resume correctly after they were stopped by a writer getting blocked by a full socket output buffer. It uses a search with syncrepl control and multiple modifications to generate enough responses to fill the output buffer.
Starting provider slapd on TCP/IP port 9011... Using ldapsearch to check that provider slapd is running... Using ldapadd to populate the provider directory... Starting persistent search and modifications... (Ignore the "press Enter to continue" that appears below)
Waiting for responses to accumulate, press Enter to continue: PID=150869 - Add/Delete(4000): entry="cn=James A Jones 2,ou=Alumni Association,ou=People,dc=example,dc=com". PID=150869 - Add/Delete done (0). Abandoning msgid 2 ldap_result: Other (e.g., implementation specific) error (80) ldapsearch failed - write waiter didn't resume pending ops
./data/regressions/its9338/its9338 failed (exit 1)
make[1]: *** [Makefile:343: hdb-its-yes] Error 1 make[1]: Leaving directory '/home/vmk/ol/openldap-OPENLDAP_REL_ENG_2_4/tests' make: *** [Makefile:326: regressions] Error 2
best regards, Jokke H.
--On Friday, October 2, 2020 2:51 PM +0300 openldap-technical@kolttonen.fi wrote:
On Thu, 1 Oct 2020, Quanah Gibson-Mount wrote:
Optionally, cd tests && make its to run through the regression suite.
Second run of "make its" on RHEL8. It seems to me that bdb succeeded this time, but now it is hdb that failed its9338:
Ok, thanks. I've run the test through a loop of 100 iterations for both bdb and hdb on Debian 10 with no issue. I'll test on CentOS8 next. I'm thinking it may be a timing issue.
I.e., from the test dir, it is possible to do:
./run -b hdb -l 100 its9338
or
./run -b bdb -l 100 its9338
To specify the backend and the number of rounds to run the test.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
Quanah Gibson-Mount wrote:
--On Friday, October 2, 2020 2:51 PM +0300 openldap-technical@kolttonen.fi wrote:
On Thu, 1 Oct 2020, Quanah Gibson-Mount wrote:
Optionally, cd tests && make its to run through the regression suite.
Second run of "make its" on RHEL8. It seems to me that bdb succeeded this time, but now it is hdb that failed its9338:
Ok, thanks. I've run the test through a loop of 100 iterations for both bdb and hdb on Debian 10 with no issue. I'll test on CentOS8 next. I'm thinking it may be a timing issue.
Note that this test depends on a socket buffer filling up and causing a slapd thread to go into a write wait, to even function. It may simply be that the default kernel socket buffer size on RHEL8 is different and so the test condition doesn't trigger.
--On Friday, October 2, 2020 7:28 PM +0100 Howard Chu hyc@symas.com wrote:
Note that this test depends on a socket buffer filling up and causing a slapd thread to go into a write wait, to even function. It may simply be that the default kernel socket buffer size on RHEL8 is different and so the test condition doesn't trigger.
OK. The system I tested on has:
cat /proc/sys/net/core/wmem_default 212992 cat /proc/sys/net/core/wmem_max 212992
Same for the CentOS8 box I'm on.
Jokke, what values does your system have?
Regards, Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
Hello,
On Fri, 2 Oct 2020, Quanah Gibson-Mount wrote:
--On Friday, October 2, 2020 7:28 PM +0100 Howard Chu hyc@symas.com wrote:
Note that this test depends on a socket buffer filling up and causing a slapd thread to go into a write wait, to even function. It may simply be that the default kernel socket buffer size on RHEL8 is different and so the test condition doesn't trigger.
OK. The system I tested on has:
cat /proc/sys/net/core/wmem_default 212992 cat /proc/sys/net/core/wmem_max 212992
Same for the CentOS8 box I'm on.
Jokke, what values does your system have?
Both are the same.
best regards, Jokke H.
Quanah Gibson-Mount quanah@symas.com schrieb am 02.10.2020 um 20:10 in
Nachricht <31B977D0527FF0BD2AF88F6A@[192.168.1.156]>:
‑‑On Friday, October 2, 2020 7:28 PM +0100 Howard Chu hyc@symas.com
wrote:
Note that this test depends on a socket buffer filling up and causing a slapd thread to go into a write wait, to even function. It may simply be that the default kernel socket buffer size on RHEL8 is different and so the test condition doesn't trigger.
OK. The system I tested on has:
cat /proc/sys/net/core/wmem_default 212992 cat /proc/sys/net/core/wmem_max 212992
Interestingly, I see the same default here for SLES12, but I also see (guessing it could be relevant): net.ipv4.tcp_wmem = 4096 16384 4194304
Same for the CentOS8 box I'm on.
Jokke, what values does your system have?
Regards, Quanah
‑‑
Quanah Gibson‑Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
On Mon, 5 Oct 2020, Ulrich Windl wrote:
Interestingly, I see the same default here for SLES12, but I also see (guessing it could be relevant): net.ipv4.tcp_wmem = 4096 16384 4194304
Same here on RHEL8.
best regards, Jokke H.
--On Monday, October 5, 2020 4:56 PM +0300 openldap-technical@kolttonen.fi wrote:
On Mon, 5 Oct 2020, Ulrich Windl wrote:
Interestingly, I see the same default here for SLES12, but I also see (guessing it could be relevant): net.ipv4.tcp_wmem = 4096 16384 4194304
Same here on RHEL8.
Discussed further with Howard. The test is timing dependent, so results may vary.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
Hi all,
On Thu, Oct 01, 2020 at 09:18:47AM -0700, Quanah Gibson-Mount wrote:
This is the first testing call for OpenLDAP 2.4.54. Depending on the results, this may be the only testing call.
Generally, get the code for RE24:
Extract, configure, and build.
Execute the test suite (via make test) after it is built. Optionally, cd tests && make its to run through the regression suite.
$ uname -a SunOS gcc-solaris11 5.11 11.3 sun4u sparc SUNW,SPARC-Enterprise
$ ./configure ... $ ... $ make test ...
Starting test018-syncreplication-persist for bdb...
running defines.sh Starting provider slapd on TCP/IP port 9011... Using ldapsearch to check that provider slapd is running... Using ldapadd to create the context prefix entry in the provider... Starting consumer slapd on TCP/IP port 9014... Using ldapsearch to check that consumer slapd is running... Using ldapadd to populate the provider directory... Waiting 7 seconds for syncrepl to receive changes... Using ldapsearch to read all the entries from the provider... Using ldapsearch to read all the entries from the consumer... Filtering provider results... Filtering consumer results... Comparing retrieved entries from provider and consumer... test failed - provider and consumer databases differ
test018-syncreplication-persist failed for bdb
(exit 1) gmake[2]: *** [Makefile:293: bdb-yes] Error 1 gmake[2]: Leaving directory '/export/home/airween/openldap-OPENLDAP_REL_ENG_2_4/tests' gmake[1]: *** [Makefile:278: test] Error 2 gmake[1]: Leaving directory '/export/home/airween/openldap-OPENLDAP_REL_ENG_2_4/tests' gmake: *** [Makefile:290: test] Error 2
regards,
a.
--On Tuesday, October 13, 2020 1:35 PM +0200 Ervin Hegedüs airween@gmail.com wrote:
test018-syncreplication-persist failed for bdb
(exit 1) gmake[2]: *** [Makefile:293: bdb-yes] Error 1 gmake[2]: Leaving directory '/export/home/airween/openldap-OPENLDAP_REL_ENG_2_4/tests' gmake[1]: *** [Makefile:278: test] Error 2 gmake[1]: Leaving directory '/export/home/airween/openldap-OPENLDAP_REL_ENG_2_4/tests' gmake: *** [Makefile:290: test] Error 2
This test is timing sensitive, unfortunately, so you may need to adjust the sleep timeouts accordingly for the OS.
Regards, Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
Hi,
On Tue, Oct 13, 2020 at 09:01:36AM -0700, Quanah Gibson-Mount wrote:
--On Tuesday, October 13, 2020 1:35 PM +0200 Ervin Hegedüs airween@gmail.com wrote:
> test018-syncreplication-persist failed for bdb
(exit 1) gmake[2]: *** [Makefile:293: bdb-yes] Error 1 gmake[2]: Leaving directory '/export/home/airween/openldap-OPENLDAP_REL_ENG_2_4/tests' gmake[1]: *** [Makefile:278: test] Error 2 gmake[1]: Leaving directory '/export/home/airween/openldap-OPENLDAP_REL_ENG_2_4/tests' gmake: *** [Makefile:290: test] Error 2
This test is timing sensitive, unfortunately, so you may need to adjust the sleep timeouts accordingly for the OS.
thanks, now I've tried:
$ export SLEEP1=10 $ make test ...
Starting test050-syncrepl-multiprovider for bdb...
running defines.sh Initializing server configurations... Starting server 1 on TCP/IP port 9011... Using ldapsearch to check that server 1 is running... Inserting syncprov overlay on server 1... Starting server 2 on TCP/IP port 9012... Using ldapsearch to check that server 2 is running... Configuring syncrepl on server 2... Starting server 3 on TCP/IP port 9013... Using ldapsearch to check that server 3 is running... Configuring syncrepl on server 3... Starting server 4 on TCP/IP port 9014... Using ldapsearch to check that server 4 is running... Configuring syncrepl on server 4... ... Waiting 10 seconds for servers to resync... Using ldapmodify to add/modify/delete entries from server 1... iteration 1 iteration 2 iteration 3 iteration 4 iteration 5 iteration 6 iteration 7 iteration 8 iteration 9 iteration 10 Waiting 10 seconds for servers to resync... Using ldapsearch to read all the entries from server 1... Using ldapsearch to read all the entries from server 2... Using ldapsearch to read all the entries from server 3... Using ldapsearch to read all the entries from server 4... Comparing retrieved entries from server 1 and server 2... test failed - server 1 and server 2 databases differ
test050-syncrepl-multiprovider failed for bdb
(exit 1)
is this sill a timing problem? Should I try with higher value?
regards,
a.
--On Tuesday, October 13, 2020 7:50 PM +0200 Hegedüs Ervin airween@gmail.com wrote:
thanks, now I've tried:
$ export SLEEP1=10 $ make test
I would try with 30 seconds, Solaris is notoriously slow, and SPARC + Solaris even slower. ;)
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
hi,
On Tue, Oct 13, 2020 at 11:52:01AM -0700, Quanah Gibson-Mount wrote:
--On Tuesday, October 13, 2020 7:50 PM +0200 Hegedüs Ervin airween@gmail.com wrote:
thanks, now I've tried:
$ export SLEEP1=10 $ make test
I would try with 30 seconds, Solaris is notoriously slow, and SPARC + Solaris even slower. ;)
I incremented that value to 12 - it runs since about 3 or 4 hours... (without problems)
a.
hi,
On Tue, Oct 13, 2020 at 11:52:01AM -0700, Quanah Gibson-Mount wrote:
--On Tuesday, October 13, 2020 7:50 PM +0200 Hegedüs Ervin airween@gmail.com wrote:
thanks, now I've tried:
$ export SLEEP1=10 $ make test
I would try with 30 seconds, Solaris is notoriously slow, and SPARC + Solaris even slower. ;)
I could't give up.
$ export SLEEP1=30 $ time make test ...
0 tests for mdb were skipped. gmake[2]: Leaving directory '/export/home/airween/openldap-OPENLDAP_REL_ENG_2_4/tests' gmake[1]: Leaving directory '/export/home/airween/openldap-OPENLDAP_REL_ENG_2_4/tests'
real 320m20.971s user 12m9.195s sys 11m40.302s
hth,
a.
hi again,
On Thu, Oct 01, 2020 at 09:18:47AM -0700, Quanah Gibson-Mount wrote:
This is the first testing call for OpenLDAP 2.4.54. Depending on the results, this may be the only testing call.
Generally, get the code for RE24:
Extract, configure, and build.
Execute the test suite (via make test) after it is built. Optionally, cd tests && make its to run through the regression suite.
$ uname -a Linux 4.18.0-80.7.2.el7.ppc64le #1 SMP Thu Sep 12 15:45:05 UTC 2019 ppc64le ppc64le ppc64le GNU/Linux $ make test ... ... 0 tests for mdb were skipped. $ cd tests/ $ make test ... 0 tests for mdb were skipped.
hth,
a.
Hi again
On Thu, Oct 01, 2020 at 09:18:47AM -0700, Quanah Gibson-Mount wrote:
This is the first testing call for OpenLDAP 2.4.54. Depending on the results, this may be the only testing call.
Generally, get the code for RE24:
Extract, configure, and build.
Execute the test suite (via make test) after it is built. Optionally, cd tests && make its to run through the regression suite.
$ uname -a Linux 4.19.123 #10 SMP PREEMPT Wed May 20 14:28:59 CEST 2020 mips64 GNU/Linux
$ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/mips64el-linux-gnuabi64/8/lto-wrapper Target: mips64el-linux-gnuabi64 Thread model: posix gcc version 8.3.0 (Debian 8.3.0-6)
$ ./configure ... checking db.h usability... yes checking db.h presence... yes checking for db.h... yes checking for Berkeley DB major version in db.h... 5 checking for Berkeley DB minor version in db.h... 3 checking if Berkeley DB version supported by BDB/HDB backends... yes checking for Berkeley DB link (-ldb-5.3)... yes checking for Berkeley DB library and header version match... Berkeley DB version mismatch header: Berkeley DB 5.3.21: (May 11, 2012) library: Berkeley DB 5.3.28: (September 9, 2013) no configure: error: Berkeley DB version mismatch
hth,
a.
--On Tuesday, October 13, 2020 6:52 PM +0200 Ervin Hegedüs airween@gmail.com wrote:
checking db.h usability... yes checking db.h presence... yes checking for db.h... yes checking for Berkeley DB major version in db.h... 5 checking for Berkeley DB minor version in db.h... 3 checking if Berkeley DB version supported by BDB/HDB backends... yes checking for Berkeley DB link (-ldb-5.3)... yes checking for Berkeley DB library and header version match... Berkeley DB version mismatch header: Berkeley DB 5.3.21: (May 11, 2012) library: Berkeley DB 5.3.28: (September 9, 2013)
This would indicate a problem with your build environment, not an OpenLDAP issue.
Regards, Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
On Tue, Oct 13, 2020 at 09:00:55AM -0700, Quanah Gibson-Mount wrote:
--On Tuesday, October 13, 2020 6:52 PM +0200 Ervin Hegedüs airween@gmail.com wrote:
checking db.h usability... yes checking db.h presence... yes checking for db.h... yes checking for Berkeley DB major version in db.h... 5 checking for Berkeley DB minor version in db.h... 3 checking if Berkeley DB version supported by BDB/HDB backends... yes checking for Berkeley DB link (-ldb-5.3)... yes checking for Berkeley DB library and header version match... Berkeley DB version mismatch header: Berkeley DB 5.3.21: (May 11, 2012) library: Berkeley DB 5.3.28: (September 9, 2013)
This would indicate a problem with your build environment, not an OpenLDAP issue.
yeah, the problem was the runtime library is installed on the system, but the developing files aren't. So I grabbed the BDB source here:
https://github.com/berkeleydb/libdb
and compiled.
The headers comes from this directory, but when the `configure` script ran the conftest binary, then it loaded the system-wide .so file - which is 5.3.28. (The GH repository contains 5.3.21)
Now it works as well:
$ uname -a Linux 4.19.123 #10 SMP PREEMPT Wed May 20 14:28:59 CEST 2020 mips64 GNU/Linux $ make test ...
0 tests for mdb were skipped.
thanks,
a.
openldap-technical@openldap.org
-
Ervin Hegedüs -
Hegedüs Ervin
-
Howard Chu -
Michael Ströder -
openldap-technical＠kolttonen.fi -
Quanah Gibson-Mount -
Ulrich Windl