Description of problem: In the current implementation, glusterd will choose a free port and pass that to brick which need to bind on it, if you observe carefully there is window open for race here. In case, if the passed port was consumed by some other processes then brick will fail to bind. In the recent past we have addressed this issue by returning EADDRINUSE from brick to glusterd after which glusterd will allocate a port from refreshed free ports list, but I feel that's kind of too much of automation and also a hacky way. Version-Release number of selected component (if applicable): mainline
REVIEW: http://review.gluster.org/14670 (port-map: let brick choose its own port) posted (#1) for review on master by Prasanna Kumar Kalever (pkalever)
REVIEW: http://review.gluster.org/14670 (port-map: let brick choose its own port) posted (#2) for review on master by Prasanna Kumar Kalever (pkalever)
REVIEW: http://review.gluster.org/14670 (port-map: let brick choose its own port) posted (#3) for review on master by Prasanna Kumar Kalever (pkalever)
REVIEW: http://review.gluster.org/14670 (port-map: let brick choose its own port) posted (#4) for review on master by Prasanna Kumar Kalever (pkalever)
REVIEW: http://review.gluster.org/14670 (port-map: let brick choose its own port) posted (#5) for review on master by Prasanna Kumar Kalever (pkalever)
REVIEW: http://review.gluster.org/14670 (port-map: let brick choose its own port) posted (#6) for review on master by Prasanna Kumar Kalever (pkalever)
REVIEW: https://review.gluster.org/14670 (port-map: let brick choose its own port) posted (#7) for review on master by Amar Tumballi
REVIEW: https://review.gluster.org/21249 (rpc: make binding to port 0 as the default if no option is provided) posted (#1) for review on master by Amar Tumballi
COMMIT: https://review.gluster.org/21249 committed in master by "Raghavendra G" <rgowdapp> with a commit message- rpc: make binding to port 0 as the default if no option is provided Right now, if no option is provided, the default port is assumed, which is 24007. Ideally, for 'glusterfsd' processes, it is better to not assume there are any ports given, so it can start listening on any port which is available. This helps us to cleanup the dependencies on glusterd from glusterfsd at the moment. No changes would be done to glusterd code, but making the right defaults helps to make glusterfsd more independent process later. NOTE: This patch is a reduced version of below set of patches: * https://review.gluster.org/14613/ & * https://review.gluster.org/14670/ & * https://review.gluster.org/14671/ Credits: Prasanna Kumar Kalever <pkalever> updates: bz#1343926 Change-Id: Ib874e10505e7366dc56ba754458252b67052e653 Signed-off-by: Amar Tumballi <amarts>
This bug is getting closed because a release has been made available that should address the reported issue. In case the problem is still not fixed with glusterfs-6.0, please open a new bug report. glusterfs-6.0 has been announced on the Gluster mailinglists [1], packages for several distributions should become available in the near future. Keep an eye on the Gluster Users mailinglist [2] and the update infrastructure for your distribution. [1] https://lists.gluster.org/pipermail/announce/2019-March/000120.html [2] https://www.gluster.org/pipermail/gluster-users/