Bug 1073188 - SIGHUP doesn't do anything for 'glusterfs' client processes anymore.
Summary: SIGHUP doesn't do anything for 'glusterfs' client processes anymore.
Keywords:
Status: CLOSED EOL
Alias: None
Product: GlusterFS
Classification: Community
Component: unclassified
Version: 3.4.2
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: bugs@gluster.org
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-03-06 01:22 UTC by Jeff Byers
Modified: 2015-10-07 13:50 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-10-07 13:49:43 UTC
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:


Attachments (Terms of Use)

Description Jeff Byers 2014-03-06 01:22:44 UTC
SIGHUP doesn't do anything for 'glusterfs' client processes
anymore.

In GlusterFS 3.2.7, sending a SIGHUP signal to 'glusterfs'
client process would cause it to reincarnate(), which caused
the client process reread the volume spec file. This was
obvious by observing its log file.

Using SIGHUP was useful when the GlusterFS distribute volume
was expanded in size, as without the SIGHUP, the client
would not see the new size.

In GlusterFS 3.4.2, the SIGHUP to the 'glusterfs' client
process appears to do nothing at all, although the call to
reincarnate() is still there, and the signal does not appear
to be blocked.

So in GlusterFS 3.4.2, then the volume is changed in shape
or size, the 'glusterfs' FUSE mount must be unmounted, which
requires the applications using the mount to be stopped as
well -- kind of disruptive.

I hoped that the unmount might be avoided with the "mount -o
remount" option, but apparently FUSE mounts to not support
the 'remount' option at all.

It would be useful if the old 3.2.7 SIGHUP behaviour could
be returned, or better, if the client 'glusterfs' process
would learn of the new volume shape/size through
communications with the 'glusterfsd' process without
requiring any user manual actions at all.

Comment 1 Niels de Vos 2015-05-17 21:57:39 UTC
GlusterFS 3.7.0 has been released (http://www.gluster.org/pipermail/gluster-users/2015-May/021901.html), and the Gluster project maintains N-2 supported releases. The last two releases before 3.7 are still maintained, at the moment these are 3.6 and 3.5.

This bug has been filed against the 3,4 release, and will not get fixed in a 3.4 version any more. Please verify if newer versions are affected with the reported problem. If that is the case, update the bug with a note, and update the version if you can. In case updating the version is not possible, leave a comment in this bug report with the version you tested, and set the "Need additional information the selected bugs from" below the comment box to "bugs@gluster.org".

If there is no response by the end of the month, this bug will get automatically closed.

Comment 2 Kaleb KEITHLEY 2015-10-07 13:49:43 UTC
GlusterFS 3.4.x has reached end-of-life.

If this bug still exists in a later release please reopen this and change the version or open a new bug.

Comment 3 Kaleb KEITHLEY 2015-10-07 13:50:53 UTC
GlusterFS 3.4.x has reached end-of-life.\                                                   \                                                                               If this bug still exists in a later release please reopen this and change the version or open a new bug.


Note You need to log in before you can comment on or make changes to this bug.