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:
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.
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.
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!
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?
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
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
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.
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
I've added tcpdump data to the internal ticket, as well as a sysreport and script (typescript) of the session generating the tcpdump data.
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.
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
RHEL 3 U5 has this fix. I am closing the bug.