Bug 137026 - autofs confusion after updateing nis map
Summary: autofs confusion after updateing nis map
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: autofs   
(Show other bugs)
Version: 3.0
Hardware: All Linux
medium
medium
Target Milestone: ---
Assignee: Jeff Moyer
QA Contact:
URL:
Whiteboard:
Keywords:
Depends On:
Blocks: 132991
TreeView+ depends on / blocked
 
Reported: 2004-10-25 09:14 UTC by David Juran
Modified: 2007-11-30 22:07 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-06-08 13:58:29 UTC
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 16:09 UTC, Brent Fox
no flags Details

Description David Juran 2004-10-25 09:14:05 UTC
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 09:17:19 UTC
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 Jeff Moyer 2004-10-28 20:30:24 UTC
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 17:57:50 UTC
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 16:45:27 UTC
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 18:33:36 UTC
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 18:37:21 UTC
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 Jeff Moyer 2005-03-01 22:49:13 UTC
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 22:37:24 UTC
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 16:43:24 UTC
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 Jeff Moyer 2005-04-25 18:47:48 UTC
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 18:34:14 UTC
 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 Jeff Moyer 2005-06-08 13:58:29 UTC
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.