5:17 a.m.
Hello,
I would like to ask you for your guidance regarding the following.
We have an openldap (v2.4.56) master server syncing with three other
openldap slaves.
The master seems being unable to complete successfully syncing a
particular entry and it keeps trying for ever. Logs follow.
I have realized this only now, but it seems that this is happening for
long. (It is recorded in all the logs I have available.)
What is the suggested way to resolve this situation?
=======================================================================================================
...
Jan 16 14:48:09 ldap.noa.gr slapd[1655]: conn=1048 op=1
syncprov_search_response: Entry cn=thermo,ou=Aliases,dc=noa,dc=gr CSN
20200910151806.461875Z#000000#000#000000 older or equal to ctx
20200910151806.461875Z#000000#000#000000
Jan 16 14:48:09 ldap.noa.gr slapd[1655]: conn=1048 op=1
syncprov_search_response:
cookie=rid=601,csn=20210116055411.875566Z#000000#000#000000
Jan 16 14:48:09 ldap.noa.gr slapd[1655]: conn=1048 op=1
syncprov_sendinfo: refreshPresent
cookie=rid=601,csn=20210116055411.875566Z#000000#000#000000
Jan 16 14:48:09 ldap.noa.gr slapd[1655]: conn=1048 op=1
syncprov_search_response: detaching op
Jan 16 14:51:09 ldap.noa.gr slapd[1655]: conn=1058 op=1
syncprov_op_search: got a persistent search with a
cookie=rid=601,csn=20200910151806.461875Z#000000#000#000000
Jan 16 14:51:09 ldap.noa.gr slapd[1655]: conn=1058 op=1
syncprov_findbase: searching
Jan 16 14:51:09 ldap.noa.gr slapd[1655]: conn=1058 op=1
syncprov_op_search: registered persistent search
Jan 16 14:51:09 ldap.noa.gr slapd[1655]: conn=1058 op=1
syncprov_findcsn: mode=FIND_CSN csn=20200910151806.461875Z#000000#000#000000
Jan 16 14:51:09 ldap.noa.gr slapd[1655]: conn=1058 op=1
syncprov_findcsn: csn==20200910151806.461875Z#000000#000#000000 found
Jan 16 14:51:09 ldap.noa.gr slapd[1655]: conn=1058 op=1
syncprov_findcsn: mode=FIND_PRESENT csn=
Jan 16 14:51:09 ldap.noa.gr slapd[1655]: conn=1058 op=1
syncprov_sendinfo: present syncIdSet cookie=
Jan 16 14:51:09 ldap.noa.gr slapd[1655]: conn=1058 op=1
syncprov_sendinfo: present syncIdSet cookie=
Jan 16 14:51:09 ldap.noa.gr slapd[1655]: conn=1058 op=1
syncprov_sendinfo: present syncIdSet cookie=
Jan 16 14:51:09 ldap.noa.gr slapd[1655]: conn=1058 op=1
syncprov_sendinfo: present syncIdSet cookie=
Jan 16 14:51:09 ldap.noa.gr slapd[1655]: conn=1058 op=1
syncprov_sendinfo: present syncIdSet cookie=
Jan 16 14:51:09 ldap.noa.gr slapd[1655]: conn=1058 op=1
syncprov_sendinfo: present syncIdSet cookie=
Jan 16 14:51:09 ldap.noa.gr slapd[1655]: conn=1058 op=1
syncprov_sendinfo: present syncIdSet cookie=
Jan 16 14:51:09 ldap.noa.gr slapd[1655]: conn=1058 op=1
syncprov_sendinfo: present syncIdSet cookie=
Jan 16 14:51:09 ldap.noa.gr slapd[1655]: conn=1058 op=1
syncprov_sendinfo: present syncIdSet cookie=
Jan 16 14:51:09 ldap.noa.gr slapd[1655]: conn=1058 op=1
syncprov_sendinfo: present syncIdSet cookie=
Jan 16 14:51:09 ldap.noa.gr slapd[1655]: conn=1058 op=1
syncprov_sendinfo: present syncIdSet cookie=
Jan 16 14:51:09 ldap.noa.gr slapd[1655]: conn=1058 op=1
syncprov_sendinfo: present syncIdSet cookie=
Jan 16 14:51:09 ldap.noa.gr slapd[1655]: conn=1058 op=1
syncprov_search_response: Entry cn=thermo,ou=Aliases,dc=noa,dc=gr CSN
20200910151806.461875Z#000000#000#000000 older or equal to ctx
20200910151806.461875Z#000000#000#000000
Jan 16 14:51:09 ldap.noa.gr slapd[1655]: conn=1058 op=1
syncprov_search_response:
cookie=rid=601,csn=20210116055411.875566Z#000000#000#000000
Jan 16 14:51:09 ldap.noa.gr slapd[1655]: conn=1058 op=1
syncprov_sendinfo: refreshPresent
cookie=rid=601,csn=20210116055411.875566Z#000000#000#000000
Jan 16 14:51:09 ldap.noa.gr slapd[1655]: conn=1058 op=1
syncprov_search_response: detaching op
=========================================================================================================
Thank you in advance for your advice!
Cheers,
Nick
8:27 a.m.
--On Saturday, January 16, 2021 3:17 PM +0200 Nick Milas
<nick(a)eurobjects.com> wrote:
Hello,
I would like to ask you for your guidance regarding the following.
Hi Nick,
Nothing in the log snippet provided shows an issue. What leads you to
believe an issue has been encountered?
Regards,
Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
2:57 p.m.
On 18/1/2021 6:27 μ.μ., Quanah Gibson-Mount wrote:
Nothing in the log snippet provided shows an issue. What leads you
to
believe an issue has been encountered?
Hi Quanah,
Thanks for the reply,
I can't tell whether it was an issue or not (for example, I could call
it a phenomenon), but I found it strange to have this repeating for
weeks every three minutes and always on that single entry (among
thousands).
I am trying to figure out what does the log snippet mean. I would guess
it means that the particular entry at the master DIT is found to be
older than the one at the slave?
If so, I wonder how this may have happened! Maybe due to a DIT change
that took place at some point in time when the master clock was a bit
slower than the slave? (Although both are running ntp service.)
And - in any case - what would be the recommended way to stop this from
occurring constantly?
My poor man's action would be to do some modification on the entry (at
the master). It might not be an elegant, or even suggested solution, but
it would force a resync of the entry at the slave, updating times. In
the end I tried this and and I have since stopped seeing this message
showing in the log.
Thanks!
Nick
2:46 a.m.
On Sat, Jan 23, 2021 at 12:57:37AM +0200, Nick Milas wrote:
On 18/1/2021 6:27 μ.μ., Quanah Gibson-Mount wrote:
> Nothing in the log snippet provided shows an issue. What leads you to
> believe an issue has been encountered?
Hi Quanah,
Thanks for the reply,
I can't tell whether it was an issue or not (for example, I could call it a
phenomenon), but I found it strange to have this repeating for weeks every
three minutes and always on that single entry (among thousands).
I am trying to figure out what does the log snippet mean. I would guess it
means that the particular entry at the master DIT is found to be older than
the one at the slave?
Something writes to your consumer, if you have a MMR environment, you
want to assign different serverids. Otherwise you want to figure out how
the change happened and either fix the offending service or set up
chaining on consumers.
If so, I wonder how this may have happened! Maybe due to a DIT change
that
took place at some point in time when the master clock was a bit slower than
the slave? (Although both are running ntp service.)
And - in any case - what would be the recommended way to stop this from
occurring constantly?
Regards,
--
Ondřej Kuzník
Senior Software Engineer
Symas Corporation http://www.symas.com
Packaged, certified, and supported LDAP solutions powered by OpenLDAP
1:24 p.m.
--On Monday, January 25, 2021 11:46 AM +0100 Ondřej Kuzník
<ondra(a)mistotebe.net> wrote:
Something writes to your consumer, if you have a MMR environment,
you
want to assign different serverids. Otherwise you want to figure out how
the change happened and either fix the offending service or set up
chaining on consumers.
Also note that if this is an MMR environment, serverID values must be > 0
and unique across the MMR environment (The log shows a "0" serverID in use).
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
794
days inactive
803
days old
openldap-technical@openldap.org
4 comments
3 participants
participants (3)
-
Nick Milas -
Ondřej Kuzník -
Quanah Gibson-Mount