-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Just a little more detail on the problem described.
We have designated a fixed port for statd, but it appears to listen on
the designated port and grab the corresponding UDP port but it also
grabbed the UDP mountd port before mountd was started which resulted in
mountd failing to launch.

On 06/26/2013 01:38 PM, Steven C Timm wrote:
> According to the man pages for rpc.statd it is possible to specify a fixed port for that daemon at startup.  I've never tried.
> 
> Steve Timm
> 
> 
> -----Original Message-----
> From: [log in to unmask] [mailto:[log in to unmask]] On Behalf Of Steven C Timm
> Sent: Wednesday, June 26, 2013 1:34 PM
> To: Eve V. E. Kovacs; scientific-linux-users
> Cc: Patrick Riehecky
> Subject: RE: peculiar statd/mountd problem
> 
> 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]
> ***************************************************************
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBAgAGBQJRyzxZAAoJEPQM1KNWz8QaoJUIAMQfc3ZPBUA2nXoh6o8vnBP6
VsFvVOKISw1zrGbx5OYSSOINubEOMaJrKu7ZTX3CWLIEW6TmxV/tWe7TR0q2KaSZ
JgGuZLnMfLfH8lV8cRgKqHBj82N65D7S9BXnL8znIWoSjjlcBLz/fbEQZWmUlB3s
cFbY3B6QFry2UIvYxuNEZMBe1Qzr56OyypVIYF4TEbzeVHJMZgenFAEJNqkw+9rG
EGmsykhrQlWM3zxMSuWsjDq3ZM61bT/JyLwFumyFv+6DR0+nviw6rmDUDXJCErrf
Kh0NLaTJT9hFhD1QAe9AiZMJB1ibLfU/p6Q+ei1mrp4f/+Zp8Bt+6B+BVlue+5M=
=d8LR
-----END PGP SIGNATURE-----