5:47 p.m.
Hi all,
Can somebody please confirm for me, when a log entry on a
consumer says:
do_syncrep2: rid 123 Can't contact LDAP server
I've been assuming it means the provider server, is that correct?
It's just occurred to me it could possibly be referring to the local
server since I believe there are multiple threads involved in a single
slapd process.
--
Lesley Walker
Linux Systems Administrator
Opus International Consultants Ltd
Email lesley.walker(a)opus.co.nz
Tel +64 4 471 7002, Fax +64 4 473 3017
http://www.opus.co.nz
Level 9 Majestic Centre, 100 Willis Street, PO Box 12 343
Wellington, New Zealand
6:57 p.m.
--On Friday, April 20, 2007 12:47 PM +1200 Lesley Walker
<lesley.walker(a)opus.co.nz> wrote:
Hi all,
Can somebody please confirm for me, when a log entry on a
consumer says:
do_syncrep2: rid 123 Can't contact LDAP server
I've been assuming it means the provider server, is that correct?
It's just occurred to me it could possibly be referring to the local
server since I believe there are multiple threads involved in a single
slapd process.
It would be the remote server. It doesn't try and contact itself.
--Quanah
--
Quanah Gibson-Mount
Senior Systems Software Developer
ITS/Shared Application Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
8:20 p.m.
Quanah Gibson-Mount wrote:
It would be the remote server. It doesn't try and contact
itself.
Okay, thanks.
Next questions:
When the replication is going through the refresh-present phase, am I
correct in believing that the ADD entries are written only for entries
that didn't previously exist in the consumer? So if there are, say, 20
ADD entries in the log, that means 20 entries that didn't exist at all
in the the consumer database?
When I see the following in the log (this was immediately after a reboot):
Config: ** successfully added syncrepl "ldap://wwsv04.opus.co.nz"
slapd starting
syncrepl_entry: rid 123 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
syncrepl_entry: rid 123 be_search (0)
syncrepl_entry: rid 123 dc=example,dc=co,dc=nz
syncrepl_entry: rid 123 be_modify (0)
syncrepl_entry: rid 123 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
syncrepl_entry: rid 123 be_search (0)
syncrepl_entry: rid 123 uid=someuser,ou=People,dc=example,dc=co,dc=nz
do_syncrep2: rid 123 LDAP_RES_INTERMEDIATE - REFRESH_DELETE
Should I take it to mean that the *entire* *tree* of
dc=example,dc=co,dc=nz was previously missing? and it now contains only
the one user "someuser"?
This would mean that the database was completely empty at that point.
Surely it should immediately start doing about 9000 ADDs to get the rest
of the database in sync - but it doesn't. It just remains in that state,
until we take some action, either resetting the sync cookie or deleting
the database and forcing it to rebuild.
This is still with version 2.3.32, I'm investigating a number of
incidents looking for common factors and trying to determine exactly
what happens.
--
Lesley Walker
Linux Systems Administrator
Opus International Consultants Ltd
Email lesley.walker(a)opus.co.nz
Tel +64 4 471 7002, Fax +64 4 473 3017
http://www.opus.co.nz
Level 9 Majestic Centre, 100 Willis Street, PO Box 12 343
Wellington, New Zealand
12:41 p.m.
--On Friday, April 20, 2007 3:20 PM +1200 Lesley Walker
<lesley.walker(a)opus.co.nz> wrote:
Quanah Gibson-Mount wrote:
> It would be the remote server. It doesn't try and contact itself.
Okay, thanks.
Next questions:
When the replication is going through the refresh-present phase, am I
correct in believing that the ADD entries are written only for entries
that didn't previously exist in the consumer? So if there are, say, 20
ADD entries in the log, that means 20 entries that didn't exist at all in
the the consumer database?
There have been a number of syncrepl bugs fixed since 2.3.32. I understand
the reasons behind sticking with stable (although I strongly disagree with
that entire thought process). I guess this is something you'll have to
live with until a new release is tagged stable. It may still occur after
that point, but then we'd know for certain it wasn't fixed by the bug fixes
that I've found have definitely fixed other syncrepl related issues.
Unless, of course, you are willing to upgrade & and can reproduce the
results with 2.3.35 (which would be helpful to the project, of course).
--Quanah
--
Quanah Gibson-Mount
Senior Systems Software Developer
ITS/Shared Application Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
3:16 p.m.
Quanah Gibson-Mount wrote:
<lesley.walker(a)opus.co.nz> wrote:
> When the replication is going through the refresh-present phase, am I
> correct in believing that the ADD entries are written only for entries
> that didn't previously exist in the consumer? So if there are, say, 20
> ADD entries in the log, that means 20 entries that didn't exist at all in
> the the consumer database?
There have been a number of syncrepl bugs fixed since 2.3.32.
With respect, I'm not trying to address any bugs with this question.
I would like to be assured that I'm interpreting the logs correctly so I
can figure out what's going on, which will will help me to determine how
the unwanted behaviour is triggered, which will help me reproduce the
problem, and when I can do that, I can test with the new version.
--
Lesley Walker
Linux Systems Administrator
Opus International Consultants Ltd
Email lesley.walker(a)opus.co.nz
Tel +64 4 471 7002, Fax +64 4 473 3017
http://www.opus.co.nz
Level 9 Majestic Centre, 100 Willis Street, PO Box 12 343
Wellington, New Zealand
5888
days inactive
5890
days old
openldap-software@openldap.org
4 comments
2 participants
participants (2)
-
Lesley Walker -
Quanah Gibson-Mount