+++ This bug was initially created as a clone of Bug #1282915 +++ +++ +++ +++ use this bug to post a fix for the release-3.7 branch. +++ Description of problem: Gluster does not reload gracefully upon server restart Version-Release number of selected component (if applicable): 3.2+ How reproducible: Steps to Reproduce: 1. Install GlusterFS as per docs on Centos7. 2. Create and start volume. 3. Restart server. Actual results: rpcbind service will not be active. Expected results: gluster will have registered with rpcbind Additional info: /usr/lib/systemd/system/glusterd.service has the following: "[Unit] Description=GlusterFS, a clustered file-system server After=network.target rpcbind.service Before=network-online.target" Changing to: [Unit] Description=GlusterFS, a clustered file-system server Requires=rpcbind.service After=network.target Before=network-online.target Corrects the issue. --- Additional comment from Red Hat Bugzilla Rules Engine on 2015-11-17 20:29:40 CET --- This bug is automatically being proposed for the current z-stream release of Red Hat Gluster Storage 3 by setting the release flag 'rhgs‑3.1.z' to '?'. If this bug should be proposed for a different release, please manually change the proposed release flag. --- Additional comment from Kaushal on 2015-11-18 06:55:39 CET --- Thanks for reporting this. Turns out we've misunderstood the meaning of the `After` option. According to the systemd.unit(5) man page, the `After` option only sets up ordering. If unit foo.service has the option `After=bar.service`, the option only ensures that if both foo and bar are started together, foo is started after bar. It doesn't ensure that starting only foo starts bar. The `Requires` option only sets up the requirement, but doesn't set up ordering. If foo.service `Requires` bar.service, it is only guaranteed that starting foo will also start bar, but not necessarily in order. The man page suggests that if a unit requires that another unit be started before itself, then both `After` and `Requires` must be used. I've submitted a change for review that fixes this at http://review.gluster.org/12605 --- Additional comment from Vijay Bellur on 2015-11-18 11:21:10 CET --- COMMIT: http://review.gluster.org/12605 committed in master by Atin Mukherjee (amukherj) ------ commit 23440a73bc348bbc3bb43ec397f0639ee45865fc Author: Kaushal M <kaushal> Date: Wed Nov 18 11:21:13 2015 +0530 glusterd.service: Ensure rpcbind is started before glusterd Having the rpcbind.service under the `After` option only ensures that glusterd.service is started after rpcbind.service if both are enabled/started at the same time. It doesn't ensure that starting glusterd.service will start rpcbind.service. The systemd.unit(5) man page suggests to use both the `Requires` and `After` options to ensure that rpcbind is started before glusterd, whenever glusterd is started. BUG: 1282915 Change-Id: Iee69965486be08711299aba235f7b00c3e2fe7e9 Signed-off-by: Kaushal M <kaushal> Reviewed-on: http://review.gluster.org/12605 Reviewed-by: Atin Mukherjee <amukherj> Reviewed-by: Anand Nekkunti <anekkunt> Tested-by: Gluster Build System <jenkins.com> Tested-by: NetBSD Build System <jenkins.org>
REVIEW: http://review.gluster.org/12640 (glusterd.service: Ensure rpcbind is started before glusterd) posted (#1) for review on release-3.7 by Niels de Vos (ndevos)
COMMIT: http://review.gluster.org/12640 committed in release-3.7 by Atin Mukherjee (amukherj) ------ commit 4a7d83d53a5698839d605ac4b3d4a9468ca64dd4 Author: Niels de Vos <ndevos> Date: Wed Nov 18 12:24:07 2015 +0100 glusterd.service: Ensure rpcbind is started before glusterd Having the rpcbind.service under the `After` option only ensures that glusterd.service is started after rpcbind.service if both are enabled/started at the same time. It doesn't ensure that starting glusterd.service will start rpcbind.service. The systemd.unit(5) man page suggests to use both the `Requires` and `After` options to ensure that rpcbind is started before glusterd, whenever glusterd is started. Cherry picked from commit 23440a73bc348bbc3bb43ec397f0639ee45865fc: > BUG: 1282915 > Change-Id: Iee69965486be08711299aba235f7b00c3e2fe7e9 > Signed-off-by: Kaushal M <kaushal> > Reviewed-on: http://review.gluster.org/12605 > Reviewed-by: Atin Mukherjee <amukherj> > Reviewed-by: Anand Nekkunti <anekkunt> > Tested-by: Gluster Build System <jenkins.com> > Tested-by: NetBSD Build System <jenkins.org> Change-Id: Iee69965486be08711299aba235f7b00c3e2fe7e9 BUG: 1283142 Signed-off-by: Niels de Vos <ndevos> Reviewed-on: http://review.gluster.org/12640 Tested-by: NetBSD Build System <jenkins.org> Tested-by: Gluster Build System <jenkins.com> Reviewed-by: Atin Mukherjee <amukherj>
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.7.7, please open a new bug report. glusterfs-3.7.7 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://www.gluster.org/pipermail/gluster-users/2016-February/025292.html [2] http://thread.gmane.org/gmane.comp.file-systems.gluster.user