[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.