Bug 1255582 - Add the ability to force an unconditional graph reload
Summary: Add the ability to force an unconditional graph reload
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: GlusterFS
Classification: Community
Component: core
Version: mainline
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: bugs@gluster.org
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-08-21 03:09 UTC by Joe Julian
Modified: 2019-05-07 21:23 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-05-07 21:23:04 UTC
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Embargoed:


Attachments (Terms of Use)

Description Joe Julian 2015-08-21 03:09:21 UTC
On the rare occasion something is wrong, like the client will not reconnect to a brick, I've been able to work around it by changing a volume setting that affects the client. This causes the client to reload the vol file and return to sanity.

A kill -HUP does not do this as the client recognizes that the vol file hasn't changed and refuses to reload.

Adding the ability to force a reload may be beneficial perhaps a SIGUSR2?

I wouldn't rely on the glusterd connection and, in fact, the signal should force that reconnection as well.

Comment 1 Amar Tumballi 2019-05-07 21:23:04 UTC
Joe, while this RFE makes sense when there are those rare issues, considering we have the work around to force a re-load by changing an option (like you mentioned above), we are deprioritizing this feature request (well, I understand this is sitting here without an update for last 4yrs). We will mark this as WONTFIX for now. Please feel free to reopen, if you find it critical.

For those who are reading this bug, to achieve the same, do a change in volfile (or gluster volume set $volname some-option some-value), and that should take care of the issue.


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