2.4.47 is now believed to be ready for release after tracking down a deadlock and a few other replication issues. Please test. :)
Generally, get the code for RE24:
Configure & 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.47 Engineering Added slapd-sock DN qualifier for subtrees to be processed (ITS#8051) Added slapd-sock ability to send extended operations to external listeners (ITS#8714) Fixed liblber to avoid incremental access to user-supplied bv in dupbv (ITS#8752) Fixed libldap dn to domain parsing with bad input (ITS#8842) Fixed slapd slapcat to correctly honor -g option (ITS#8667) Fixed slapd to correctly handle NO_SUCH_OBJECT with dynamic groups (ITS#8923) Fixed slapd to check status of rdnNormalize (ITS#8932) Fixed slapd cn=config when modifying slapo-syncprov config (ITS#8616) Fixed slapd sasl authz-policy "all" behavior (ITS#8909) Fixed slapd sasl minor typo (ITS#8918) Fixed slapd to correctly hide hidden DBs in the rootDSE (ITS#8912) Fixed slapd domainScope control to match Microsoft specification (ITS#8840) Fixed slapd-bdb/hdb/mdb to not convert certain IDLs to ranges (ITS#8868) Fixed slapo-accesslog deadlock during cleanup (ITS#8752) Fixed slapo-memberof cn=config modifications (ITS#8663) Fixed slapo-ppolicy with multimaster replication (ITS#8927) Fixed slapo-syncprov with NULL modlist (ITS#8843) Build Environment Fixed missing includes with OpenSSL 1.0.2 (ITS#8809) Contrib Fixed slapo-pbkdf2 hash generation (ITS#8878) Documentation admin24 fixed minor typo (ITS#8887)
LMDB 0.9.23 Engineering ITS#8756 Fix loose pages in dirty list ITS#8831 Fix mdb_load flag init ITS#8844 Fix mdb_env_close in forked process Documentation ITS#8857 mdb_cursor_del doesn't invalidate cursor ITS#8908 GET_MULTIPLE etc don't change passed in key
Regards, Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
On 12/15/18 1:02 AM, Quanah Gibson-Mount wrote:
2.4.47 is now believed to be ready for release after tracking down a deadlock and a few other replication issues. Please test. :)
FWIW: make test works for me.
Platform: openSUSE Tumbleweed x86_64 gcc version 8.2.1 20181108 [gcc-8-branch revision 265914] (SUSE Linux) cyrus-sasl 2.1.27
Ciao, Michael.
Am 15.12.18 um 01:02 schrieb Quanah Gibson-Mount:
2.4.47 is now believed to be ready for release after tracking down a deadlock and a few other replication issues. Please test. :)
compile with many (mostly known notes) and some warnings. But "make its" fail.
Starting its8752 ...
running defines.sh This test tracks a case where slapd deadlocks during a significant write load See http://www.openldap.org/its/index.cgi/?findid=8752 for more information. Starting slapd on TCP/IP port 9011... Using ldapsearch to check that slapd is running... Populating database on first provider... Stopping slapd and reworking configuration for MMR... Starting provider slapd on TCP/IP URI ldap://localhost:9011/ Using ldapsearch to check that provider slapd is running... Starting provider slapd on TCP/IP URI ldap://localhost:9012/ Using ldapsearch to check that provider slapd is running... Starting provider slapd on TCP/IP URI ldap://localhost:9013/ Using ldapsearch to check that provider slapd is running... Starting provider slapd on TCP/IP URI ldap://localhost:9014/ Using ldapsearch to check that provider slapd is running... Setting up accesslog on each master... Modifying dn: cn=Elmer_Fudd,ou=People,dc=example,dc=com on master 1 Modifying dn: cn=Elmer_Fudd,ou=People,dc=example,dc=com on master 2 ldapmodify failed (32)
./data/regressions/its8752/its8752 failed (exit 1)
here the warnings while compiling: tls2.c:369:9: warning: implicit declaration of function 'ldap_pvt_tls_check_hostname' [-Wimplicit-function-declaration] ./libraries/libldap/os-ip.c:262: warning: `sys_errlist' is deprecated; use `strerror' or `strerror_r' instead ./libraries/libldap/os-ip.c:262: warning: `sys_nerr' is deprecated; use `strerror' or `strerror_r' instead thr_posix.c:93:9: warning: implicit declaration of function 'pthread_setconcurrency' [-Wimplicit-function-declaration] thr_posix.c:107:9: warning: implicit declaration of function 'pthread_getconcurrency' [-Wimplicit-function-declaration] os-ip.c:261:3: warning: ignoring return value of 'read', declared with attribute warn_unused_result [-Wunused-result] os-local.c:152:3: warning: ignoring return value of 'read', declared with attribute warn_unused_result [-Wunused-result]
and many instances of ldpversion.c:20:38: warning: macro "__DATE__" might prevent reproducible builds [-Wdate-time] "@(#) $OpenLDAP: ldappasswd 2.4.X (" __DATE__ " " __TIME__ ") $\n" ^~~~~~~~ ldpversion.c:20:51: warning: macro "__TIME__" might prevent reproducible builds [-Wdate-time] "@(#) $OpenLDAP: ldappasswd 2.4.X (" __DATE__ " " __TIME__ ") $\n"
if you need more information I may provide them...
Andreas
--On Saturday, December 15, 2018 11:16 PM +0100 "A. Schulze" sca@andreasschulze.de wrote:
Am 15.12.18 um 01:02 schrieb Quanah Gibson-Mount:
2.4.47 is now believed to be ready for release after tracking down a deadlock and a few other replication issues. Please test. :)
compile with many (mostly known notes) and some warnings. But "make its" fail.
Starting its8752 ...
running defines.sh This test tracks a case where slapd deadlocks during a significant write load See http://www.openldap.org/its/index.cgi/?findid=8752 for more information. Starting slapd on TCP/IP port 9011... Using ldapsearch to check that slapd is running... Populating database on first provider... Stopping slapd and reworking configuration for MMR... Starting provider slapd on TCP/IP URI ldap://localhost:9011/ Using ldapsearch to check that provider slapd is running... Starting provider slapd on TCP/IP URI ldap://localhost:9012/ Using ldapsearch to check that provider slapd is running... Starting provider slapd on TCP/IP URI ldap://localhost:9013/ Using ldapsearch to check that provider slapd is running... Starting provider slapd on TCP/IP URI ldap://localhost:9014/ Using ldapsearch to check that provider slapd is running... Setting up accesslog on each master... Modifying dn: cn=Elmer_Fudd,ou=People,dc=example,dc=com on master 1 Modifying dn: cn=Elmer_Fudd,ou=People,dc=example,dc=com on master 2 ldapmodify failed (32)
./data/regressions/its8752/its8752 failed (exit 1)
The testrun directory would need to be provided for this.
and many instances of ldpversion.c:20:38: warning: macro "__DATE__" might prevent reproducible builds [-Wdate-time] "@(#) $OpenLDAP: ldappasswd 2.4.X (" __DATE__ " " __TIME__ ") $\n" ^~~~~~~~ ldpversion.c:20:51: warning: macro "__TIME__" might prevent reproducible builds [-Wdate-time] "@(#) $OpenLDAP: ldappasswd 2.4.X (" __DATE__ " " __TIME__ ") $\n"
This can be ignored, see ITS#8928
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
A. Schulze wrote:
Am 15.12.18 um 01:02 schrieb Quanah Gibson-Mount:
2.4.47 is now believed to be ready for release after tracking down a deadlock and a few other replication issues. Please test. :)
compile with many (mostly known notes) and some warnings. But "make its" fail.
Starting its8752 ...
running defines.sh This test tracks a case where slapd deadlocks during a significant write load See http://www.openldap.org/its/index.cgi/?findid=8752 for more information. Starting slapd on TCP/IP port 9011... Using ldapsearch to check that slapd is running... Populating database on first provider... Stopping slapd and reworking configuration for MMR... Starting provider slapd on TCP/IP URI ldap://localhost:9011/ Using ldapsearch to check that provider slapd is running... Starting provider slapd on TCP/IP URI ldap://localhost:9012/ Using ldapsearch to check that provider slapd is running... Starting provider slapd on TCP/IP URI ldap://localhost:9013/ Using ldapsearch to check that provider slapd is running... Starting provider slapd on TCP/IP URI ldap://localhost:9014/ Using ldapsearch to check that provider slapd is running... Setting up accesslog on each master... Modifying dn: cn=Elmer_Fudd,ou=People,dc=example,dc=com on master 1 Modifying dn: cn=Elmer_Fudd,ou=People,dc=example,dc=com on master 2 ldapmodify failed (32)
./data/regressions/its8752/its8752 failed (exit 1)
I believe this is simply due to too short a sleep between steps. It happens quite often on slower machines.
Am 16.12.18 um 23:32 schrieb Howard Chu:
> ./data/regressions/its8752/its8752 failed (exit 1)
I believe this is simply due to too short a sleep between steps. It happens quite often on slower machines.
are there plans to to relax the timings or should I simple ignore that fail? "it may happen that 'make its' pass on other computers" don't really satisfy me :-)
Andreas
--On Monday, December 17, 2018 10:19 PM +0100 "A. Schulze" sca@andreasschulze.de wrote:
Am 16.12.18 um 23:32 schrieb Howard Chu:
>> ./data/regressions/its8752/its8752 failed (exit 1)
I believe this is simply due to too short a sleep between steps. It happens quite often on slower machines.
are there plans to to relax the timings or should I simple ignore that fail? "it may happen that 'make its' pass on other computers" don't really satisfy me :-)
I just checked in a fix for this. Please pull new source and see if it passes. :)
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
"A. Schulze" sca@andreasschulze.de schrieb am 17.12.2018 um 22:19 in
Nachricht 77e04ce8-0362-c873-c751-98bc9ea58c73@andreasschulze.de:
Am 16.12.18 um 23:32 schrieb Howard Chu:
>> ./data/regressions/its8752/its8752 failed (exit 1)
I believe this is simply due to too short a sleep between steps. It happens
quite
often on slower machines.
are there plans to to relax the timings or should I simple ignore that fail? "it may happen that 'make its' pass on other computers" don't really satisfy me :-)
When waiting for an event (other than passing of time) sleep is always the wrong solution (iven if seemingly industry-standard work-around for all kinds of bugs): It's either too long, wasting time, or too short, failing to fulfill ist purpose.
Regards, Ulrich
Andreas
Ulrich Windl wrote:
"A. Schulze" sca@andreasschulze.de schrieb am 17.12.2018 um 22:19 in
Nachricht 77e04ce8-0362-c873-c751-98bc9ea58c73@andreasschulze.de:
Am 16.12.18 um 23:32 schrieb Howard Chu:
>>> ./data/regressions/its8752/its8752 failed (exit 1)
I believe this is simply due to too short a sleep between steps. It happens
quite
often on slower machines.
are there plans to to relax the timings or should I simple ignore that fail? "it may happen that 'make its' pass on other computers" don't really satisfy me :-)
When waiting for an event (other than passing of time) sleep is always the wrong solution
False.
(iven if seemingly industry-standard work-around for all kinds of bugs): It's either too long, wasting time, or too short, failing to fulfill ist purpose.
sleep is used because it is a low cost operation on the computer. Anything more active than that will use more system resources, which are obviously already scarce on a slower system. i.e., active polling on a slow machine will only make things slower.
Howard Chu hyc@symas.com schrieb am 18.12.2018 um 09:55 in Nachricht
970a00c2-d5ba-d562-89e3-94bf35d70d9e@symas.com:
Ulrich Windl wrote:
"A. Schulze" sca@andreasschulze.de schrieb am 17.12.2018 um 22:19 in
Nachricht 77e04ce8-0362-c873-c751-98bc9ea58c73@andreasschulze.de:
Am 16.12.18 um 23:32 schrieb Howard Chu:
>>>> ./data/regressions/its8752/its8752 failed (exit 1)
I believe this is simply due to too short a sleep between steps. It happens
quite
often on slower machines.
are there plans to to relax the timings or should I simple ignore that fail? "it may happen that 'make its' pass on other computers" don't really satisfy
me :-)
When waiting for an event (other than passing of time) sleep is always the
wrong solution
False.
(iven if seemingly industry-standard work-around for all kinds of bugs):
It's either too long, wasting time, or too short, failing to fulfill ist purpose.
sleep is used because it is a low cost operation on the computer. Anything more active than that will use more system resources, which are obviously already scarce on a slower system. i.e., active polling on a slow machine will only make things slower.
I agree that busy waiting is worse than sleeping.
-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
openldap-technical@openldap.org
-
A. Schulze -
Howard Chu -
Michael Ströder -
Quanah Gibson-Mount -
Ulrich Windl