Bug 200312

Summary: fstab mounting of different nfs servers broken
Product: Red Hat Enterprise Linux 3 Reporter: Josko Plazonic <plazonic>
Component: util-linuxAssignee: Steve Dickson <steved>
Status: CLOSED ERRATA QA Contact: Brian Brock <bbrock>
Severity: high Docs Contact:
Priority: medium    
Version: 3.0CC: coughlan, kzak, olle, tao
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: RHBA-2006-0657 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-08-28 14:23:08 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 190430    
Attachments:
Description Flags
strace of failing mount none

Description Josko Plazonic 2006-07-26 19:55:35 UTC
Description of problem:
If two or more different nfs servers are listed in fstab mount 2.11y-31.18
cannot mount them both - it will only mount the first one in most cases (as long
as rpc.mountd is listening on different ports on these servers).

The reason is addition of util-linux-2.11y-nfsmount-mountd-udp.patch in
2.11y-31.18 release.  What happens is that portmap is queried on the first
server, that info is cached in a static struct and not reset when mounting the
second server. As a result of that bug mount uses the rpc.mountd port of the
first server to talk to the rpc.mountd on the second server.  I include relevant
strace that shows this.

A brute force fix is:
--- util-linux-2.11y/mount/nfsmount.c.jpfix     2006-07-26 14:01:18.000000000 -0400
+++ util-linux-2.11y/mount/nfsmount.c   2006-07-26 14:05:45.000000000 -0400
@@ -267,6 +267,8 @@
        time_t prevt;
        time_t timeout;

+
+       pmaps = NULL;
        /* The version to try is either specified or 0
           In case it is 0 we tell the caller what we tried */
        if (!*nfs_mount_vers)


Version-Release number of selected component (if applicable):
2.11y-31.18

How reproducible:
check steps

Steps to Reproduce:
1. Have two different nfs servers in fstab, make sure they have mountd listening
on different ports - important.
2. mount -a 
  
Actual results:
Only the first nfs mount will be mounted.  Second mount will fail with errors
(like "mount: RPC: Unable to receive; errno = Connection refused").

Expected results:
All nfs mounts should be mounted.

Additional info:
connect(3, {sa_family=AF_INET, sin_port=htons(53),
sin_addr=inet_addr("172.16.16.2")}, 28) = 0
recvfrom(3, "i\377\205\200\0\1\0\1\0\6\0\6\4maia\3sns\3ias\3edu\0\0"..., 1024,
0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("172.16.16.2")},
[16]) = 258
bind(3, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("0.0.0.0")},
16) = 0
connect(3, {sa_family=AF_INET, sin_port=htons(111),
sin_addr=inet_addr("172.16.16.9")}, 16) = 0
bind(3, {sa_family=AF_INET, sin_port=htons(1003),
sin_addr=inet_addr("0.0.0.0")}, 16) = 0
sendto(3, "@\226s\330\0\0\0\0\0\0\0\2\0\1\206\245\0\0\0\3\0\0\0\1"..., 108, 0,
{sa_family=AF_INET, sin_port=htons(32767), sin_addr=inet_addr("172.16.16.9")},
16) = 108
recvfrom(3, "@\226s\330\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 8800,
0, {sa_family=AF_INET, sin_port=htons(32767),
sin_addr=inet_addr("172.16.16.9")}, [16]) = 68
bind(4, {sa_family=AF_INET, sin_port=htons(1004),
sin_addr=inet_addr("0.0.0.0")}, 16) = 0
connect(3, {sa_family=AF_INET, sin_port=htons(53),
sin_addr=inet_addr("172.16.16.2")}, 28) = 0
recvfrom(3, "Y\227\205\200\0\1\0\1\0\6\0\6\4maia\3sns\3ias\3edu\0\0"..., 1024,
0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("172.16.16.2")},
[16]) = 258
bind(3, {sa_family=AF_INET, sin_port=htons(1005),
sin_addr=inet_addr("0.0.0.0")}, 16) = 0
sendto(3, "n\264\344B\0\0\0\0\0\0\0\2\0\1\206\245\0\0\0\2\0\0\0\1"..., 108, 0,
{sa_family=AF_INET, sin_port=htons(32767), sin_addr=inet_addr("172.16.16.9")},
16) = 108
recvfrom(3, "n\264\344B\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 8800,
0, {sa_family=AF_INET, sin_port=htons(32767),
sin_addr=inet_addr("172.16.16.9")}, [16]) = 60
bind(5, {sa_family=AF_INET, sin_port=htons(1006),
sin_addr=inet_addr("0.0.0.0")}, 16) = 0
connect(3, {sa_family=AF_INET, sin_port=htons(53),
sin_addr=inet_addr("172.16.16.2")}, 28) = 0
recvfrom(3, "\7\'\205\200\0\1\0\2\0\6\0\6\10mailhost\3sns\3ias\3ed"..., 1024, 0,
{sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("172.16.16.2")},
[16]) = 284
bind(3, {sa_family=AF_INET, sin_port=htons(1007),
sin_addr=inet_addr("0.0.0.0")}, 16) = 0
sendto(3, "P\27\33i\0\0\0\0\0\0\0\2\0\1\206\245\0\0\0\3\0\0\0\1\0"..., 108, 0,
{sa_family=AF_INET, sin_port=htons(32767), sin_addr=inet_addr("172.16.17.19")},
16) = 108
recvmsg(3, {msg_name(16)={sa_family=AF_INET, sin_port=htons(32767),
sin_addr=inet_addr("172.16.17.19")},
msg_iov(1)=[{"P\27\33i\0\0\0\0\0\0\0\2\0\1\206\245\0\0\0\3\0\0\0\1\0"..., 108}],
msg_controllen=44, {cmsg_len=44, cmsg_level=SOL_IP, cmsg_type=, ...},
msg_flags=MSG_ERRQUEUE}, MSG_ERRQUEUE) = 108

Comment 1 Steve Dickson 2006-07-27 14:44:06 UTC
Fixed in mount-2.11y-31.19

Comment 2 Jeff Layton 2006-07-28 17:29:36 UTC
*** Bug 200529 has been marked as a duplicate of this bug. ***

Comment 3 Jeff Layton 2006-07-28 17:44:49 UTC
Created attachment 133254 [details]
strace of failing mount

I just tried the package in 3.0E-errata-candidate and am still seeing the same
problem. Here's an strace from a failed "mount -t nfs -a". The first mount that
it attempts is successful, but subsequent mounts still fail.

It looks like the problem is that it consults the portmapper for the first
server to get the mountd port, and then assumes that all other servers are
using the same port.

Comment 4 Josko Plazonic 2006-07-28 17:54:46 UTC
That's exactly what is happening - maybe I didn't explain it clearly enough but
read above.  I also included a fix above that is confirmed to work even though
it is not very elegant.

BTW this is probably a significant enough regression that you should  probably
consider pushing this fix earlier rather than later - but don't mind me...

Comment 5 Jeff Layton 2006-07-28 18:59:28 UTC
Oops, the patch that went into -31.19 *does* seem to correct the problem. I had
updated the wrong package when testing before.


Comment 6 Karel Zak 2006-08-18 14:52:31 UTC
*** Bug 203117 has been marked as a duplicate of this bug. ***

Comment 13 Red Hat Bugzilla 2006-08-28 14:23:12 UTC
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-2006-0657.html