Bug 194069

Created attachment 130516 [details]
a log fragmet showing the issue

(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
 

(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

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.

(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

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.