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.
I may be able to reproduce it given the export lists, as long as there aren't too many servers.
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.)
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
Created attachment 305085 [details] Patcg to check for nohide mounts
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.
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.
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.
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.
(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.
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 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
This has been fixed some time ago.