Bug 137026 - autofs confusion after updateing nis map
autofs confusion after updateing nis map
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: autofs (Show other bugs)
3.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jeffrey Moyer
:
Depends On:
Blocks: 132991
  Show dependency treegraph
 
Reported: 2004-10-25 05:14 EDT by David Juran
Modified: 2007-11-30 17:07 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-06-08 09:58:29 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)
Typescript file with test results from -130 (18.47 KB, text/plain)
2005-04-27 12:09 EDT, Brent Fox
no flags Details

  None (edit)
Description David Juran 2004-10-25 05:14:05 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.3)
Gecko/20040924

Description of problem:
During the weekend we moved a filesystem from one of our fileservers
to another one and updated the automounter nis maps accordingly. This
is how the nis maps look:

david 21: ypcat -k auto.master
/- auto.direct  -rw
/users auto.users       -rw
/nfs/ipatinga/isosrv auto.isosrv        -ro
/nfs/vm auto.vm         -rw

Then in auto.vm we changed 
technical_sales -proto=tcp,nointr       lehrter:/lfs/vm/

to

technical_sales -proto=tcp,nointr       fillmore:/vol/vol2/&

On some computers the old filesystem was still in use, so then we did
a 'umount -fl /nfs/vm/technical_sales' and then also 'service autofs
reload'
Now on monday I see several computers, both AMD64 and i386 ones, where
there are problems with autofs. On some computers autofs is dead
altogether, och some there are only 1 or 2 automouter processes
instead of the usual 3, and most disturbingly, on several computers
where the process handling /nfs/vm is alive, it still is bound to
lehrter, the old fileserver instead of the new one.
I do have a sysreport saved from one of these computers if you think
it would be helpful.

Version-Release number of selected component (if applicable):
autofs-4.1.3-12, kernel-smp-2.4.21-20.EL

How reproducible:
Didn't try

Steps to Reproduce:
1. Not sure

    

Additional info:
Comment 1 David Juran 2004-10-25 05:17:19 EDT
Just noticed that on one computer where the automouter process was
bound to the wrong fileserver and 'service autofs reload' didn't work,
kill -HUP on the automounter process solved the problem. Do note that
this method with the HUP did not work on all computers.
Comment 2 Jeffrey Moyer 2004-10-28 16:30:24 EDT
This is a known issue with the current automounter.  Map expiry code will be put
in place in the near future.  I'll update this bug when a version of the package
that fixes these problems is available.
Comment 5 Greg Baker 2005-01-20 12:57:50 EST
Exact same problem here.

NIS-based auto.master
NIS-based automount maps
Change mount location in automount maps, push maps
autofs doesn't recognize the change on random systems; data gets
fscked all over the place.

This behavior began when Redhat introduced autofs4 in U3.

Any updates?

Thanks!
Comment 6 Greg Baker 2005-01-27 11:45:27 EST
kill -HUP on automounter managing mount point using NIS maps that
change cause automounter to function properly.  Any ideas on when/if a
package with map expiry code will become available?
Comment 14 Kiersten (Kerri) Anderson 2005-02-01 13:33:36 EST
Update for Issue Tracker:

Due to the number of changes that have gone into autofs in conjunction with the
U5 development, we are not able to provide a hot fix for this defect at this
time.  At this point, the earliest new version will be part of the beta release
for U5 based on the RHEL3 U5 schedule.
Kevin
Comment 15 Kiersten (Kerri) Anderson 2005-02-01 13:37:21 EST
Try again: Update for Issue Tracker:

Due to the number of changes that have gone into autofs in conjunction with the
U5 development, we are not able to provide a hot fix for this defect at this
time.  At this point, the earliest new version will be part of the beta release
for U5 based on the RHEL3 U5 schedule.
Kevin
Comment 20 Jeffrey Moyer 2005-03-01 17:49:13 EST
A fix for this has been committed to the U5 pool.  Packages versioned 4.1.3-104
and later have the required patches to address this issue.
Comment 21 Greg Baker 2005-03-29 17:37:24 EST
Anybody else have luck with the fix working?  autofs-4.1.3-104 hasn't proven
succesfull in our environment.

Here's a capture of the problem.

*** NIS file currently contains:

[root@sif030 /]# ypcat -k auto.u | grep autofstest
autofstest -intr        fortitud:/vol/vol6/home2/&

*** Sent to syslog via:

[root@sif030 /]# ypcat -k auto.u | grep autofstest | logger

*** Making sure that /home/autofstest isn't mounted

[root@sif030 /]# umount /home/autofstest
[root@sif030 /]# cat /proc/mounts | grep autofstest

*** We then cd to /home/autofstest

[root@sif030 /]# cd /home/autofstest

*** And see that it's mounting from the "old" location

[root@sif030 autofstest]# df -k .
Filesystem           1K-blocks      Used Available Use% Mounted on
escher:/vol/vol2/admin_home/autofstest
                    262144000 200530112  61613888  77% /home/autofstest

*** Parts of syslog (attached files) to look at corrosponding to above

Mar  8 15:46:39 sif030 logger: autofstest -intr        fortitud:/vol/vol6/home2/&
Mar  8 15:46:56 sif030 automount[4058]: handle_packet_missing: token 11, name
autofstest
Mar  8 15:46:56 sif030 automount[4058]: attempting to mount entry /home/autofstest
Mar  8 15:46:56 sif030 automount[8726]: lookup(yp): looking up autofstest
Mar  8 15:46:56 sif030 automount[8726]: ret = 1
Mar  8 15:46:56 sif030 automount[8726]: lookup(yp): autofstest -> -intr       
escher:/vol/vol2/admin_home/&
Mar  8 15:46:56 sif030 automount[8726]: parse(sun): expanded entry: -intr      
 escher:/vol/vol2/admin_home/autofstest


(internal https://enterprise.redhat.com issue #63602).

Ideas?

--greg
Comment 26 Greg Baker 2005-04-25 12:43:24 EDT
I've added tcpdump data to the internal ticket, as well as a sysreport and
script (typescript) of the session generating the tcpdump data.

Comment 29 Jeffrey Moyer 2005-04-25 14:47:48 EDT
Dan,

You should be able to get rid of the is_mounted check.  I can't really see why
it is even there (and removing it gets rid of a memory leak, too).  I've tested
this and it works in my environment.
Comment 35 Greg Baker 2005-04-27 14:34:14 EDT
 I'm doing a happy dance right now.

The problem of "autofs does not recognize when NIS mount points change" appears
to be fixed, as tested on:

  * autofs-4.1.3-130.x86_64.rpm
  * RHEL U5-beta

Tested on 10 systems, multiple times.  I've attached a typescript for details.

Thanks!  

--Greg
Comment 36 Jeffrey Moyer 2005-06-08 09:58:29 EDT
RHEL 3 U5 has this fix.  I am closing the bug.

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