test049 fails with invalid DN "cn=Ursula Hampster,ou=Alumni Association,ou=People,dc=example,dc=com" in the consumer because core.schema with 'ou' and 'dc' is not loaded.
test050 similarly fails on "dc=example,dc=com".
test053 also fails, i have not checked why. Like test050 it keeps waiting for syncrepl to receive changes, then gives up.
If it makes a difference, my configuration is ./configure --enable-dynamic --enable-modules --enable-dynamic --enable-dynacl --enable-aci --enable-crypt --enable-lmpasswd --enable-modules --enable-spasswd --enable-rlookups --enable-slapi --enable-backends=mod --disable-ndb --disable-sql --enable-overlays=mod
Hallvard B Furuseth wrote:
test049 fails with invalid DN "cn=Ursula Hampster,ou=Alumni Association,ou=People,dc=example,dc=com" in the consumer because core.schema with 'ou' and 'dc' is not loaded.
test050 similarly fails on "dc=example,dc=com".
test053 also fails, i have not checked why. Like test050 it keeps waiting for syncrepl to receive changes, then gives up.
As a side note, test053 is not in RE24. Should it be? Seems likely...
--On Saturday, November 15, 2008 10:36 PM -0800 Howard Chu hyc@symas.com wrote:
Hallvard B Furuseth wrote:
test049 fails with invalid DN "cn=Ursula Hampster,ou=Alumni Association,ou=People,dc=example,dc=com" in the consumer because core.schema with 'ou' and 'dc' is not loaded.
test050 similarly fails on "dc=example,dc=com".
test053 also fails, i have not checked why. Like test050 it keeps waiting for syncrepl to receive changes, then gives up.
As a side note, test053 is not in RE24. Should it be? Seems likely...
No, it should not. I've already removed it once from RE24:
1.1.2.2 Mon May 5 21:32:15 2008 UTC; 6 months, 1 week ago by quanah Branch: OPENLDAP_REL_ENG_2_4 Changed since 1.1.2.1: +1 -1 lines Diffs to 1.1.2.1 (colored diff) FILE REMOVED
Remove test053-syncprov-glue. It assumes options that aren't valid for earlier versions of BDB, and it assumes the db_stat in the user's path is from the same version of BDB as OpenLDAP was compiled against.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Quanah Gibson-Mount skrev:
--On Saturday, November 15, 2008 10:36 PM -0800 Howard Chu hyc@symas.com wrote:
As a side note, test053 is not in RE24. Should it be? Seems likely...
No, it should not. I've already removed it once from RE24:
1.1.2.2 Mon May 5 21:32:15 2008 UTC; 6 months, 1 week ago by quanah Branch: OPENLDAP_REL_ENG_2_4 Changed since 1.1.2.1: +1 -1 lines Diffs to 1.1.2.1 (colored diff) FILE REMOVED
Remove test053-syncprov-glue. It assumes options that aren't valid for earlier versions of BDB, and it assumes the db_stat in the user's path is from the same version of BDB as OpenLDAP was compiled against.
I have updated the script to try if any db_stat it finds in PATH works with the bdb OpenLDAP was compiled with before actually making use of it. Does this make the script acceptable?
Alternatively, we could remove its db_stat usage. It is only used as an extra aid in detecting the deadlock situation the script was written to find, and to warn the user about a possible deadlock if the bug appears to be there. Or is there some other safe way to find a working db_stat to use, or test the "db_stat -V" output of any if finds agains the bdb version OpenLDAP was built with?
Rein
Rein Tollevik wrote:
Quanah Gibson-Mount skrev:
--On Saturday, November 15, 2008 10:36 PM -0800 Howard Chu hyc@symas.com wrote:
As a side note, test053 is not in RE24. Should it be? Seems likely...
No, it should not. I've already removed it once from RE24:
1.1.2.2 Mon May 5 21:32:15 2008 UTC; 6 months, 1 week ago by quanah Branch: OPENLDAP_REL_ENG_2_4 Changed since 1.1.2.1: +1 -1 lines Diffs to 1.1.2.1 (colored diff) FILE REMOVED
Remove test053-syncprov-glue. It assumes options that aren't valid for earlier versions of BDB, and it assumes the db_stat in the user's path is from the same version of BDB as OpenLDAP was compiled against.
I have updated the script to try if any db_stat it finds in PATH works with the bdb OpenLDAP was compiled with before actually making use of it. Does this make the script acceptable?
Alternatively, we could remove its db_stat usage. It is only used as an extra aid in detecting the deadlock situation the script was written to find, and to warn the user about a possible deadlock if the bug appears to be there. Or is there some other safe way to find a working db_stat to use, or test the "db_stat -V" output of any if finds agains the bdb version OpenLDAP was built with?
On some platforms it's called "slapd_db_stat" or somesuch. There's really no guaranteed way to find the right exe.
--On Tuesday, November 18, 2008 1:37 PM -0800 Howard Chu hyc@symas.com wrote:
Rein Tollevik wrote:
Quanah Gibson-Mount skrev:
--On Saturday, November 15, 2008 10:36 PM -0800 Howard Chu hyc@symas.com wrote:
As a side note, test053 is not in RE24. Should it be? Seems likely...
No, it should not. I've already removed it once from RE24:
1.1.2.2 Mon May 5 21:32:15 2008 UTC; 6 months, 1 week ago by quanah Branch: OPENLDAP_REL_ENG_2_4 Changed since 1.1.2.1: +1 -1 lines Diffs to 1.1.2.1 (colored diff) FILE REMOVED
Remove test053-syncprov-glue. It assumes options that aren't valid for earlier versions of BDB, and it assumes the db_stat in the user's path is from the same version of BDB as OpenLDAP was compiled against.
I have updated the script to try if any db_stat it finds in PATH works with the bdb OpenLDAP was compiled with before actually making use of it. Does this make the script acceptable?
Alternatively, we could remove its db_stat usage. It is only used as an extra aid in detecting the deadlock situation the script was written to find, and to warn the user about a possible deadlock if the bug appears to be there. Or is there some other safe way to find a working db_stat to use, or test the "db_stat -V" output of any if finds agains the bdb version OpenLDAP was built with?
On some platforms it's called "slapd_db_stat" or somesuch. There's really no guaranteed way to find the right exe.
And, for example, in my case, it's not in my path. ;)
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Hallvard B Furuseth wrote:
test049 fails with invalid DN "cn=Ursula Hampster,ou=Alumni Association,ou=People,dc=example,dc=com" in the consumer because core.schema with 'ou' and 'dc' is not loaded.
test050 similarly fails on "dc=example,dc=com".
test053 also fails, i have not checked why. Like test050 it keeps waiting for syncrepl to receive changes, then gives up.
If it makes a difference, my configuration is ./configure --enable-dynamic --enable-modules --enable-dynamic --enable-dynacl --enable-aci --enable-crypt --enable-lmpasswd --enable-modules --enable-spasswd --enable-rlookups --enable-slapi --enable-backends=mod --disable-ndb --disable-sql --enable-overlays=mod
Hm, all of these tests passed for me but I only have '--enable-modules' '--enable-overlays=mod' '--enable-ldap' '--enable-meta' at the moment...
Howard Chu wrote:
Hallvard B Furuseth wrote:
test049 fails with invalid DN "cn=Ursula Hampster,ou=Alumni Association,ou=People,dc=example,dc=com" in the consumer because core.schema with 'ou' and 'dc' is not loaded.
test050 similarly fails on "dc=example,dc=com".
test053 also fails, i have not checked why. Like test050 it keeps waiting for syncrepl to receive changes, then gives up.
If it makes a difference, my configuration is ./configure --enable-dynamic --enable-modules --enable-dynamic --enable-dynacl --enable-aci --enable-crypt --enable-lmpasswd --enable-modules --enable-spasswd --enable-rlookups --enable-slapi --enable-backends=mod --disable-ndb --disable-sql --enable-overlays=mod
Hm, all of these tests passed for me but I only have '--enable-modules' '--enable-overlays=mod' '--enable-ldap' '--enable-meta' at the moment...
Ah, my tree wasn't fully up to date; in particular I don't have a current acl.c / aclparse.c. On my fully updated tree test049 failed, waiting for syncrepl to receive changes. Seems this ACL code has broken something.
Howard Chu wrote:
Howard Chu wrote:
Hallvard B Furuseth wrote:
test049 fails with invalid DN "cn=Ursula Hampster,ou=Alumni Association,ou=People,dc=example,dc=com" in the consumer because core.schema with 'ou' and 'dc' is not loaded.
test050 similarly fails on "dc=example,dc=com".
test053 also fails, i have not checked why. Like test050 it keeps waiting for syncrepl to receive changes, then gives up.
If it makes a difference, my configuration is ./configure --enable-dynamic --enable-modules --enable-dynamic --enable-dynacl --enable-aci --enable-crypt --enable-lmpasswd --enable-modules --enable-spasswd --enable-rlookups --enable-slapi --enable-backends=mod --disable-ndb --disable-sql --enable-overlays=mod
Hm, all of these tests passed for me but I only have '--enable-modules' '--enable-overlays=mod' '--enable-ldap' '--enable-meta' at the moment...
Ah, my tree wasn't fully up to date; in particular I don't have a current acl.c / aclparse.c. On my fully updated tree test049 failed, waiting for syncrepl to receive changes. Seems this ACL code has broken something.
No, that wasn't the problem. This commit
http://www.openldap.org/lists/openldap-commit/200811/msg00312.html
is leaving SYNCTYPE undefined so it defaults to refreshOnly with no repeat interval, so the consumer connects once and then goes away, and it never sees the core.schema being loaded on the provider.
Howard Chu wrote:
No, that wasn't the problem. This commit
http://www.openldap.org/lists/openldap-commit/200811/msg00312.html
is leaving SYNCTYPE undefined so it defaults to refreshOnly with no repeat interval, so the consumer connects once and then goes away, and it never sees the core.schema being loaded on the provider.
Well, you need to re-configure, because tests/run is generated. I should have pointed it out in the commit log, but I did it long before I committed, sorry.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando@sys-net.it -----------------------------------
Pierangelo Masarati writes:
Well, you need to re-configure, because tests/run is generated. I should have pointed it out in the commit log, but I did it long before I committed, sorry.
cvs update make distclean; ./configure with my old parameters; ...; cd tests
$ ./run test049 ... Waiting 20 seconds for syncrepl to receive changes... Using ldapsearch to check that syncrepl received database changes... Waiting 5 seconds for syncrepl to receive changes... {tried 6 times} ldapsearch failed (32)!
{0}core.ldif is in the consumers this time though. The other tests succeed.
Hallvard B Furuseth wrote:
Pierangelo Masarati writes:
Well, you need to re-configure, because tests/run is generated. I should have pointed it out in the commit log, but I did it long before I committed, sorry.
cvs update make distclean; ./configure with my old parameters; ...; cd tests
$ ./run test049 ... Waiting 20 seconds for syncrepl to receive changes... Using ldapsearch to check that syncrepl received database changes... Waiting 5 seconds for syncrepl to receive changes... {tried 6 times} ldapsearch failed (32)!
{0}core.ldif is in the consumers this time though. The other tests succeed.
Works here (after a fresh update). Can you run manually the search that's tried at that point of test049 (after run -k)? The error code "32" is fake, it's not what ldapsearch returned. Anything but receiving the expected DN will print 32.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando@sys-net.it -----------------------------------
Pierangelo Masarati writes:
Works here (after a fresh update). Can you run manually the search that's tried at that point of test049 (after run -k)?
../clients/tools/ldapsearch -P 3 -x -LLL -H ldap://localhost:9012/ -s base -b 'cn=Ursula Hampster,ou=Alumni Association,ou=People,dc=example,dc=com' '(objectClass=*)' No such object (32)
../clients/tools/ldapsearch -P 3 -x -LLL -H ldap://localhost:9012/ -s sub -b 'dc=example,dc=com' '(objectClass=*)' No such object (32)
It works when configured with just ./configure.
Hallvard B Furuseth wrote:
Pierangelo Masarati writes:
Works here (after a fresh update). Can you run manually the search that's tried at that point of test049 (after run -k)?
../clients/tools/ldapsearch -P 3 -x -LLL -H ldap://localhost:9012/ -s base -b 'cn=Ursula Hampster,ou=Alumni Association,ou=People,dc=example,dc=com' '(objectClass=*)' No such object (32)
../clients/tools/ldapsearch -P 3 -x -LLL -H ldap://localhost:9012/ -s sub -b 'dc=example,dc=com' '(objectClass=*)' No such object (32)
It works when configured with just ./configure.
I have reconfigured as you indicated, and I confirm it fails most of the time as you indicated. Occasionally, it succeeds (let's say 1 out of 5 succeeds).
I'm investigating.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando@sys-net.it -----------------------------------
I have reconfigured as you indicated, and I confirm it fails most of the time as you indicated. Occasionally, it succeeds (let's say 1 out of 5 succeeds).
I'm investigating.
Should be now fixed in HEAD.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando@sys-net.it -----------------------------------
Howard Chu hyc@symas.com wrote:
Ah, my tree wasn't fully up to date; in particular I don't have a current acl.c / aclparse.c. On my fully updated tree test049 failed, waiting for syncrepl to receive changes. Seems this ACL code has broken something.
Weird: I did run the tests prior committing and saw nothing. Corrupted memory problem that pops up on some setups and not others?
-
Hallvard B Furuseth -
Howard Chu -
manu＠netbsd.org -
Pierangelo Masarati -
Quanah Gibson-Mount -
Rein Tollevik