Bug 442618

Summary: expire_indirect: fstat failed: Bad file descriptor
Product: [Fedora] Fedora Reporter: Jeff Moyer <jmoyer>
Component: autofsAssignee: Ian Kent <ikent>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: 9CC: bugs+fedora, ikent, jmoyer, staubach
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-06-10 12:51:21 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 448038    
Attachments:
Description Flags
Patcg to check for nohide mounts none

Description Jeff Moyer 2008-04-15 20:10:47 UTC
Description of problem:
After some amount of time using /net for builds, the following shows up in the
log (after enabling debugging, because the mount points wouldn't expire):

Apr 15 15:29:12 xxxx automount[1932]: st_expire: state 1 path /net
Apr 15 15:29:12 xxxx automount[1932]: expire_proc: exp_proc =
3082759056 path /net
Apr 15 15:29:12 xxxx automount[1932]: expire_proc_indirect: expire
/net/yyyy/usr/src
Apr 15 15:29:12 xxxx automount[1932]: expire_indirect: fstat failed:
Bad file descriptor
Apr 15 15:29:12 xxxx automount[1932]: expire_proc_indirect: expire
/net/yyyy/usr/src
Apr 15 15:29:12 xxxx automount[1932]: expire_indirect: fstat failed:
Bad file descriptor
Apr 15 15:29:12 xxxx automount[1932]: expire_proc_indirect: expire
/net/yyyy
Apr 15 15:29:12 xxxx automount[1932]: 3 remaining in /net
Apr 15 15:29:12 xxxx automount[1932]: expire_cleanup: got thid
3082759056 path /net stat 4
Apr 15 15:29:12 xxxx automount[1932]: expire_cleanup: sigchld: exp
3082759056 finished, switching from 2 to 1

Version-Release number of selected component (if applicable):
Linux automount version 5.0.3-11

Directories:
       config dir:     /etc/sysconfig
       maps dir:       /etc
       modules dir:    /usr/lib/autofs

Compile options:
 DISABLE_MOUNT_LOCKING ENABLE_IGNORE_BUSY_MOUNTS WITH_HESIOD WITH_LDAP
 WITH_SASL

kernel 2.6.25-0.220

How reproducible:
Not sure.

Comment 1 Ian Kent 2008-04-16 06:21:47 UTC
I may be able to reproduce it given the export lists, as
long as there aren't too many servers.

Comment 2 Peter Staubach 2008-04-16 13:32:50 UTC
The exports on the server look like:

/               *(ro,sync,fsid=0)
/usr/src        *(rw,sync,nohide,no_root_squash)

I am working in a directory inside of that /usr/src file system.
(/ is exported so that I can get NFSv4 working in a similar
fashion to NFSv2 and NFSv3.  I am not using NFSv4 here though.)

Comment 3 Ian Kent 2008-04-19 04:05:19 UTC
Just to let you know, I haven't forgotten this.

The cause of the descriptor messages is due to autofs
interaction with the "nohide" option. I've been expecting
something like this for some time and have thought about
how to deal with it on and off for a while.

What happens is that, since this mount shows up in the exports
list autofs thinks it is something it needs to automount but
because it is a "nohide" export the NFS client also mounts it
transparently. This confuses autofs as it then thinks it needs
to umount it more than once.

I can't see any way to discover the export options in user
space on the client, any ideas?

Anyway, I'm giving it more serious thought now we have a
reported case.

Ian


Comment 4 Ian Kent 2008-05-12 07:03:00 UTC
Created attachment 305085 [details]
Patcg to check for nohide mounts

Comment 5 Ian Kent 2008-05-12 07:06:44 UTC
Could you please check this to see if the patch functions correctly.
The built packages are available at:
http://koji.fedoraproject.org/packages/autofs/5.0.3/14.

Comment 6 Peter Staubach 2008-05-12 22:31:38 UTC
I have installed the new rpm, but I am at Connectathon and it may take
me a few days to test.  I will update this bugzilla as soon as I have
some feedback.

Comment 7 Peter Staubach 2008-05-13 22:31:48 UTC
It seems to work for me.  I accessed the server mentioned in Comment #2.
It appears that autofs caused the / file system to be mounted, but then
the NFS client mounted the /usr/src file system.  It all umounted
cleanly as far as I could tell.

Comment 8 Peter Staubach 2008-05-13 22:35:19 UTC
One other thing, the "nohide" export option is a Linux thing.  Other
systems, such as Solaris, can export the hierarchy described in
Comment #2, without any special export options.

My suggestion is to avoid the mention of the "nohide" export option
because it is server specific.

Comment 9 Ian Kent 2008-05-14 01:57:25 UTC
(In reply to comment #8)
> One other thing, the "nohide" export option is a Linux thing.  Other
> systems, such as Solaris, can export the hierarchy described in
> Comment #2, without any special export options.
> 
> My suggestion is to avoid the mention of the "nohide" export option
> because it is server specific.

OK, I'll alter the description and internal comments and then
commit it upstream and push updates out.

Heads up, we've had another issue reported in Rawhide which
results in these messages and has similar symptoms. It appears
to be gvfsd that is the causing it but there must be a case
where the mount control file descriptor is incorrectly being
closed. Anyway I'm working on it.

Thanks.

Comment 10 Bug Zapper 2008-05-14 09:30:10 UTC
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 11 Bug Zapper 2009-06-10 00:12:37 UTC
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 12 Ian Kent 2009-06-10 12:51:21 UTC
This has been fixed some time ago.