Bug 444899 - rpc.statd using rsync port
rpc.statd using rsync port
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: nfs-utils (Show other bugs)
All Linux
low Severity low
: rc
: ---
Assigned To: Steve Dickson
Depends On:
  Show dependency treegraph
Reported: 2008-05-01 13:03 EDT by jas
Modified: 2008-05-30 08:27 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-05-30 08:27:55 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description jas 2008-05-01 13:03:12 EDT
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:


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

Comment 1 Steve Dickson 2008-05-30 08:27:55 EDT
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.