Bug 444899 - rpc.statd using rsync port
Summary: rpc.statd using rsync port
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: nfs-utils
Version: 4.6
Hardware: All
OS: Linux
low
low
Target Milestone: rc
: ---
Assignee: Steve Dickson
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-05-01 17:03 UTC by jas
Modified: 2008-05-30 12:27 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-05-30 12:27:55 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

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... 


Note You need to log in before you can comment on or make changes to this bug.