[Date Prev][Date Next] [Chronological] [Thread] [Top]

(ITS#8396) syncprov hourly fails to answer syncrepl



Full_Name: Francis Swasey
Version: 2.4.44
OS: Red Hat Enterprise Linux Server release 7.2 (Maipo)
URL: http://www.uvm.edu/~fcs/openldap_its/syncprov_files.tar.gz
Submission from: (NULL) (132.198.104.198)


Once an hour, the primary server logs a syncprov_sendresp that does not include
a csn.  When that happens, the replica misses that there were changes and does
not update and therefore falls behind.

The URI provides files for the primary and replica.  

replica/slapd_db.ldif -- starting database
replica/slapd.conf -- replica's slapd configuration file (you'll need to create
your own ssl certs)
replica/syncrepl_audit.sh -- Runs on the replica (edit the email address and the
path to check_syncrepl
replica/check_syncrepl -- Used by nagios to report csn being in sync or not

primary/slapd_db.ldif -- starting database (almost exactly like the replica's
version)
primary/slapd.conf -- primary's slapd configuration file (you'll need to create
your own ssl certs)
primary/syncprov_audit.sh -- greps the system log (edit the path) looking for
the syncprov error
primary/makechanges.sh -- edit to change the name of the ldap server and run
this to make constant changes

The bad log entries that coincide with check_syncrepl finding the replica has
fallen behind are like:

Apr  4 13:18:27 ldap7p slapd[27800]: syncprov_sendresp: cookie=rid=100
Apr  4 13:18:27 ldap7p slapd[27800]: syncprov_sendresp: cookie=rid=100
Apr  4 14:18:53 ldap7p slapd[27800]: syncprov_sendresp: cookie=rid=100
Apr  4 14:18:53 ldap7p slapd[27800]: syncprov_sendresp: cookie=rid=100

They appear once an hour.