Bug 444899 – rpc.statd using rsync port

Bug 444899 - rpc.statd using rsync port

Summary:	rpc.statd using rsync port

Status:	CLOSED NOTABUG

Aliases:	None

Product:	Red Hat Enterprise Linux 4
Classification:	Red Hat
Component:	nfs-utils (Show other bugs)
Sub Component:
Version:	4.6
Hardware:	All Linux

Priority	low Severity low
Target Milestone:	rc
Target Release:	---
Assigned To:	Steve Dickson
QA Contact:
Docs Contact:

URL:
Whiteboard:
Keywords:

Depends On:
Blocks:
	Show dependency tree / graph

Reported:	2008-05-01 13:03 EDT by jas
Modified:	2008-05-30 08:27 EDT (History)
CC List:	0 users

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

Attachments	(Terms of Use)
Add an attachment (proposed patch, testcase, etc.)

Groups: 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:

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