Bug 444899

Summary: rpc.statd using rsync port
Product: Red Hat Enterprise Linux 4 Reporter: jas
Component: nfs-utilsAssignee: Steve Dickson <steved>
Status: CLOSED NOTABUG QA Contact:
Severity: low Docs Contact:
Priority: low    
Version: 4.6   
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-05-30 12:27:55 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:

Description jas 2008-05-01 17:03:12 UTC 
Description of problem:

After kickstarting a new server today, when xinetd started, it complained that
the port for rsync (port 873) was already in use.  As it happens, it was in use
by rpc.statd.  Looking at the source for rpc.statd, if a port number hasn't been
specified, it looks like it relies on bind to get a port number. I may be wrong.
 However, /proc/sys/net/ipv4/ip_local_port_range contains
32768   61000
... so bind should never have used port 873?

Afterwards, we created /etc/sysconfig/nfs containing:

STATD_PORT=32765
STATD_OUTGOING_PORT=32766

... which solved the problem, but we've never had to do this on any of our other
servers before.  On our other servers, rpc.statd is also using a port less than
1024 -- 773 on one other host.

I don't know how bind determines the address to use.  I'm not exactly sure where
to report this bug, so I'll report it here, and hope that you can change the
"Component" appropriately.

Thanks..
Comment 1 Steve Dickson 2008-05-30 12:27:55 UTC 
The port space is first come first server... so it is possible
for statd to "steal" other well know ports... 

You took the correct action...