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.comwrote:
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.comwrote:
--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