From: Duffy, Thomas J. (thomas.duffy@ngc.com)
Date: Thu Jan 26 2006 - 10:57:00 EST
Fellow Tru64 Managers,
Many thanks to the folks that assisted me with this issue. The
consensus solution was to utilize the lsof utility which can be
downloaded from:
http://www.tru64.org/dl/lsof.tar.Z
to determine what processes are consuming ports. You need to gunzip and
untar the file and then build it for your target system. I used the
./Configure tru64 command followed by make and it worked fine on my
system. Originally I had an compiling issues because I tried to build
lsof on a version 5.1 system instead of 5.1A/5.1B, but things went
smoothly when I switched to the appropriate OS.
It was also suggested that I utilize the rpcinfo -p command which would
work if the program registered for an RPC. However, that was not so in
my case.
Below is my original request for context:
-----------------------------------------
We have an application running on a Compaq ES40/ES45 with a Tru64 5.1B
OS that listens on udp port 3000 and have found that there is a range of
udp ports that some application is listening on that sometimes collides
with our desired port. The range of consecutive ports varies as we go
from one system to another so the collision occurs on only one of our
systems. The theory is that some application is reserving a range of
ports, but the range is not consistent from one system to another.
By issuing a netstat -na command, we typically see a range of udp port
numbers consumed along with various individual udp ports. Unfortunately
for us, the range of ports on one of our systems encompasses our port
3000. Is there any way we can find out what application(s) is listening
on the range of ports? Taking 3 systems for example, we see that ports
4851-4864 are taken on one system, 3851-3864 on another 1378-1405 on yet
another.
All answers much appreciated.
Tom Duffy
Ph: 410-788-0226
thomas.duffy@ngc.com
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:50:28 EDT