openldap-bugs

openldap-bugs@openldap.org

1 participants
20966 discussions

Re: (ITS#5465) Delta-Syncrepl cookie problems
by quanah＠zimbra.com 12 Apr '08

12 Apr '08

--On Saturday, April 12, 2008 10:14 AM -0700 Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > I realized last night that this is likely due to the race condition issue > between syncprov & syncrepl when check pointing the cookie. The > replica's run the syncprov overlay so that we can see the cookie as it's > a glue DB. They also have a check point line. I'll have the checkpoint > line removed on the replicas. Never mind, I was incorrect. The syncprov-checkpoint line is not present on the replicas, only "overlay syncprov", so this isn't it. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5465) Delta-Syncrepl cookie problems
by quanah＠zimbra.com 12 Apr '08

12 Apr '08

--On Friday, April 11, 2008 9:33 PM +0000 quanah(a)zimbra.com wrote: > So it's clear that the update took on the replica. I restarted slapd, > and it started replicating correctly. So it looks like there's a problem > where internally it thinks it is on a previous cookie to what it has > already committed. I realized last night that this is likely due to the race condition issue between syncprov & syncrepl when check pointing the cookie. The replica's run the syncprov overlay so that we can see the cookie as it's a glue DB. They also have a check point line. I'll have the checkpoint line removed on the replicas. Does this sound correct, as per the note Howard made recently about this issue? --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#4890) Default Values overlay (patch)
by ando＠sys-net.it 12 Apr '08

12 Apr '08

docelic(a)spinlocksolutions.com wrote: > The contrib section does not have usable makefiles (nor the system > to create them). Usually, building a contrib does not require much makefile stuff. > Putting this overlay in contrib, where it would be unmaintained > and practically broken right away from the start (due to missing > build integration) doesn't make any sense. It makes sense: if we integrate it in the mainstream source and it breaks because it's unmaintained, then the distribution is broken > People interested in the overlay are able to download it from > the maintained location at: > > http://techpubs.spinlocksolutions.com/openldap/ Well, in that case you have to guarantee that the URL remains valid over time. If you put it in contrib/ the OpenLDAP project guarantees (sort of) it remains available. To the average potential user, I guess it's the same level of guarantee :) 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5408) back-ldif bugs
by hyc＠symas.com 11 Apr '08

11 Apr '08

h.b.furuseth(a)usit.uio.no wrote: > Here are a bunch of back-ldif bugs some questions. I have code for most > of it, but need advice/discussion on functionality changes. > - When back-ldif uses OS-specific escaping, we can't move a directory > tree between Windows and Unix hosts if some RDN in the tree contains > characters with OS-specific escaping. This is never a priority. The only documented way to move databases is via slapcat/slapadd. I'm perfectly fine with a Windows-specific special case that simply maps all forbidden characters to control-characters, or some other equally obscure approach. (E.g. map all forbidden characters to the same character.) The typical Windows admin will never see the raw filenames anyway. -- -- 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

