Bug 156655

Summary: rpc.statd dies immediately when STATD_PORT=786
Product: Red Hat Enterprise Linux 4 Reporter: DriveCam Video Systems <cmiller>
Component: nfs-utilsAssignee: Steve Dickson <steved>
Status: CLOSED ERRATA QA Contact: Ben Levenson <benl>
Severity: medium Docs Contact:
Priority: medium    
Version: 4.0CC: tao
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: RHBA-2006-0463 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-08-10 21:28:08 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:
Bug Depends On:    
Bug Blocks: 181409    

Description DriveCam Video Systems 2005-05-02 21:51:09 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.7) Gecko/20050416 Red Hat/1.0.3-1.4.1 Firefox/1.0.3

Description of problem:
I am trying to pin my NFS RPC services to sepcific ports so that I can poke a minimal-sized hole through a firewall and still allow NFS to run.  I have put the line:

STATD_PORT=786

in my /etc/sysconfig/network file to pin rpc.statd to port 786.  This change causes /sbin/rpc.statd to die immediately after being started up without producing an error message.  Even the command:

/sbin/rpc.statd -F -d -p 786

fails and returns immediately to the command prompt without saying why.

Version-Release number of selected component (if applicable):
nfs-utils-1.0.6-46

How reproducible:
Always

Steps to Reproduce:
1. Add the line "STATD_PORT=786" to /etc/sysconfig/network
2. Run /etc/rc.d/init.d/nfslock restart

  

Actual Results:  ps ax | grep stat shows that rpc.statd is not running.
rpcinfo -p shows that there is no status service registered with the portmapper.

Expected Results:  A rpc.statd should appear in the process list.  The status service should appear in the portmapper service registry, bound to port 786.

Additional info:

Tried on both RHEL4-ES-i386 and RHEL4-WS-x86_64 with the same results.

Comment 6 Steve Dickson 2006-02-10 02:26:52 UTC
So your saying the STATD and LOCKD NEVER get honered??? I did not see that in my 
testing... actually I was able to get all the ports I asked for every single
time I tried... I wonder what the difference is... 

Comment 7 DriveCam Video Systems 2006-02-10 04:21:28 UTC
Just STATD_PORT.  And it's not that it doesn't get honored; it's that it causes
statd to crash.

[root@isengard init.d]# ps ax | grep stat
30571 pts/0    S+     0:00 grep stat
[root@isengard init.d]# rpc.statd -p 785
[root@isengard init.d]# ps ax | grep stat
30571 pts/0    S+     0:00 grep stat
[root@isengard init.d]# rpc.statd -p 31594
[root@isengard init.d]# ps ax | grep stat
30575 ?        Ss     0:00 rpc.statd -p 31594
30577 pts/0    S+     0:00 grep stat
[root@isengard init.d]# kill -TERM 30575
[root@isengard init.d]# rpc.statd -p 785
[root@isengard init.d]# ps ax | grep stat
30581 pts/0    S+     0:00 grep stat
[root@isengard init.d]# rpc.statd -p 1023
[root@isengard init.d]# ps ax | grep stat
30593 pts/0    S+     0:00 grep stat
[root@isengard init.d]# rpc.statd -p 1024
[root@isengard init.d]# ps ax | grep stat
30595 ?        Ss     0:00 rpc.statd -p 1024
30597 pts/0    S+     0:00 grep stat
[root@isengard init.d]# kill -TERM 30595

Seems to work as long as the requested port number is >= 1024.  Did you test
with priviledged ports?  Does it drop privs before it tries to open the port maybe?

Comment 8 Steve Dickson 2006-05-14 01:56:46 UTC
Fixed in nfs-utils-1.0.6-70.EL4

Comment 12 Red Hat Bugzilla 2006-08-10 21:28:14 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2006-0463.html