Description of problem: After remove brick commit it should stop the gsyncd running on the removed node. In geo-rep, there will one monitor process per node and one worker process per brick. After remove brick, the worker process corresponding to removed brick should be stopped Version-Release number of selected component (if applicable):glusterfs-3.4.0.39rhs-1 How reproducible:Happens everytime Steps to Reproduce: 1.create and start a geo-rep relationship between master and slave 2.add a new node to the cluser and add brick to the volume. 3.do gsec_create, create push-pem force and start force. 4. remove the added brick. Actual results: geo-rep fails to stop the worker process corresponding to removed brick Expected results: It should stop the gsyncd process, other wise it becomes stale process and it might introduce new problems. Additional info:
Verified with build: glusterfs-3.7.1-1.el6rhs.x86_64 As mentioned in the comment 3, the geo-rep session should be stopped before commit which is documented in the guide as well. Doing so, will kill all the gsyncd process and hence wont hit the bug mentioned in the description. Verified the documented steps and no gsyncd process was running on the removed node. Moving the bug to verified state.
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. https://rhn.redhat.com/errata/RHSA-2015-1495.html