Bug 1255582

Summary: Add the ability to force an unconditional graph reload
Product: [Community] GlusterFS Reporter: Joe Julian <joe>
Component: coreAssignee: bugs <bugs>
Status: CLOSED WONTFIX QA Contact:
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: mainlineCC: atumball, bugs, pkarampu, rgowdapp, skoduri, smohan, vbellur
Target Milestone: ---Keywords: RFE, Triaged
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-05-07 21:23:04 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

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.