Description of problem: If the geo-rep config special-sync-mode is set to wrong value, it takes it successfully and makes the geo-rep status to faulty. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [root@shaktiman ~]# gluster v geo master 10.70.43.23::imaster config special-sync-mode sDGs geo-replication config updated successfully >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Version-Release number of selected component (if applicable):glusterfs-3.4.0.20rhs-1.el6rhs.x86_64 How reproducible:happens every time Steps to Reproduce: 1.Create and start a geo-rep relationship between master and slave. 2.set the config special-sync-mode to some random value 3.check the geo-rep status Actual results: special-sync-mode succeeds for the wrong value and makes the geo-rep status faulty Expected results: First of all it should proper error message, and also it should never take the status to faulty. Additional info:
Avra/Venky, We need a fix to handle this option more carefully, and notify user that its not valid. At least 'gsyncd' process should not get into the recursive failure mode. Lets try to get it addressed early.
This happens as the config value is used to instantiate a class that has the config string as the class name. Checking this string for validity in gsyncd (worker) might be too late as monitor tracks the state of the worker process which in this case errors out due to an invalid class name.
https://code.engineering.redhat.com/gerrit/#/c/11610/
verified on glusterfs-3.4.0.22rhs-2.el6rhs.x86_64
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2013-1262.html