https://bugzilla.redhat.com/show_bug.cgi?id=820258 (Red Hat Enterprise Linux 6)
Description of problem: Change in winSyncInterval does not take immediate effect Version-Release number of selected component (if applicable): 389-ds-base-1.2.10.2-6.el6.x86_64 How reproducible: Always Steps to Reproduce: 1. Configure AD winsync 2. Update errorlog level of 389-ds config to 8192 nsslapd-errorlog-level: 8192 3. Modify winsync interval to 120 seconds 4. Observe the error logs for timestamp of "Running Dirsync" eg: tail -f /var/log/dirsrv/slapd-LAB-ENG-PNQ-REDHAT-COM/errors | grep "Running Dirsync" Actual results: Dirsync is initiated at default 300 seconds interval. The new interval doesn't take effect unless dirsrv is restarted. Expected results: winSyncInterval change should take effect immediately without restart. Additional info: Last night I had changed the interval to 600 seconds. Today I set it to 120 seconds and watched the logs to check when the interval change would take effect. After more than an hour I restarted only dirsrv this time. [root@wheeljack ~]# date; ldapmodify -x -D "cn=directory manager" -w wheeljack << EOF dn: cn=meTodhcp201-118.englab.pnq.redhat.com,cn=replica,cn=dc\3Dlab\2Cdc\3Deng\ 2Cdc\3Dpnq\2Cdc\3Dredhat\2Cdc\3Dcom,cn=mapping tree,cn=config changetype: modify replace: winSyncInterval winSyncInterval: 120 EOF Wed May 9 12:16:06 IST 2012 modifying entry "cn=meTodhcp201-118.englab.pnq.redhat.com,cn=replica,cn=dc\3Dla b\2Cdc\3Deng\2Cdc\3Dpnq\2Cdc\3Dredhat\2Cdc\3Dcom,cn=mapping tree,cn=config" [root@wheeljack ~]# date; service dirsrv restart Wed May 9 13:30:38 IST 2012 Shutting down dirsrv: LAB-ENG-PNQ-REDHAT-COM... [ OK ] PKI-IPA... [ OK ] Starting dirsrv: LAB-ENG-PNQ-REDHAT-COM... [ OK ] PKI-IPA... [ OK ] [root@wheeljack ~]# [root@wheeljack ~]# tail -f /var/log/dirsrv/slapd-LAB-ENG-PNQ-REDHAT-COM/errors | grep "Running Dirsync" [09/May/2012:12:10:24 +051800] NSMMReplicationPlugin - Running Dirsync [09/May/2012:12:20:24 +051800] NSMMReplicationPlugin - Running Dirsync [09/May/2012:12:30:24 +051800] NSMMReplicationPlugin - Running Dirsync [09/May/2012:12:40:24 +051800] NSMMReplicationPlugin - Running Dirsync [09/May/2012:12:50:24 +051800] NSMMReplicationPlugin - Running Dirsync [09/May/2012:13:00:24 +051800] NSMMReplicationPlugin - Running Dirsync [09/May/2012:13:10:24 +051800] NSMMReplicationPlugin - Running Dirsync [09/May/2012:13:20:24 +051800] NSMMReplicationPlugin - Running Dirsync [09/May/2012:13:30:24 +051800] NSMMReplicationPlugin - Running Dirsync >>[09/May/2012:13:30:44 +051800] NSMMReplicationPlugin - Running Dirsync [09/May/2012:13:32:44 +051800] NSMMReplicationPlugin - Running Dirsync [09/May/2012:13:34:44 +051800] NSMMReplicationPlugin - Running Dirsync [09/May/2012:13:36:44 +051800] NSMMReplicationPlugin - Running Dirsync [09/May/2012:13:38:44 +051800] NSMMReplicationPlugin - Running Dirsync
set default ticket origin to Community
Added initial screened field value.
Although we can change the config setting, we only read it in once in windows_inc_run().
windows_inc_protocol.c line 361: if (is_first_start) { unsigned long interval = windows_private_get_sync_interval(prp->agmt) * 1000; / * The function, the arguments, the time (hence) when it is first to be called, * and the repeat interval. / / DBDB: we should probably make this polling interval configurable / dirsync = slapi_eq_repeat(periodic_dirsync, (void*) prp, (time_t)0 , interval); is_first_start = PR_FALSE; } break;
The calls to change replication agreement settings all call prot_notify_agmt_changed() if the change was successful. This tells the incremental protocol loop in windows_inc_run() that the agreement has changed and the loop needs to go to the START state. I think for this fix all we need to do is to call prot_notify_agmt_changed() when the winsyncinterval is successfully set. Looking at the code, we don't call prot_notify_agmt_changed() for any of the windows sync settings. We probably should. The easiest way to do this would be to call prot_notify_agmt_changed() from windows_parse_config_entry() upon success. That would cover all of the windows sync attributes. The other change would be to remove the check for is_first_start in windows_inc_run(), and instead see if there is already a slapi_eq event set up for the interval. If so, cancel it, and create a new one.
Revised 0001-Ticket-393-Change-in-winSyncInterval-does-not-take-i.patch
git merge ticket393 Updating 2b98d67..8799a86 Fast-forward ldap/servers/plugins/replication/repl5.h | 2 + ldap/servers/plugins/replication/repl5_agmt.c | 10 ++++++++ .../plugins/replication/windows_inc_protocol.c | 23 +++++++++---------- ldap/servers/plugins/replication/windows_private.c | 10 +++++++- 4 files changed, 31 insertions(+), 14 deletions(-)
git push origin master Counting objects: 19, done. Delta compression using up to 4 threads. Compressing objects: 100% (10/10), done. Writing objects: 100% (10/10), 1.56 KiB, done. Total 10 (delta 8), reused 0 (delta 0) To ssh://git.fedorahosted.org/git/389/ds.git 2b98d67..8799a86 master -> master
Metadata Update from @mreynolds: - Issue assigned to mreynolds - Issue set to the milestone: 1.3.0.rc1
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/393
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: Fixed)
Login to comment on this ticket.