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
<[email protected]>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 <[email protected]>wrote:
>
>> --On Friday, July 12, 2013 5:40 PM +0530 Ashok <[email protected]>
>> 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
