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)
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 <email@example.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,AshokOn Fri, Jul 12, 2013 at 9:26 PM, Quanah Gibson-Mount <firstname.lastname@example.org> wrote:
It sounds like it is resyncing the DB, and skipping entries that already exist: LDAP_ALREADY_EXISTS is error code 68.--On Friday, July 12, 2013 5:40 PM +0530 Ashok <email@example.com> wrote:
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.
Sr. Member of Technical Staff
A Division of VMware, Inc.
Zimbra :: the leader in open source messaging and collaboration
Jason K. BrandtSystems AdministratorBradley University