[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: syncrepl issue not replicating all changes

On Wed, 25 Apr 2012, Mark Coetser wrote:
the thing is that all the versions on the servers are all the same so if it was a bug surely the issue would occur across all the servers?
Most of the bugs that make it far enough to ship in a tagged release are quite a bit more subtle than 100% reproducibility. Especially with replication, there are extremely minute timing subtleties/races/etc. (Things that are that easy to find tend to make it into the test suite, after all.)
another issue is that using debian stable due too internal company policies means that I would have too stick too the current version until a newer version is released within the debian stable package tree. 

Not necessarily the best idea...
Is there no way too debug the syncrepl too try and see if I can find the cause?
Of course you can; that's the beauty of an open project. Runtime, "slapd -d sync" and similar (see slapd(8)/slapd.conf(5) man pages). For potentially faster results, you can go to http://www.openldap.org/its/ and read through the debugging, triage, and resolution that occurred for known issues. Perhaps you could reproduce those steps in your environment, to confirm if your scenario matches.
And assuming there's a match in the ITS, you'd mail debian stable with "hey, OpenLDAP fixed their ITS#1234 five months ago, let's get that fix into debian stable?"
And Debian would probably write you back with something similar to: http://www.openldap.org/faq/data/cache/1456.html
And then you'd end up going to www.openldap.org and upgrading to the latest published release, OR saying "this is a known issue of debian stable, debian stable is desired via internal policies, therefore this known issue is desired under internal policies. Don't complain about things that are desired."