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.
--On Friday, April 20, 2007 12:47 PM +1200 Lesley Walker lesley.walker@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
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.
--On Friday, April 20, 2007 3:20 PM +1200 Lesley Walker lesley.walker@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
Quanah Gibson-Mount wrote:
lesley.walker@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.
openldap-software@openldap.org
-
Lesley Walker -
Quanah Gibson-Mount