Bug 194069 - autofs does not expire top-level server directories
autofs does not expire top-level server directories
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: autofs (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Ian Kent
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-06-05 12:29 EDT by Michal Jaegermann
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-06-15 20:08:22 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)
a log fragmet showing the issue (1.40 KB, text/plain)
2006-06-05 12:29 EDT, Michal Jaegermann
no flags Details
debug log from automount showing details of the problem (29.83 KB, text/plain)
2006-06-06 15:29 EDT, Michal Jaegermann
no flags Details

  None (edit)
Description Michal Jaegermann 2006-06-05 12:29:45 EDT
Description of problem:

With NFS server exporting a hierarchy of filesystems and autofs which
is supposed to expire mounts a lower level mounts do expire but the
top one looks like stuck.  Only restarting autofs makes automount to
release such entry.

Attached is piece of log from a run with 'automount -v -d'.  It
is already about twenty five minutes after the last log entry and
'/net/zeno' mount still did not expire.

Version-Release number of selected component (if applicable):
autofs-5.0.0_beta4-1 and kernel-2.6.16-1.2245_FC6

How reproducible:
always
Comment 1 Michal Jaegermann 2006-06-05 12:29:45 EDT
Created attachment 130516 [details]
a log fragmet showing the issue
Comment 2 Ian Kent 2006-06-05 20:58:35 EDT
(In reply to comment #1)
> Created an attachment (id=130516) [edit]
> a log fragmet showing the issue
> 

This looks like a different problem to what we've seen so far.
There's an update making it's way to the mirrors, autofs-5.0.0_beta4-3.
Please try and duplicate this with that version.

Don't forget to send the denug output somewhere so we can get more
info about what's happening.

With something like this in syslog.conf.

daemon.*			/var/log/debug

Ian
 
Comment 3 Ian Kent 2006-06-05 23:47:55 EDT
(In reply to comment #0)
> Description of problem:
> 
> With NFS server exporting a hierarchy of filesystems and autofs which
> is supposed to expire mounts a lower level mounts do expire but the
> top one looks like stuck.  Only restarting autofs makes automount to
> release such entry.

Excellent. Good work.

I've been able to reproduce this.
It appears this happens at the top level when the export tree is
one level deep. I the top exports have more than one directory
level it appears not to happen. Oddly enough my testing has been
with exports like /usr/local/* which obviously has two levles.

Ha.
Ian


> 
> Attached is piece of log from a run with 'automount -v -d'.  It
> is already about twenty five minutes after the last log entry and
> '/net/zeno' mount still did not expire.
> 
> Version-Release number of selected component (if applicable):
> autofs-5.0.0_beta4-1 and kernel-2.6.16-1.2245_FC6
> 
> How reproducible:
> always

Comment 4 Michal Jaegermann 2006-06-06 15:29:29 EDT
Created attachment 130633 [details]
debug log from automount showing details of the problem

re comment #2:

Yes, the same thing happens with autofs-5.0.0_beta4-3.	Stopping autofs
shows in logs for a mount point which is refusing to expire:

automount[4251]: umounted /net/zeno/boot
automount[4251]: umounted /net/zeno/home
automount[4251]: umounted /net/zeno/opt
automount[4251]: umounted /net/zeno/usr
automount[4251]: umounted /net/zeno/var
automount[4251]: umounted /net

while nothing but /net/zeno was really mounted at that moment.
Apparently mount triggers, whatever they are, make this directory
busy.

Attached is a debug log (around 30 K) from an automount run.
It looks that automount goes into a loop, with a period of 15 seconds,
for that last remaining mountpoint.  It gets broken only
at 13:17:46 when autofs is stopped.
Comment 5 Ian Kent 2006-06-06 21:06:45 EDT
(In reply to comment #4)
> Created an attachment (id=130633) [edit]
> debug log from automount showing details of the problem
> 
> re comment #2:
> 
> Yes, the same thing happens with autofs-5.0.0_beta4-3.	Stopping autofs
> shows in logs for a mount point which is refusing to expire:
> 
> automount[4251]: umounted /net/zeno/boot
> automount[4251]: umounted /net/zeno/home
> automount[4251]: umounted /net/zeno/opt
> automount[4251]: umounted /net/zeno/usr
> automount[4251]: umounted /net/zeno/var
> automount[4251]: umounted /net
> 
> while nothing but /net/zeno was really mounted at that moment.
> Apparently mount triggers, whatever they are, make this directory
> busy.

I've found several mistakes during testing which I'm fixing.
I'm likely to be finished today.

I'll push an update out before I start working on the "reload"
issue.

Ian
Comment 6 Michal Jaegermann 2006-06-08 16:03:23 EDT
With the latest version of autofs (autofs-5.0.0_beta4-4 + "out-of-band"
extra patch) I see now in logs

automount[10469]: expiring path /net/zeno
automount[10469]: umounted offset /net/zeno/boot
automount[10469]: umounted offset /net/zeno/home
automount[10469]: umounted offset /net/zeno/opt
automount[10469]: umounted offset /net/zeno/usr
automount[10469]: umounted offset /net/zeno/var
automount[10469]: expired /net/zeno

and all mount points expected to expire indeed do that.

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