Description of problem: when setting transport.socket.bind-address it is ignored except for actually binding the glusterd daemon. Basically NFS, SHD and everything else tries to connect to 127.0.0.1:24007 instead of the actual address bound. This means FUSE is the only option for connects and of course the volume get corrupted shortly after. Look in xlators/mgmt/glusterd/src/glusterd-utils.c:glusterd_nodesvc_start() for possible fix. ie: glusterd_nodesvc_start() calls runner_add_args( ... , "-s", "localhost", ...) above provided by ndevos in IRC Version-Release number of selected component (if applicable): 3.5.2 How reproducible: set transport.socket.bind-address option and restart. viola! Steps to Reproduce: 1. set transport.socket.bind-address option 2. restart glusterfs-server 3. Actual results: no NFS, no SHD and anything else that attempts to connect to 127.0.0.1:24007 Expected results: it should work Additional info:
forgot to add: in the "volume management" section of glusterd.vol is where you can set this "option transport.socket.bind-address 123.123.123.123"
Backport guidelines: - http://www.gluster.org/community/documentation/index.php/Backport_Guidelines Patches that need backporting to 3.5: 1. http://review.gluster.org/8908 2. http://review.gluster.org/8910
REVIEW: http://review.gluster.org/8952 (glusterd: pass the bind-address to starting services) posted (#1) for review on release-3.5 by Niels de Vos (ndevos)
REVIEW: http://review.gluster.org/8953 (glusterd: make bricks respect 'transport.socket.bind-address') posted (#1) for review on release-3.5 by Niels de Vos (ndevos)
COMMIT: http://review.gluster.org/8953 committed in release-3.5 by Niels de Vos (ndevos) ------ commit 6b6ee3bce4b2fcb2cbfd06ab0a199d7aac4b7cec Author: Niels de Vos <ndevos> Date: Tue Oct 21 09:38:09 2014 +0200 glusterd: make bricks respect 'transport.socket.bind-address' When GlusterD starts the brick processes, these will listen on all interfaces. When the 'transport.socket.bind-address' option is set in glusterd.vol, the brick processes should only listen on the specified hostname or IP-address. Cherry picked from commit 430b874c4f1a171c106a9e1e6507e14e79805a1d: > Change-Id: I8e7d1f294904081137c23f3446261329d0d13bba > BUG: 1149863 > Signed-off-by: Niels de Vos <ndevos> > Reviewed-on: http://review.gluster.org/8910 > Tested-by: Gluster Build System <jenkins.com> > Reviewed-by: Krishnan Parthasarathi <kparthas> > Tested-by: Krishnan Parthasarathi <kparthas> Change-Id: I8e7d1f294904081137c23f3446261329d0d13bba BUG: 1149857 Signed-off-by: Niels de Vos <ndevos> Reviewed-on: http://review.gluster.org/8953 Tested-by: Gluster Build System <jenkins.com>
COMMIT: http://review.gluster.org/8952 committed in release-3.5 by Niels de Vos (ndevos) ------ commit 4f58e62ce5787303ced4e11ba15d5ce8f07c379f Author: Niels de Vos <ndevos> Date: Tue Oct 21 09:20:31 2014 +0200 glusterd: pass the bind-address to starting services When the transport.socket.bind-address option is set to a hostname or ip-address, the services started by GlusterD fail to connect to the management daemon. GlusterD always forces the services to connect to the "localhost" hostname, even if it is not listening on that address. GlusterD should take the transport.socket.bind-address option into consideration, and pass that to the glusterfs-clients with the -s or --volfile commandline parameter. Note that this is not a change that removes all hard-coded dependencies on "localhost". This change merely makes it possible to start required services when the transport.socket.bind-address option is set. Cherry picked from commit 283fa797f4bf98130b42c36972305b8cb6e5aaaf: > Change-Id: I36a0ed6c69342e6327adc258fea023929055d7f2 > BUG: 1149863 > Signed-off-by: Niels de Vos <ndevos> > Reviewed-on: http://review.gluster.org/8908 > Tested-by: Gluster Build System <jenkins.com> > Reviewed-by: Jeff Darcy <jdarcy> > Reviewed-by: Krishnan Parthasarathi <kparthas> > Tested-by: Krishnan Parthasarathi <kparthas> Change-Id: I36a0ed6c69342e6327adc258fea023929055d7f2 BUG: 1149857 Signed-off-by: Niels de Vos <ndevos> Reviewed-on: http://review.gluster.org/8952 Tested-by: Gluster Build System <jenkins.com>
The second Beta for GlusterFS 3.5.3 has been released [1]. Please verify if the release solves this bug report for you. In case the glusterfs-3.5.3beta2 release does not have a resolution for this issue, leave a comment in this bug and move the status to ASSIGNED. If this release fixes the problem for you, leave a note and change the status to VERIFIED. Packages for several distributions have been made available on [2] to make testing easier. [1] http://supercolony.gluster.org/pipermail/gluster-users/2014-November/019359.html [2] http://download.gluster.org/pub/gluster/glusterfs/qa-releases/3.5.3beta2/
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-3.5.3, please reopen this bug report. glusterfs-3.5.3 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] http://supercolony.gluster.org/pipermail/announce/2014-November/000042.html [2] http://supercolony.gluster.org/pipermail/gluster-users/