Bug 1151696

Summary: mount.glusterfs fails due to race condition in `stat` call
Product: [Community] GlusterFS Reporter: John Hopkins <johnnycobol>
Component: fuseAssignee: bugs <bugs>
Status: CLOSED EOL QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 3.5.2CC: bartlomiej+redhat, bugs, james, ndevos, nicolas, rdmitterer
Target Milestone: ---Keywords: Triaged
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-06-17 15:57:32 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:
Attachments:
Description Flags
This patch resolved the issue for me none

Description John Hopkins 2014-10-11 04:23:15 UTC
Created attachment 945895 [details]
This patch resolved the issue for me

Description of problem:

When mounting a Gluster volume using mount.glusterfs, I consistently received the error "Mount failed. Please check the log file for more details."

After some investigation, I found that the `stat` call (which is made right after the mount) fails.

Version-Release number of selected component (if applicable):


How reproducible:

Consistently.


Steps to Reproduce:
1. Using glusterfs 3.5.2, create a 6-node, 6-brick replica 2 gluster volume.  The nodes should be running Oracle Linux 6.5 x86_64.
2. Start the volume and attempt to mount it using mount.glusterfs.

Actual results:

"Mount failed. Please check the log file for more details."

Expected results:

The mount should have succeeded.

Additional info:

Inserting a 0.1 second sleep between the mount and the stat call resolved the issue for me.  The patch is attached to this bug entry.

Comment 1 Niels de Vos 2014-10-28 12:54:59 UTC
This seems to be some race in the fuse client. The 'sleep .1' might work for you, but we can not assume it works (or is needed) everywhere.

We'll need to investigate a little more on why the stat() fails.

Comment 2 guzik 2015-01-28 06:31:09 UTC
I've got the same problem
http://www.gluster.org/pipermail/gluster-users/2015-January/020216.html

Comment 3 Rick Mitterer 2016-01-22 23:59:32 UTC
I'm having this issue with clients on RHEL 6.5 ... the .1 second delay worked for me. I have other clients running RHEL 6.7 that seem to work fine.

R

Comment 4 Niels de Vos 2016-06-17 15:57:32 UTC
This bug is getting closed because the 3.5 is marked End-Of-Life. There will be no further updates to this version. Please open a new bug against a version that still receives bugfixes if you are still facing this issue in a more current release.