+++ This bug was initially created as a clone of Bug #442618 +++ 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. -- Additional comment from ikent on 2008-04-16 02:21 EST -- I may be able to reproduce it given the export lists, as long as there aren't too many servers. -- Additional comment from staubach on 2008-04-16 09:32 EST -- 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.) -- Additional comment from ikent on 2008-04-19 00:05 EST -- 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 -- Additional comment from ikent on 2008-05-12 03:03 EST -- Created an attachment (id=305085) Patcg to check for nohide mounts -- Additional comment from ikent on 2008-05-12 03:06 EST -- 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. -- Additional comment from staubach on 2008-05-12 18:31 EST -- 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. -- Additional comment from staubach on 2008-05-13 18:31 EST -- 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. -- Additional comment from staubach on 2008-05-13 18:35 EST -- 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. -- Additional comment from ikent on 2008-05-13 21:57 EST -- (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. -- Additional comment from fedora-triage-list on 2008-05-14 05:30 EST -- 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
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2009-0178.html