Bug 1151696 - mount.glusterfs fails due to race condition in `stat` call
Summary: mount.glusterfs fails due to race condition in `stat` call
Keywords:
Status: CLOSED EOL
Alias: None
Product: GlusterFS
Classification: Community
Component: fuse
Version: 3.5.2
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: ---
Assignee: bugs@gluster.org
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-10-11 04:23 UTC by John Hopkins
Modified: 2016-06-17 15:57 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-06-17 15:57:32 UTC
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Embargoed:


Attachments (Terms of Use)
This patch resolved the issue for me (613 bytes, text/plain)
2014-10-11 04:23 UTC, John Hopkins
no flags Details

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.


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