(ITS#5465) Delta-Syncrepl cookie problems
by quanah＠zimbra.com 11 Apr '08

11 Apr '08

Full_Name: Quanah Gibson-Mount Version: 2.3.41 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (24.23.156.219) I have a replica spitting out the following error in its logs (master and replica running OpenLDAP 2.3.41): Apr 11 13:28:03 123-ldap-3 slapd[21846]: syncrepl_message_to_op: rid 100 be_modify uid=xxxxx,ou=people,dc=123,dc=abc,dc=edu (20) It's syncrepl cookie is: contextCSN: 20080410145621Z#000000#00#000000 Looking at the accesslog on the master, I see (for this time period): dn: reqStart=20080410145621.000001Z,cn=accesslog objectClass: auditModify structuralObjectClass: auditModify reqStart: 20080410145621.000001Z reqEnd: 20080410145621.000003Z reqType: modify reqSession: 190486 reqAuthzID: uid=zimbra,cn=admins,cn=zimbra reqDN: uid=xxxxx,ou=people,dc=123,dc=abc,dc=edu reqResult: 0 reqMod: zimbraPasswordLockoutFailureTime:+ 20080410145621Z reqMod: zimbraPasswordLockoutFailureTime:- 20080410145230Z reqMod: entryCSN:= 20080410145621Z#000000#00#000000 reqMod: modifiersName:= uid=zimbra,cn=admins,cn=zimbra reqMod: modifyTimestamp:= 20080410145621Z entryUUID: 06ac9202-9b5a-102c-8816-1596598f2bf0 creatorsName: cn=accesslog createTimestamp: 20080410145621Z entryCSN: 20080410145621Z#000000#00#000000 modifiersName: cn=accesslog modifyTimestamp: 20080410145621Z dn: reqStart=20080410145621.000027Z,cn=accesslog objectClass: auditModify structuralObjectClass: auditModify reqStart: 20080410145621.000027Z reqEnd: 20080410145621.000028Z reqType: modify reqSession: 190494 reqAuthzID: uid=zimbra,cn=admins,cn=zimbra reqDN: uid=yyyy_07,ou=people,dc=123,dc=abc,dc=edu reqResult: 0 reqMod: zimbraPasswordLockoutFailureTime:+ 20080410145621Z reqMod: entryCSN:= 20080410145621Z#000001#00#000000 reqMod: modifiersName:= uid=zimbra,cn=admins,cn=zimbra reqMod: modifyTimestamp:= 20080410145621Z entryUUID: 06ee59c6-9b5a-102c-8817-1596598f2bf0 creatorsName: cn=accesslog createTimestamp: 20080410145621Z entryCSN: 20080410145621Z#000001#00#000000 modifiersName: cn=accesslog modifyTimestamp: 20080410145621Z So as I understand (delta)syncrepl, the replica knows it already received the update for uid=xxxxx, and yet it is still trying to process that update, rather than the next one for uid=yyyy_07. The entry on the replica has: dn: uid=xxxxx,ou=people,dc=123,dc=abc,dc=edu zimbraPasswordLockoutFailureTime: 20080410145515Z zimbraPasswordLockoutFailureTime: 20080410145516Z zimbraPasswordLockoutFailureTime: 20080410145519Z zimbraPasswordLockoutFailureTime: 20080410145539Z zimbraPasswordLockoutFailureTime: 20080410145547Z zimbraPasswordLockoutFailureTime: 20080410145548Z zimbraPasswordLockoutFailureTime: 20080410145621Z So it's clear that the update took on the replica. I restarted slapd, and it started replicating correctly. So it looks like there's a problem where internally it thinks it is on a previous cookie to what it has already committed. --Quanah

1 0

Re: (ITS#4890) Default Values overlay (patch)
by docelic＠spinlocksolutions.com 11 Apr '08

11 Apr '08

The contrib section does not have usable makefiles (nor the system to create them). Putting this overlay in contrib, where it would be unmaintained and practically broken right away from the start (due to missing build integration) doesn't make any sense. People interested in the overlay are able to download it from the maintained location at: http://techpubs.spinlocksolutions.com/openldap/ Davor Ocelic Spinlock Solutions http://www.spinlocksolutions.com/

1 0

Re: (ITS#5463) syncrepl stops or pauses
by marian.eichholz＠freenet.ag 11 Apr '08

11 Apr '08

On Fri, Apr 11, 2008 at 11:34:33AM +0200, Rein Tollevik wrote: > This sounds a lot like the problems we had, see ITS#5454. Replication > has been running smootly since we implemented the patch included there. OK, we switched to the CVS version (openldap-20080411). The patch is rejected, as You might guess :-) The problem persists more or less, anyway. FYI: Whenever the replication stops, in the provider-log (sync, conns) there is a line: Apr 11 15:30:12 1 slapd[8994]: ber_flush2 failed errno=11 reason="Resource temporarily unavailable" I don't know if this is really meaningful. Just for those people not too familiar with CVS: How can I retrieve that very branch, where the hunk in ITS 5454 would succeed? Thank You very much in advance, anyway, and the help in the past! -- Mit freundlichen Gruessen / Yours sincerely Marian Eichholz Postmaster

1 0

Re: (ITS#5463) syncrepl stops or pauses
by hyc＠symas.com 11 Apr '08

11 Apr '08

rein(a)basefarm.no wrote: > marian.eichholz(a)freenet.ag skrev: >> Full_Name: >> Version: 2.4.8 >> OS: Linux 2.6.23.13 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (194.97.7.65) >> >> The replication may suddenly stop, and we see no reason for that. Sometimes it >> recovers by itself, sometimes it recovers only when the consumer slapd is >> stopped and restarted. >> Is there a "golden path" to debug this issue? > > This sounds a lot like the problems we had, see ITS#5454. Replication > has been running smootly since we implemented the patch included there. > > An alternative version is implemented in the CVS head release, but that > lacks a change from trylock to real mutex lock before the race condition > is fully closed. > > We experienced a lot of replication problems after upgrading from a > slurpd based replication in 2.3.x to syncrepl in 2.4.8. We are > currently using the CVS head version (as it was about a week ago), and > most of our problems has been solved there :-) You should consider the > cvs version, as it has many syncrepl and syncprov fixes. At this point it would be better to test RE24, not HEAD. -- -- 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#5454) syncrepl refreshAndPersist stops receiving
by hyc＠symas.com 11 Apr '08

11 Apr '08

Hallvard B Furuseth wrote: > hyc(a)symas.com writes: >> OK, reverted the trylock (which was put there in rev 1.376). I >> unfortunately don't remember what prompted that commit; certainly >> there was no ITS associated with it. > > It was committed 9 minutes before this message: > http://www.openldap.org/lists/openldap-devel/200802/msg00032.html > Thanks for that reference. test050 is fine right now; I think rev 1.381 was the more correct fix for that problem. -- -- 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#5454) syncrepl refreshAndPersist stops receiving
by h.b.furuseth＠usit.uio.no 11 Apr '08

11 Apr '08

hyc(a)symas.com writes: > OK, reverted the trylock (which was put there in rev 1.376). I > unfortunately don't remember what prompted that commit; certainly > there was no ITS associated with it. It was committed 9 minutes before this message: http://www.openldap.org/lists/openldap-devel/200802/msg00032.html -- Hallvard

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