openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

Re: (ITS#5470) Sporadic failures with RE24
by raphael.ouazana＠linagora.com 07 May '08

07 May '08

Hi, Le Lun 5 mai 2008 23:08, Howard Chu a écrit : > The logs show that the syncrepl consumers all timed out periodically, when > trying to bind to a provider. It seems that using a 1 second timeout in > the > syncrepl configs is too short, or your test machine was too slow during > that run. > > Probably we should remove that timeout now, since the cn=config/thread > pause > issue has already been resolved. Currently testing new RE24. I have now a slapd process stuck at 100% : \_ /bin/sh ./scripts/test050-syncrepl-multimaster hdb \_ /tmp/openldap/tests/../servers/slapd/slapd -s0 -F slapd.d -h ldap://localhost:9011/ -d 261 \_ /tmp/openldap/tests/../servers/slapd/slapd -s0 -F ./slapd.d -h ldap://localhost:9012/ -d 261 \_ /tmp/openldap/tests/../servers/slapd/slapd -s0 -F ./slapd.d -h ldap://localhost:9013/ -d 261 \_ /bin/sh ./scripts/test050-syncrepl-multimaster hdb \_ ../clients/tools/ldapsearch -P 3 -x -LLL -H ldap://localhost:9013/ -s base -b cn=Ursula Hampster,ou=Alumni Association,ou=People,dc=example,dc=com (objectClass=*) \_ awk /^dn:/ {print "OK"} Do you need some debugging info (strace, gdb, log, or other) ? Regards, Raphael Ouazana.

1 0

(ITS#5497) back-sql with base64 encoded attributes
by kislinger＠kn.vutbr.cz 07 May '08

07 May '08

Full_Name: Pavel Kislinger Version: 2.4.8 OS: Freebsd 6.3 Stable URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (147.229.202.76) I am using this packages: openldap-server-2.4.8_1 openldap-client-2.4.8 mysql-client-5.0.51a unixODBC-2.2.12_4 mysql-connector-odbc-unixodbc-mysql50-3.51.12_1 I have records with diacritics (czech language) like name or surname in SQL. +-------+---------------+-----------+ | vutid | name | surname | +-------+---------------+-----------+ | 1 | Pavel | Kislinger | | 2 | Michhěčřýíé | abáček | +-------+---------------+-----------+ First record in SQL correspond to record in LDAP. Second record with diacritics doesn't works. # 1, users, test.vutbr.cz dn: uid=1,ou=users,dc=test,dc=vutbr,dc=cz objectClass: usi cn: Pavel Kislinger sn: Kislinger givenName: Pavel uid: 1 Solution of this problem is base64 encoding of attributes. "cn" for second record "Michhěčřýíé abáček" could be: cn:: eHhNaWNoaOy56Pi+/e3pYWx4eCBLaXNsaW5nZXI= I wrote MySQL function base64_encoding and adjusted table ldap_attr_mapping for "cn": insert into ldap_attr_mappings (<list of columns>) values (114,3,'cn',"base64_encode(concat(users.name,' ',users.surname))",'users',NULL,NULL,NULL,3,0); the result in ldap is: cn: eHhNaWNoaOy56Pi+/e3pYWx4eCBLaXNsaW5nZXI= This value is false recognized by ldap clients (outlook, thunderbird) as string "eHhN..." instead of "Michhěčřýíé abáček" How can I mark "cn" attribute in SQL, that this attribute is encoded by base64?

1 0

Re: (ITS#5495) cpu consuption
by quanah＠zimbra.com 06 May '08

06 May '08

--On Monday, May 05, 2008 6:07 AM +0000 naga.gangadhar(a)gmail.com wrote: > Full_Name: Naga Gangadhar Reddy > Version: 2.4.19 > OS: cent-os > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (203.212.208.159) There's no evidence of a bug here. Please submit questions about how to configure and use OpenLDAP to the Openldap software list. I will also note that there is no such OpenLDAP release as "2.4.19". Regards, Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5494) slapd crashed when accessed by multiple threads
by adejong＠debian.org 06 May '08

06 May '08

--=-6tNxv4Jql6LXRCulK2og Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2008-05-05 at 18:30 -0700, Howard Chu wrote: > This is most likely the same as ITS#5439, fixed in HEAD/RE24/2.4.9. > Please test against a more recent release. I have used a cvs version: cvs -d :pserver:anonymous@cvs.OpenLDAP.org:/repo/OpenLDAP -z3 \ checkout -P -rOPENLDAP_REL_ENG_2_4_9 openldap and configured it with: ./configure --prefix=3D/opt/openldap-cvs-2.4.9 --enable-local \ --enable-slapd --enable-aci --enable-cleartext --enable-crypt \ --disable-lmpasswd --enable-spasswd --enable-slapi --enable-slp \ --enable-wrappers --enable-backends=3Dmod --enable-ldbm=3Dno \ --enable-overlays=3Dmod --with-subdir=3Dldap --with-cyrus-sasl \ --with-threads --with-tls=3Dgnutls --with-odbc=3Dunixodbc \ --enable-perl=3Dno and have not been able to trigger a crash with it so I would think that it is fixed in that version. Thanks. --=20 -- arthur - adejong(a)debian.org - http://people.debian.org/~adejong -- --=-6tNxv4Jql6LXRCulK2og Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBIIMnRVYan35+NCKcRArkpAKCYd7ndeUHUsgQtj0loLAOJZYKDTgCgk37K C4gfQFwljJKeGhYkY7gWnq0= =YSTk -----END PGP SIGNATURE----- --=-6tNxv4Jql6LXRCulK2og--

1 0

Re: (ITS#5494) slapd crashed when accessed by multiple threads
by hyc＠symas.com 05 May '08

05 May '08

This is most likely the same as ITS#5439, fixed in HEAD/RE24/2.4.9. Please test against a more recent release. adejong(a)debian.org wrote: > Full_Name: Arthur de Jong > Version: 2.4.7 > OS: Debian unstable > URL: http://arthurenhella.demon.nl/nss-ldapd/adejong-slapd-crash.log > Submission from: (NULL) (83.160.165.27) > > > This has also been submitted as a Debian bug: > http://bugs.debian.org/479237 > > My test slapd consistently crashes when doing multiple simultaneous > requests in different threads. Each thread has it's own LDAP *ld > connection to the LDAP server which is supposed to be supported [1]. In > any case this shouldn't crash the LDAP server. > > [1] http://www.openldap.org/lists/openldap-software/200606/msg00252.html > > This problem arises in my test suite for nss-ldapd. Source can be > checked out at http://arthurenhella.demon.nl/svn/nss-ldapd/ (svn) and > the test file is (test/test_myldap.c). It uses a wrapper module (myldap) > around calls to OpenLDAP to simplify memory management. The function > that triggers the crash is test_threads(). > > I have captured the crash in gdb: > > # gdb /usr/sbin/slapd > GNU gdb 6.8-debian > [...] > This GDB was configured as "i486-linux-gnu"... > (gdb) r -d 1 -h ldap:/// ldaps:/// ldapi:/// -g openldap -u openldap -f > /etc/ldap/slapd.conf > Starting program: /usr/sbin/slapd -d 1 -h ldap:/// ldaps:/// ldapi:/// -g > openldap -u openldap -f /etc/ldap/slapd.conf > [Thread debugging using libthread_db enabled] > [New Thread 0xb7b3a930 (LWP 1542)] > @(#) $OpenLDAP: slapd 2.4.7 (Apr 16 2008 08:13:31) $ > @minerva.hungry.com:/home/pere/src/debiancvs/initscripts-ng-svn/trunk/src/insserv/openldap2.3-2.4.7/debian/build/servers/slapd > ldap_pvt_gethostbyname_a: host=sorbet, r=0 > daemon_init: listen on ldap:/// > daemon_init: 1 listeners to open... > [...] > <= send_search_entry: conn 2 exit. > entry_decode: "cn=Zaka Eddins+uid=zeddins,ou=lotsofpeople,dc=test,dc=tld" > <= entry_decode(cn=Zaka Eddins+uid=zeddins,ou=lotsofpeople,dc=test,dc=tld) > => send_search_entry: conn 2 dn="cn=Zaka > Eddins+uid=zeddins,ou=lotsofpeople,dc=test,dc=tld" > ber_flush2: 107 bytes to sd 18 > <= send_search_entry: conn 2 exit. > entry_decode: "uid=wvakil,ou=lotsofpeople,dc=test,dc=tld" > <= entry_decode(uid=wvakil,ou=lotsofpeople,dc=test,dc=tld) > => send_search_entry: conn 2 dn="uid=wvakil,ou=lotsofpeople,dc=test,dc=tld" > ber_flush2: 90 bytes to sd 18 > <= send_search_entry: conn 2 exit. > entry_decode: "uid=zmeeker,ou=lotsofpeople,dc=test,dc=tld" > <= entry_decode(uid=zmeeker,ou=lotsofpeople,dc=test,dc=tld) > => send_search_entry: conn 2 dn="uid=zmeeker,ou=lotsofpeople,dc=test,dc=tld" > ber_flush2: 92 bytes to sd 18 > <= send_search_entry: conn 2 exit. > bdb_search: 1104 scope not okay > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0xb5f18b90 (LWP 5017)] > 0xb7cef160 in pthread_mutex_lock () from /lib/libpthread.so.0 > (gdb) bt > #0 0xb7cef160 in pthread_mutex_lock () from /lib/libpthread.so.0 > #1 0xb7f4351d in ldap_pvt_thread_mutex_lock () from > /usr/lib/libldap_r-2.4.so.2 > #2 0xb783883d in bdb_cache_return_entry_rw (bdb=0x81ea358, e=0x820922c, rw=0, > lock=0xb5f16fd4) > at /home/pere/src/debiancvs/initscripts-ng-svn/trunk/src/insserv/openldap2.3-2.4.7/servers/slapd/back-bdb/cache.c:256 > #3 0xb782ce12 in bdb_search (op=0x8299b10, rs=0xb5f18168) > at /home/pere/src/debiancvs/initscripts-ng-svn/trunk/src/insserv/openldap2.3-2.4.7/servers/slapd/back-bdb/search.c:909 > #4 0x08077d13 in fe_op_search (op=0x8299b10, rs=0xb5f18168) > at /home/pere/src/debiancvs/initscripts-ng-svn/trunk/src/insserv/openldap2.3-2.4.7/servers/slapd/search.c:368 > #5 0x0807853c in do_search (op=0x8299b10, rs=0xb5f18168) > at /home/pere/src/debiancvs/initscripts-ng-svn/trunk/src/insserv/openldap2.3-2.4.7/servers/slapd/search.c:217 > #6 0x080757c6 in connection_operation (ctx=0xb5f18248, arg_v=0x8299b10) > at /home/pere/src/debiancvs/initscripts-ng-svn/trunk/src/insserv/openldap2.3-2.4.7/servers/slapd/connection.c:1083 > #7 0x08075ed6 in connection_read_thread (ctx=0xb5f18248, argv=0x13) > at /home/pere/src/debiancvs/initscripts-ng-svn/trunk/src/insserv/openldap2.3-2.4.7/servers/slapd/connection.c:1210 > #8 0xb7f42a44 in ?? () from /usr/lib/libldap_r-2.4.so.2 > #9 0xb5f18248 in ?? () > #10 0x00000013 in ?? () > #11 0x00000000 in ?? () > > A more detailed backtrace is available at the url specified below. > > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5470) Sporadic failures with RE24
by hyc＠symas.com 05 May '08

05 May '08

Raphaël Ouazana-Sustowski wrote: > Hi, > > Le Ven 2 mai 2008 11:01, hyc(a)symas.com a écrit : >> luca(a)OpenLDAP.org wrote: >>> luca(a)OpenLDAP.org wrote: >>>> This is a multi-part message in MIME format. >>>> --------------080809000906010300090306 >>>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >>>> Content-Transfer-Encoding: 7bit >>>> >>>> Howard Chu wrote: >>>> >>>>> Thanks. Please try HEAD again. >>>>> >>>> No way. >>>> new testrun directory in >>>> ftp://ftp.sys-net.it/luca_scamoni_its5470_20080430-new.tgz >>>> >>>> backtrace attached >>>> >>> recent commits seem to have fixed it (at least, right now I'm not able >>> to reproduce it anymore...) >> Right. Confirmed here too; I (temporarily) added an assert(0) to the >> offending >> branch of code to make sure the patch was actually getting hit. It takes a >> very particular timing to trigger that code path. >> >> I'm not sure how we can reliably test for this down the road. Perhaps we >> should add a "disabled" config keyword for backends and syncrepl >> consumers, so >> that we can start up the individual servers, (which takes an unpredictable >> amount of time for each) and then enable various parts in a fixed sequence >> (e.g. 1 second sleeps between ldapmodify/enable requests). Even that's hit >> or >> miss, because our test database is so small it's unlikely that we can hit >> the >> window of time on demand. > > I'm testing the last RE24 tag. After 201 successful runs of test050, I got > a failure :/ > Cleaning up test run directory leftover from previous run. > Running ./scripts/test050-syncrepl-multimaster... > running defines.sh > Initializing server configurations... > Starting producer slapd on TCP/IP port 9011... > Using ldapsearch to check that producer slapd is running... > Inserting syncprov overlay on producer... > Starting consumer slapd on TCP/IP port 9012... > Using ldapsearch to check that consumer slapd is running... > Configuring syncrepl on consumer... > Starting consumer2 slapd on TCP/IP port 9013... > Using ldapsearch to check that consumer2 slapd is running... > Configuring syncrepl on consumer2... > Adding schema and databases on producer... > Using ldapadd to populate producer... > Waiting 20 seconds for syncrepl to receive changes... > Using ldapadd to populate consumer... > 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... > Waiting 5 seconds for syncrepl to receive changes... > Waiting 5 seconds for syncrepl to receive changes... > Waiting 5 seconds for syncrepl to receive changes... > Waiting 5 seconds for syncrepl to receive changes... > Waiting 5 seconds for syncrepl to receive changes... > ldapsearch failed (32)! > > testrun uploaded in > ftp://ftp.openldap.org/incoming/raphael-ouazana-testrun-080505.tgz The logs show that the syncrepl consumers all timed out periodically, when trying to bind to a provider. It seems that using a 1 second timeout in the syncrepl configs is too short, or your test machine was too slow during that run. Probably we should remove that timeout now, since the cn=config/thread pause issue has already been resolved. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5488) syncrepl received contextCSN not passed on to syncprov consumers
by rein＠OpenLDAP.org 05 May '08

05 May '08

On Sun, 4 May 2008, hyc(a)symas.com wrote: > Rein Tollevik wrote: >> On Wed, 30 Apr 2008, Howard Chu wrote: >>> rein(a)OpenLDAP.org wrote: >>>> My first attempt at fixing this was to change syncprov to fetch the >>>> queued csn values from the glue backend where it was used. But that >>>> failed as other modules queues the csn values in their own backend when >>>> they changes things. >>> What other modules? Generally there cannot be any other sources of changes. >> >> Sorry, I should have written other configurations. The CSNs gets queued >> in the subordinate database when syncrepl is used there, or not at all >> (i.e in regular updates that comes in through the frontend). > > OK, but that's again quite a special case. I.e., that's multi-master; in the > default (single-master) case there cannot be regular updates arriving through > the frontend. When a single-master syncrepl consumer is configured, that is > the only possible source of updates. Let's be sure we've solved this question > for the single-master case first, before addressing the multi-master case. No, I'm thinking about single-master glued configurations where either: 1) The server is the single master for the subordinate backend or 2) The server is a syncrepl consumer for the subordinate backend, and syncrepl is configured on the subordinate db. In both cases is the CSN values queued in the subordinate database where syncprov looks for the values. The case that don't work is when syncrepl and syncprov are both used on the glue database, but still in single-master mode (although I don't think that matter). I.e, this server acts like a kind of forwarding server, it replicates the changes it receives from its producer to its own consumers. In this case syncrepl queues the CSN values in the glue database, while syncprov still looks for them in the subordinate database where the actual changes are made. > While it's expected that the software will be able to handle multiple glued > DBs and multi-master across them, I seriously doubt that anyone out there > actually knows how to configure and maintain such a setup yet. I haven't looked at multi-master yet, although I have multiple master servers that replicate between each other. But each backend database has a clearly defined single master, so this is not what I think about as multi-master configurations. >>>> Instead I changed ctxcsn.c so that it always >>>> queues them in the glue backend where syncprov is used. But I don't >>>> feel that my understanding of this stuff is good enough to be sure that >>>> this is the optimal solution.. >>> I definitely don't like references to the syncprov overlay appearing in main >>> slapd code like that. We need a different solution. > >> To me it makes sense to have a single queue of CSN values in a glued >> configuration, no matter if or where syncprov is used. > > Yes, I can probably go along with that. The downside is that it may reduce > write concurrency a bit, compared to a glued configuration where each glued DB > is otherwise independent. Which again should imply that the best fix probably is to change syncrepl so that it queues the csn values in the backends where the changes are made? >> Another approach could be to have syncprov look in the glue database if >> it fails to find any queued CSN in a subordinate db. I haven't tested >> it, but that should work in both configurations. It should also remove >> the need to always look for the glue db which my patch requires. Would >>> that be better? > > That sounds like a decent alternative. A new patch that implements this is at the end. Is this OK or should we go for the syncrepl alternative instead? >>>> Btw, in syncprov_checkpoint() there is a similar SLAP_GLUE_SUBORDINATE >>>> test, should that have included an overlay_is_inst() clause as well? >>> Perhaps. You would have to use op->o_bd->bd_self instead of op->o_bd on >>> that call. > >> The current test (introduced to fix ITS#5433) causes the contextCSN to >> be written to the glue database when syncprov is used on a subordinate >> db, which appears wrong to me. > > Understood. > > Again, the question is whether the admin intended to configure a single > syncprov over an entire glued DB, or individual syncprovs over each component > of the glued tree. The distinction is vital, and it's detected based on > whether the syncprov overlay is above the glue overlay in the overlay stack, > or below it, on the topmost DB. Yes, the first case is what I'm using, it works with the current code. The second is what I'm afraid got broken by this patch. Although I haven't tried the second type, so I'm not sure.. >> Could you elaborate on when op->o_bd->bd_self must be used instead of >> op->o_bd? I understand that op->o_bd may be a copy of the original >> structure that op->o_bd->bd_self refers to, but I'm not sure when it >> must be used. Btw, could op->o_bd->bd_self->bd_info be used to fetch >> the BackendInfo that can be used to call the top-most bd_search (and >> similar) also in overlays? > > If you read the code for overlay_is_inst() it should be obvious - that > function only works when used with a real BackendDB structure. The local copy > structure has had its bd_info replaced with whatever on_inst structure > corresponds to the current overlay. OK, I understand that one. I had hoped for a general rule, but am afraid that can't be given. And if we should continue this discussion I guess it's time to move it to openldap-devel. > Yes, the bd_self points to the topmost structure, so you can use it for > be_search. Much of what's happening in these overlays was intended to avoid > starting over at the top though, because the code is already running in the > desired overlay context. Ah, good. Using that is much clearer than to cast op->o_bd->bd_info into an overinst pointer and fetching it there :-) Rein Index: OpenLDAP/servers/slapd/overlays/syncprov.c =================================================================== RCS file: /f/CVSROOT/drift/OpenLDAP/servers/slapd/overlays/syncprov.c,v retrieving revision 1.20 diff -u -u -r1.20 syncprov.c --- OpenLDAP/servers/slapd/overlays/syncprov.c 5 May 2008 17:45:38 -0000 1.20 +++ OpenLDAP/servers/slapd/overlays/syncprov.c 5 May 2008 20:58:35 -0000 @@ -1589,6 +1589,17 @@ cbuf[0] = '\0'; ldap_pvt_thread_rdwr_wlock( &si->si_csn_rwlock ); slap_get_commit_csn( op, &maxcsn ); + if ( BER_BVISNULL( &maxcsn ) && SLAP_GLUE_SUBORDINATE( op->o_bd )) { + /* syncrepl queues the CSN values in the db where + * it is configured , not where the changes are made. + * So look for a value in the glue db if we didn't + * find any in this db. + */ + BackendDB *be = op->o_bd; + op->o_bd = select_backend( &be->be_nsuffix[0], 1); + slap_get_commit_csn( op, &maxcsn ); + op->o_bd = be; + } if ( !BER_BVISNULL( &maxcsn ) ) { int i, sid; strcpy( cbuf, maxcsn.bv_val );

1 0

Re: (ITS#5487) syncprov_findbase must search the backend from the syncrepl search
by rein＠OpenLDAP.org 05 May '08

05 May '08

On Sun, 4 May 2008, hyc(a)symas.com wrote: > Rein Tollevik wrote: >> A new patch that I hope should fix this is at the end. It always use >> be_search, after putting back the original bd_info if needed. I feel >> that using the generic be_search is better than interfering directly >> with the overlay code as overlay_op_walk does. I also tested for >> SLAP_ISOVERLAY rather than PS_IS_REFRESHING, as that appeared more >> generic to me. But again, I may be totally wrong here. Does this >> patch look better? > > SLAP_IS_OVERLAY will never be true here. That flag is only set when the > BackendDB being tested is a local copy of a real BackendDB structure. The > structure referenced in s_op is always a real BackendDB. No, it is true when syncprov_findbase is called from syncprov_op_search, as s_op is the op passed to that function. The new patch at the end uses o_bd->bd_self, which should eliminate this test since copying the db is not necessary. > In fact, if you're always going to use s_op and be_search, there's no > further work needed, because the regular overlay infrastructure will > always make a new local BackendDB copy itself. (And of course, some of > that would be wasted effort, which is why the original code uses > overlay_op_walk. Since op->o_bd is already an overlay DB, there's no > need to make yet another copy for the first-search case.) I understand, but I still prefer the clarity of always using be_search. After all, this function is only called the first time a consumer is initialized or after an update of the search base entry. I.e the few extra cycles shouldn't be measurable, even when the search base is the glue suffix where updates of the contextCSN causes the entry to be written more often than most other entries. Rein Index: OpenLDAP/servers/slapd/overlays/syncprov.c =================================================================== RCS file: /f/CVSROOT/drift/OpenLDAP/servers/slapd/overlays/syncprov.c,v retrieving revision 1.1.1.18 retrieving revision 1.20 diff -u -u -r1.1.1.18 -r1.20 --- OpenLDAP/servers/slapd/overlays/syncprov.c 30 Apr 2008 11:17:58 -0000 1.1.1.18 +++ OpenLDAP/servers/slapd/overlays/syncprov.c 5 May 2008 17:45:38 -0000 1.20 @@ -404,7 +404,6 @@ slap_callback cb = {0}; Operation fop; SlapReply frs = { REP_RESULT }; - BackendInfo *bi; int rc; fc->fss->s_flags ^= PS_FIND_BASE; @@ -412,11 +411,10 @@ fop = *fc->fss->s_op; + fop.o_bd = fop.o_bd->bd_self; fop.o_hdr = op->o_hdr; - fop.o_bd = op->o_bd; fop.o_time = op->o_time; fop.o_tincr = op->o_tincr; - bi = op->o_bd->bd_info; cb.sc_response = findbase_cb; cb.sc_private = fc; @@ -434,8 +432,7 @@ fop.ors_filter = &generic_filter; fop.ors_filterstr = generic_filterstr; - rc = overlay_op_walk( &fop, &frs, op_search, on->on_info, on ); - op->o_bd->bd_info = bi; + rc = fop.o_bd->be_search( &fop, &frs ); } else { ldap_pvt_thread_mutex_unlock( &fc->fss->s_mutex ); fc->fbase = 1;

1 0

(ITS#5496) delta-syncrepl consumers don't update backend contextCSN after processing each entry
by jwm＠horde.net 05 May '08

05 May '08

Full_Name: John Morrissey Version: 2.3.41 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (66.133.190.110) delta-syncrepl does not update the backend's contextCSN after processing each replication event. This exposes slapd to problems in the event of a power loss, crash, etc. as it will attempt to re-process the replication entries once re-started. Relevant thread on openldap-software starts here: http://marc.info/?l=openldap-software&m=120965853100883&w=2 and Howard's summary of the behavior is here: http://marc.info/?l=openldap-software&m=120967526528453&w=2

1 0

Re: (ITS#5470) Sporadic failures with RE24
by raphael.ouazana＠linagora.com 05 May '08

05 May '08

Hi, Le Ven 2 mai 2008 11:01, hyc(a)symas.com a écrit : > luca(a)OpenLDAP.org wrote: >> luca(a)OpenLDAP.org wrote: >>> This is a multi-part message in MIME format. >>> --------------080809000906010300090306 >>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >>> Content-Transfer-Encoding: 7bit >>> >>> Howard Chu wrote: >>> >>>> Thanks. Please try HEAD again. >>>> >>> No way. >>> new testrun directory in >>> ftp://ftp.sys-net.it/luca_scamoni_its5470_20080430-new.tgz >>> >>> backtrace attached >>> >> recent commits seem to have fixed it (at least, right now I'm not able >> to reproduce it anymore...) > > Right. Confirmed here too; I (temporarily) added an assert(0) to the > offending > branch of code to make sure the patch was actually getting hit. It takes a > very particular timing to trigger that code path. > > I'm not sure how we can reliably test for this down the road. Perhaps we > should add a "disabled" config keyword for backends and syncrepl > consumers, so > that we can start up the individual servers, (which takes an unpredictable > amount of time for each) and then enable various parts in a fixed sequence > (e.g. 1 second sleeps between ldapmodify/enable requests). Even that's hit > or > miss, because our test database is so small it's unlikely that we can hit > the > window of time on demand. I'm testing the last RE24 tag. After 201 successful runs of test050, I got a failure :/ Cleaning up test run directory leftover from previous run. Running ./scripts/test050-syncrepl-multimaster... running defines.sh Initializing server configurations... Starting producer slapd on TCP/IP port 9011... Using ldapsearch to check that producer slapd is running... Inserting syncprov overlay on producer... Starting consumer slapd on TCP/IP port 9012... Using ldapsearch to check that consumer slapd is running... Configuring syncrepl on consumer... Starting consumer2 slapd on TCP/IP port 9013... Using ldapsearch to check that consumer2 slapd is running... Configuring syncrepl on consumer2... Adding schema and databases on producer... Using ldapadd to populate producer... Waiting 20 seconds for syncrepl to receive changes... Using ldapadd to populate consumer... 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... Waiting 5 seconds for syncrepl to receive changes... Waiting 5 seconds for syncrepl to receive changes... Waiting 5 seconds for syncrepl to receive changes... Waiting 5 seconds for syncrepl to receive changes... Waiting 5 seconds for syncrepl to receive changes... ldapsearch failed (32)! testrun uploaded in ftp://ftp.openldap.org/incoming/raphael-ouazana-testrun-080505.tgz Regards, Raphaël Ouazana.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs