Bug 193832 - New autofs failes to remount /net maps after expiry
New autofs failes to remount /net maps after expiry
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-01 18:10 EDT by Stephen Tweedie
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:27:43 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 Stephen Tweedie 2006-06-01 18:10:09 EDT
Description of problem:
After upgrading a working rawhide to autofs-5.0.0-beta, /net now fails to
remount subdirectories if the mount times out and expires, as near as I can make
out.

I'm using a standard /etc/auto.net, and accessing it via

    /net/$host/disk/new

where $host is a short hostname listed in the NIS hosts map.

Immediately after restarting autofs, I can see this mount.  But if I wait a
while, it becomes inaccessible, becoming available again only after restarting
autofs.


Version-Release number of selected component (if applicable):
glibc-2.4.90-10
autofs-5.0.0_beta3-6
kernel-2.6.16-1.2232_FC6xen0

How reproducible:
100%

Steps to Reproduce:
1. ls /net/$somehost/$some/$dir
2. wait
3. ls /net/$somehost/$some/$dir
  
Actual results:
    # ls /net/$somehost/$some/$dir
    ls: /net/$somehost/$some/$dir: No such file or directory
on second "ls"

Expected results:
"ls" should work both times.

Additional info:
After
    service autofs restart
I can once again access the mount, for a while.

When the re-access fails, it is always accompanied by a log message complaining,
for example:
Jun  1 23:04:50 ghost automount[5410]: lookup_mount: >> /usr/sbin/showmount:
can't get address for $somehost/$some
ie. it is trying to lookup the host AND the prefix of the subdirectory pathname
as a hostname, and failing.

This fails for top-level maps on a host as well as for subdirectories:

    [root@ghost ~]# ls /net/sisko/kickstart
    [WORKS]
    [root@ghost ~]# ls /net/sisko/disk/new/
    [WORKS]
    ... wait ...
    [root@ghost ~]# ls /net/sisko/kickstart
    ls: /net/sisko/kickstart: No such file or directory
    [root@ghost ~]# ls /net/sisko/disk/new/
    ls: /net/sisko/disk/new/: No such file or directory

leaving behind

Jun  1 23:15:23 ghost automount[7290]: lookup_mount: >> /usr/sbin/showmount:
can't get address for sisko/kickstart
Jun  1 23:15:23 ghost automount[7290]: lookup_mount: lookup(program): lookup for
sisko/kickstart failed
Jun  1 23:15:40 ghost automount[7290]: lookup_mount: >> /usr/sbin/showmount:
can't get address for sisko/disk
Jun  1 23:15:40 ghost automount[7290]: lookup_mount: lookup(program): lookup for
sisko/disk failed

in the logs.
Comment 1 Ian Kent 2006-06-01 21:07:35 EDT
(In reply to comment #0)
> Description of problem:
> After upgrading a working rawhide to autofs-5.0.0-beta, /net now fails to
> remount subdirectories if the mount times out and expires, as near as I can make
> out.

I thought I'd fixed this with revision 6.
Obviously not.

I'll get right on it.

Ian
Comment 2 Ian Kent 2006-06-02 07:10:29 EDT
(In reply to comment #1)
> (In reply to comment #0)
> > Description of problem:
> > After upgrading a working rawhide to autofs-5.0.0-beta, /net now fails to
> > remount subdirectories if the mount times out and expires, as near as I can make
> > out.
> 
> I thought I'd fixed this with revision 6.
> Obviously not.

I'm not certain but I believe I've fixed this while sorting out
the issue with the wildcard entry in maps. I found a place where
I failed to release a mutex during expire runs. I must have made
this blunder fairly recently as I would have noticed it earlier.

So please check autofs-5.0.0_beta4-1 (when it appears on the mirrors)
and see if it resolves this problem.

Ian
Comment 3 Stephen Tweedie 2006-06-02 08:18:49 EDT
A local build of autofs-5.0.0_beta4-1 shows exactly the same problem.

It appears that the lookup_mount is failing to construct the correct hostname to
pass to /usr/sbin/showmount: the errors

Jun  1 23:15:23 ghost automount[7290]: lookup_mount: >> /usr/sbin/showmount:
can't get address for sisko/kickstart
Jun  1 23:15:23 ghost automount[7290]: lookup_mount: lookup(program): lookup for
sisko/kickstart failed

indicate that the hostname being passed to showmount is mistakenly getting the
first component of the pathname appended to it.  And indeed, running showmount
with the same arguments at the command line shows the same errors.
Comment 4 Ian Kent 2006-06-02 08:54:55 EDT
(In reply to comment #3)
> A local build of autofs-5.0.0_beta4-1 shows exactly the same problem.
> 
> It appears that the lookup_mount is failing to construct the correct hostname to
> pass to /usr/sbin/showmount: the errors
> 
> Jun  1 23:15:23 ghost automount[7290]: lookup_mount: >> /usr/sbin/showmount:
> can't get address for sisko/kickstart
> Jun  1 23:15:23 ghost automount[7290]: lookup_mount: lookup(program): lookup for
> sisko/kickstart failed
> 
> indicate that the hostname being passed to showmount is mistakenly getting the
> first component of the pathname appended to it.  And indeed, running showmount
> with the same arguments at the command line shows the same errors.
> 

OK. I'll try harder to duplicate this.
Can you outline what you're doing to give me something to
work with please?

Ian
Comment 5 Ian Kent 2006-06-02 09:04:12 EDT
(In reply to comment #4)
> (In reply to comment #3)

> 
> OK. I'll try harder to duplicate this.
> Can you outline what you're doing to give me something to
> work with please?

Ignore this you've got the detail above.

Ian
Comment 6 Ian Kent 2006-06-02 09:29:43 EDT
(In reply to comment #4)
> (In reply to comment #3)
> > A local build of autofs-5.0.0_beta4-1 shows exactly the same problem.
> > 
> > It appears that the lookup_mount is failing to construct the correct hostname to
> > pass to /usr/sbin/showmount: the errors
> > 
> > Jun  1 23:15:23 ghost automount[7290]: lookup_mount: >> /usr/sbin/showmount:
> > can't get address for sisko/kickstart
> > Jun  1 23:15:23 ghost automount[7290]: lookup_mount: lookup(program): lookup for
> > sisko/kickstart failed

Also could you provide the output from "showmount -e sisko" please.
I'll setup similar here and see if I can duplicate it.

Ian
Comment 8 Ian Kent 2006-06-02 10:27:34 EDT
(In reply to comment #6)
> (In reply to comment #4)
> > (In reply to comment #3)
> > > A local build of autofs-5.0.0_beta4-1 shows exactly the same problem.
> > > 
> > > It appears that the lookup_mount is failing to construct the correct
hostname to
> > > pass to /usr/sbin/showmount: the errors
> > > 
> > > Jun  1 23:15:23 ghost automount[7290]: lookup_mount: >> /usr/sbin/showmount:
> > > can't get address for sisko/kickstart
> > > Jun  1 23:15:23 ghost automount[7290]: lookup_mount: lookup(program):
lookup for
> > > sisko/kickstart failed
> 
> Also could you provide the output from "showmount -e sisko" please.
> I'll setup similar here and see if I can duplicate it.
> 

Got it.

In fact it dawned on me while I was thinking about it.
I'm not cleaning up after myself properly, leaving stale mount
point directories around and letting the umount of the autofs
filesystem do it. This was an experiment that appeared to work
but obviously it's a bad idea. Mostly it's not a problem except
in some specific cases, like this one.

I'll need to check this out a bit further but I should have
something by Monday.

Thanks for your patience.
Ian
Comment 9 Ian Kent 2006-06-05 10:26:27 EDT
(In reply to comment #8)
> > Also could you provide the output from "showmount -e sisko" please.
> > I'll setup similar here and see if I can duplicate it.
> > 
> 
> Got it.
> 
> In fact it dawned on me while I was thinking about it.
> I'm not cleaning up after myself properly, leaving stale mount
> point directories around and letting the umount of the autofs
> filesystem do it. This was an experiment that appeared to work
> but obviously it's a bad idea. Mostly it's not a problem except
> in some specific cases, like this one.
> 
> I'll need to check this out a bit further but I should have
> something by Monday.

Hi Stephen,

Could you try autofs-5.0.0_beta4-3 either from CVS or when it
hits the mirrors please. It's in the build queue now.

Ian
Comment 10 Ian Kent 2006-06-05 23:50:54 EDT
Hi Stephen,

fyi, still shaking out problems with multi-mounts, see
bz# 194069.

Ian
Comment 11 Stephen Tweedie 2006-06-06 13:15:31 EDT
In my own config, which mixes top-level and deeper exports, autofs-5.0.0_beta4-3
(built locally from CVS) fixes this entirely --- thanks!
Comment 12 Ian Kent 2006-06-06 22:30:04 EDT
(In reply to comment #11)
> In my own config, which mixes top-level and deeper exports, autofs-5.0.0_beta4-3
> (built locally from CVS) fixes this entirely --- thanks!
> 

Thanks Stephen,

I'll leave this open a little longer as I'm working on some related
corrections which may impact you.

If I don't hear anything within a few after the update reaches
the mirrors I'll assume all is OK.

Ian

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