Red Hat Bugzilla – Bug 117591
Autofs/automount do no umount shares
Last modified: 2007-11-30 17:10:37 EST
Description of problem: We have about a dozen nfs shares that have been used through autofs since prior releases to RH6.2. In FC1 we have noticed a behavior that we have not seen before. Upon logon through the GUI (after the GDM and into the gnome login) every nfs share gets mounted. This would a non issue if the shares would timeout after being idle, but they don't. I have tried adding '--timeout 5' within the /etc/init.d/autofs script for daemonoptions with no positive outcome. Version-Release number of selected component (if applicable): *FC1 w/ stock SMP kernel; FC1 w/ stock kernel; FC1 with vanilla 2.4.25 kernel (which thus far has stopped my crashing related to nfs/fs) *autofs stock How reproducible: Steps to Reproduce: 1. Use autofs for nfs crossmounts 2. Login via X GDM into gnome 3. do a `df` to see what is mounted Actual results: Every crossmount mounts and never umounts through an idle timout Expected results: Only the users crossmount will be mounted Additional info: Example of /etc/auto_home which is pointed to by /etc/auto.master * home:/export/home/&
This sounds like it is an application issue. Are you running Nautilus, per chance? Here is an excerpt from a discussion on the autofs list: > I've been struggling to figure out why autofs does not appear > to unmount many mount points. I have more than 150 entries in > a map file and most of these entries get mounted when I log into > a Gnome session and never seem to ever get unmounted. This > happened under RedHat 8.0 (autofs-3.1.7-33) and still happens on > SuSE 9.0 (autofs-3.1.7-717). I'm guessing that Nautilus is doing > this. Is anyone else seeing this? Any suggestions on how to prevent > or debug this? I can provide more details if anyone is interested. The problem is that Nautilus scans the directory if/when it notices umount activity. This causes a remount. I couldn't find a way to trun it off. The list of directories to scan is help in a file (I can't remember where now) and I was able to stop it, to some extent, by cleaning it out and changing the modes on the file (for non-root login anyway).
We most likely are running nautilus. In the past we have had some issues with nautilus and nfs mounts, but we have seen them dwindle away since RH7.3 and use of NFS over TCP. First of all, I am not exactly sure how to turn off nautilus. Second, it seems that excessive mounting and umounting from an appliction, such as nautilus, should not undermine the stability of FC1 which has brought the machine down within a few days of using NFS crossmounts which is the behavior we have seen with all of our FC1 NFS clients. Ideas?
What do you mean it has "brought the machine down"? Did the kernel crash? Does the system hang? Nautilus doesn't explicitly mount/umount. When autofs umount's the directory, nautilus stats the directory, causing autof to remount. Thus, setting your --timeout=5 is probably only making the problem worse. I would set it higher, rather than lower until we can figure out exactly how best to address the issue. Just to be sure, are you running autofs-3.1.7-42? Note that there were no code changes between 3.1.7-36 (which was the RHL 8 and 9 version) and 3.1.7-42.
I am running the current version of autofs. My issues arise out of something similar to the recent Dual Xeon/Dual Athlon/SMP crashing issues, but we have only experienced these crashes when using autofs (hence the thread of autofs). Our other FC1 machines that have identical hardware are rock solid and have never crashed since their inception. This leaves me with thinking that the issue is autofs or the kernel or the interaction between both. Brought to light that there has been no change in autofs between RH8.0-9 to FC1. I am led to believe it is the kernel or the interaction between both. Manual umounts fail and stopping autofs hangs the machine (in a way that it still can be pinged, but it is hard locked via the network and console) ( please see bug # 116036 ) I set --timeout=5 to be sure that the timeout was set, the number is not important, it is just convenently short so I can see the outcome in a reasonable amount of time. Ideas? Suggestions?
Try running lsof for the mount points. I'm curious to see what application(s) have references to the directories.
Are you still experiencing this problem?
(In reply to comment #6) > Are you still experiencing this problem? We have since migrated to FC3 which no longer has this problem.
Thank you for the update.