Bug 156655 - rpc.statd dies immediately when STATD_PORT=786
rpc.statd dies immediately when STATD_PORT=786
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: nfs-utils (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Steve Dickson
Ben Levenson
Depends On:
Blocks: 181409
  Show dependency treegraph
Reported: 2005-05-02 17:51 EDT by DriveCam Video Systems
Modified: 2007-11-30 17:07 EST (History)
1 user (show)

See Also:
Fixed In Version: RHBA-2006-0463
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-08-10 17:28:08 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 DriveCam Video Systems 2005-05-02 17:51:09 EDT
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:


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

How reproducible:

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-09 21:26:52 EST
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-09 23:21:28 EST
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-13 21:56:46 EDT
Fixed in nfs-utils-1.0.6-70.EL4
Comment 12 Red Hat Bugzilla 2006-08-10 17:28:14 EDT
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.


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