Has it ever worked correctly?  It sounds to me as if you're having the same issue I did to begin with, being that you do not have the appropriate permissions for the accessLog database.  This fixed the issue for me. (my accessLog database is 2)

dn: olcDatabase={2}hdb,cn=config
changetype: modify
replace: olcAccess
olcAccess: to * by dn="uid=user.name,ou=xxxxx,dc=xxxxx,dc=com" read

On Sun, Jul 14, 2013 at 12:05 PM, Ashok Kumar Shah <ashok.shah@flipkart.com> wrote:
I am running OpenLDAP 2.4.23. Looks like syncrepl has stuck i am seeing this message from last 2 days every minute i see this message popping up on the logs perhaps  this the reason of huge slave lag is 2 days and some hours. Is there a fix for this?
 syncrepl_message_to_op: rid=011 be_modrdn uid=user.name,ou=xxxxx,dc=xxxx,dc=com (68)
 do_syncrepl: rid=011 rc 68 retrying

Thanks,
Ashok


On Fri, Jul 12, 2013 at 9:26 PM, Quanah Gibson-Mount <quanah@zimbra.com> wrote:
--On Friday, July 12, 2013 5:40 PM +0530 Ashok <ashok.shah@flipkart.com> wrote:






Hi,

I am running ldap master and multiple slave with RefreshandPersist config.
 ldap search for an user shows different set  of records. ContextCSN on
master and slave are exactly same.
What can i do to fix this. I tried restarting slave ldap but didn't help.
Also i keep getting do_syncrepl: rid=112 rc 68 retrying every minute. I
doubt if there is replication issue.

It sounds like it is resyncing the DB, and skipping entries that already exist:  LDAP_ALREADY_EXISTS is error code 68.


--Quanah



--

Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.
--------------------
Zimbra ::  the leader in open source messaging and collaboration




--
Jason K. Brandt
Systems Administrator
Bradley University
(309) 677-2958