Description of problem: glusterd sequence of initialisation operations can lead to use of glusterd_[friend/op]_sm before their respective initialisations. One possible sequence of operations that can result in a crash is as follows, - glusterd attempts to restore all the peers. - One of the peer's ip/hostname is unreachable. - glusterd receives a disconnect from that peer before restore phase is complete. This can result in 'moving' of the friend_sm. But friend_sm initialisation is yet to happen. Version-Release number of selected component (if applicable): master, release-3.2 (corresponding git branches that are affected) How reproducible: Inconsistent. It depends on how soon the non-blocking socket returns with an unreachable/unresolvable hostname/ip of peer. Steps to Reproduce: 1. Create a trusted pool with more than one peers. 2. One of the peers' hostname/ip must be unreachable/unresolvable. 3. Actual results: glusterd should not crash. Expected results: glusterd crashes. Additional info:
*** Bug 787516 has been marked as a duplicate of this bug. ***
CHANGE: http://review.gluster.com/2725 (glusterd: Initialised op_sm/friend_sm before cluster restore.) merged in master by Vijay Bellur (vijay)