This service will be undergoing maintenance at 20:00 UTC, 2017-04-03. It is expected to last about 30 minutes
Bug 117591 - Autofs/automount do no umount shares
Autofs/automount do no umount shares
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: autofs (Show other bugs)
1
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jeffrey Moyer
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-03-05 12:02 EST by John Stokes
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-04-13 12:26:32 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description John Stokes 2004-03-05 12:02:34 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/&
Comment 1 Jeffrey Moyer 2004-03-19 18:36:34 EST
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).
Comment 2 John Stokes 2004-03-25 15:38:30 EST
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?
Comment 3 Jeffrey Moyer 2004-03-25 15:58:22 EST
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.

Comment 4 John Stokes 2004-03-25 16:17:16 EST
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?
Comment 5 Jeffrey Moyer 2004-11-01 17:09:03 EST
Try running lsof for the mount points.  I'm curious to see what application(s)
have references to the directories.
Comment 6 Jeffrey Moyer 2005-04-11 16:02:39 EDT
Are you still experiencing this problem?
Comment 7 John Stokes 2005-04-13 12:24:45 EDT
(In reply to comment #6)
> Are you still experiencing this problem?

We have since migrated to FC3 which no longer has this problem.

Comment 8 Jeffrey Moyer 2005-04-13 12:26:32 EDT
Thank you for the update.

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