From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.0.10) Gecko/20070312 Red Hat/1.5.0.10-2.el5 Firefox/1.5.0.10 Description of problem: In our last downtime we applied relevent updates to our system. One package was autofs that was version autofs-4.1.3-187 and in the update process was upgraded to autofs-4.1.3-199.3. We later noticed that one of our autofs maps was no longer working. This specific map uses the documented multi server features in the man pages for autofs. An example of this multi server map file is: ---<start snip>--- * -udp,rsize=32768,wsize=32768,nfsvers=3,nolock,hard,intr,timeo=16,retrans=8 fileserv-psmith-h01.chpc.utah.edu:/mnt/iGrid/CRSim_PSmith/export/& \ fileserv-reichler-h01.chpc.utah.edu:/mnt/iGrid/MET_Reichler/export/& \ fileserv-molinero-h01.chpc.utah.edu:/mnt/iGrid/CHEM_Molinero/export/& \ fileserv-zpu-h01.chpc.utah.edu:/mnt/iGrid/MET_ZPu/export/& \ fileserv2.helmsdeep:/uufs/chpc.utah.edu/common/home/& ---<end snip>--- What the file simply does is reuse the same autofs mount point but looks through different servers to find the requested directory/file to mount. According to the docs for autofs the way things work is that it attempts to ask all servers listed for the request and gives a .1 second timeout. If it does not get a sucessfull reply it then retries again to all servers with a 10 second timeout. From what we can see watching logs with the new, broken, version is that it only tries the first server listed and never tries the other servers. We worked around this issue by rolling back to the autofs-4.1.3-187 version and things return to proper functionality. Version-Release number of selected component (if applicable): autofs-4.1.3-199.3 How reproducible: Always Steps to Reproduce: See description. Actual Results: If you are on the older working version, which has been working since RHEL4 was released, you will mount all directories your multiple servers are offering out. If you are using the newer, broken, version you will only be able to mount files/dirs from the first server listed in the file. All other dir/file mount attemps will report unavaliable. Expected Results: We should have mounted all dirs/files from the appropriate server in the list of servers. Additional info: To be clear to make sure I'm communicating things right. Each server has a unique set of directories that each is exporting. So specifically there are no name colisions in terms of more then one server having a directory of the same name.
Please try the autofs packages located here: http://people.redhat.com/~jmoyer/autofs/rhel4/4.1.3-214 That version has the replicated server selection code backported from autofs v5. If this does not work for you, then please provide the debugging information requested in the section entitled, "Filing bug reports" on my people page: http://people.redhat.com/jmoyer/ Thanks.
[root@br001 ~]# rpm -q autofs autofs-4.1.3-214 [root@br001 ~]# uname -r 2.6.9-42.0.10.ELsmp [root@br001 ~]# uname -r 2.6.9-42.0.10.ELsmp [root@br001 ~]# cat /etc/auto.master /uufs/bioinfo.utah.edu/common/rnafs /etc/auto.rnafs /uufs/bioinfo.utah.edu/common/dnafs /etc/auto.dnafs /uufs/bioinfo.utah.edu/common/amberfs /etc/auto.amberfs /uufs/chpc.utah.edu/common/home /etc/auto.chpc --debug /uufs/chpc.utah.edu/common/centaurus /etc/auto.centaurus /uufs/geophys.utah.edu/common/utamfs /etc/auto.utamfs /uufs/geophys.utah.edu/common/seismic /etc/auto.seismic /uufs/hec.utah.edu/common/hecfs /etc/auto.hecfs /uufs/hec.utah.edu/common/hydrogen /etc/auto.hydrogen /uufs/hec.utah.edu/common/vothfs1a /etc/auto.vothfs1a /uufs/hec.utah.edu/common/vothfs1b /etc/auto.vothfs1b /uufs/hec.utah.edu/common/vothfs2a /etc/auto.vothfs2a /uufs/hec.utah.edu/common/vothfs2b /etc/auto.vothfs2b /uufs/inscc.utah.edu/common/home /etc/auto.home /uufs/inscc.utah.edu/common/cosmic /etc/auto.cosmic /uufs/crsim.utah.edu/common/crsimfs /etc/auto.crsimfs /uufs/geophys.utah.edu/common/tomofs /etc/auto.tomofs [root@br001 ~]# cat /etc/auto.chpc * -udp,rsize=32768,wsize=32768,nfsvers=3,nolock,hard,intr,timeo=16,retrans=8 fileserv-psmith-h01.chpc.utah.edu:/mnt/iGrid/CRSim_PSmith/export/& \ fileserv-reichler-h01.chpc.utah.edu:/mnt/iGrid/MET_Reichler/export/& \ fileserv-molinero-h01.chpc.utah.edu:/mnt/iGrid/CHEM_Molinero/export/& \ fileserv-zpu-h01.chpc.utah.edu:/mnt/iGrid/MET_ZPu/export/& \ fileserv2.helmsdeep:/uufs/chpc.utah.edu/common/home/& [root@br001 ~]# cat /etc/nsswitch.conf passwd: compat shadow: compat group: compat hosts: files dns ethers: files netmasks: files networks: files protocols: files rpc: files services: files netgroup: files nis automount: files aliases: files [root@br001 ~]# cat /etc/sysconfig/autofs # Define custom options in /etc/sysconfig/autofs # Use LOCALOPTIONS for defining variables, e.g. OSREL # Use DAEMONOPTIONS to define the unmount timeout # Define UNDERSCORETODOT as 1 to convert # auto_home to auto.home and auto_mnt to auto.mnt # Mount options, e.g. rsize=8192, should go in auto.master or # the auto_* map entry for a specific mount point # LOCALOPTIONS="" DAEMONOPTIONS="--timeout=60" LDAPAUTOMASTER="" # UNDERSCORETODOT changes auto_home to auto.home and auto_mnt to auto.mnt UNDERSCORETODOT=1 DISABLE_DIRECT=1 # Only source one master map if set to 1. This would mimic Sun behaviour. # The default is 0 to maintain backwards compatibility. ONE_AUTO_MASTER=0 # List of directories to be ghosted, separated by white space. GHOSTDIRS="" # Base DN to use when searching for the master map BASEDN= # The ldap module was updated to only try the first schema that works # (instead of trying all 3 autofs schemas for each lookup). It is # possible, though unlikely, that this could cause problems. If you update # the automounter and find that your ldap schemas doesn't work as it did # previously, try setting this option to 1. Please also report the problem, # as it is likely that your schema is incompatible with autofs v5. OLD_LDAP_LOOKUP=0 I used the --debug in the auto.master file and with the new version of autofs you asked me to try I captured the following from the logs. This time it seems to have taken the last server in the list and worked correctly with it but the other servers it did not. Specifically user brian is served from fileserv2.helmsdeep where user vale and reichler each come from one of the other servers in the server list. ---<start syslog snip>--- May 7 16:07:53 br001.balancedrock.arches automount[8286]: attempting to mount entry /uufs/chpc.utah.edu/common/home/vale May 7 16:07:53 br001.balancedrock.arches automount[10084]: parse(sun): entry vale is empty! May 7 16:07:53 br001.balancedrock.arches automount[10084]: failed to mount /uufs/chpc.utah.edu/common/home/vale May 7 16:07:53 br001.balancedrock.arches automount[8286]: attempting to mount entry /uufs/chpc.utah.edu/common/home/vale May 7 16:07:53 br001.balancedrock.arches automount[10085]: >> mount: fileserv2.helmsdeep:/uufs/chpc.utah.edu/common/home/vale failed, reason given by server: No such file or directory May 7 16:07:53 br001.balancedrock.arches automount[10085]: mount(nfs): nfs: mount failure fileserv-psmith-h01.chpc.utah.edu:/mnt/iGrid/CRSim_PSmith/export/vale fileserv-reichler-h01.chpc.utah.edu:/mnt/iGrid/MET_Reichler/export/vale fileserv-molinero-h01.chpc.utah.edu:/mnt/iGrid/CHEM_Molinero/export/vale fileserv-zpu-h01.chpc.utah.edu:/mnt/iGrid/MET_ZPu/export/vale fileserv2.helmsdeep:/uufs/chpc.utah.edu/common/home/vale on /uufs/chpc.utah.edu/common/home/vale May 7 16:07:53 br001.balancedrock.arches automount[10085]: failed to mount /uufs/chpc.utah.edu/common/home/vale May 7 16:07:57 br001.balancedrock.arches automount[8286]: attempting to mount entry /uufs/chpc.utah.edu/common/home/reichler May 7 16:07:57 br001.balancedrock.arches automount[10093]: parse(sun): entry reichler is empty! May 7 16:07:57 br001.balancedrock.arches automount[10093]: failed to mount /uufs/chpc.utah.edu/common/home/reichler May 7 16:07:57 br001.balancedrock.arches automount[8286]: attempting to mount entry /uufs/chpc.utah.edu/common/home/reichler May 7 16:07:57 br001.balancedrock.arches automount[10094]: >> mount: fileserv2.helmsdeep:/uufs/chpc.utah.edu/common/home/reichler failed, reason given by server: No such file or directory May 7 16:07:57 br001.balancedrock.arches automount[10094]: mount(nfs): nfs: mount failure fileserv-psmith-h01.chpc.utah.edu:/mnt/iGrid/CRSim_PSmith/export/reichler fileserv-reichler-h01.chpc.utah.edu:/mnt/iGrid/MET_Reichler/export/reichler fileserv-molinero-h01.chpc.utah.edu:/mnt/iGrid/CHEM_Molinero/export/reichler fileserv-zpu-h01.chpc.utah.edu:/mnt/iGrid/MET_ZPu/export/reichler fileserv2.helmsdeep:/uufs/chpc.utah.edu/common/home/reichler on /uufs/chpc.utah.edu/common/home/reichler May 7 16:07:57 br001.balancedrock.arches automount[10094]: failed to mount /uufs/chpc.utah.edu/common/home/reichler May 7 16:07:59 br001.balancedrock.arches automount[8286]: attempting to mount entry /uufs/chpc.utah.edu/common/home/brian May 7 16:07:59 br001.balancedrock.arches automount[10099]: mount(nfs): mounted fileserv2.helmsdeep:/uufs/chpc.utah.edu/common/home/brian on /uufs/chpc.utah.edu/common/home/brian ---<end syslog snip>---
OK, this *may* be a duplicate of 239370. I'll try to reproduce this as soon as possible. Thanks!
Any updates to this bug yet?
Created attachment 159874 [details] Convert the internal representation of the nfs version number to one accepted by the rpc layer. This patch addresses the problem in my environment.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
A fix for this issue was committed to autofs-4.1.3-227.
This bugzilla has Keywords: Regression. Since no regressions are allowed between releases, it is also being proposed as a blocker for this release. Please resolve ASAP.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2007-0734.html