I have a SLF5 system which is only an NFS client but I see the same issue that rpc.statd is running on a different port for
UDP than it is for TCP. We have seen some strange issues with the automount on this system failing a couple of times to mount the remote client system. Wonder if this is related to what you are seeing. It could be.
Steve Timm
-----Original Message-----
From: [log in to unmask] [mailto:[log in to unmask]] On Behalf Of Eve V. E. Kovacs
Sent: Wednesday, June 26, 2013 1:24 PM
To: scientific-linux-users
Cc: Patrick Riehecky
Subject: peculiar statd/mountd problem
We have an SL5.5 nfs server that has developed an odd problem.
We have configured /etc/sysconfig/nfs to assign port numbers for the various services, 662 for statd and 892 for mountd, in particular.
For reasons unknown, rpc.statd, in addition to running on port 662 as directed, has grabbed port 892 for running udp.
We see, on the server:
rpc.statd 2412 rpcuser 3u IPv4 7443 UDP *:662
rpc.statd 2412 rpcuser 6u IPv4 7434 UDP *:892
rpc.statd 2412 rpcuser 7u IPv4 7446 TCP *:662 (LISTEN)
Since 892 was the port that was assigned to mountd, it caused mountd to fail, and hence nfs mounts from the clients to fail.
We have switched mountd to run on port 895 for the time being, so we are functional, but we would like to understand what happened.
We are running an identical backup server, and interestingly, there, the extra port being grabbed by statd is 982 not 892!
Has anyone else seen this behavior, or have any idea why the two servers are behaving differently?
Presumably this extra port for statd is being assigned by portmap.
Is there any way to fix this port assigment so that we don't get a collision like this in the future?
Thanks
Eve
ps. we tried booting to the previous kernel but that did not fix the problem
***************************************************************
Eve Kovacs
Argonne National Laboratory,
Room L-177, Bldg. 360, HEP
9700 S. Cass Ave.
Argonne, IL 60439 USA
Phone: (630)-252-6208
Fax: (630)-252-5047
email: [log in to unmask]
***************************************************************
|
