Port already in use: 1080

[Vasudevan MV]

I am running the RMI Server on port 1080. I have a cron set for bringing the server down and after a sleep 20, bring it back up.
While Trying to get the RMI Server up it gives the error "Port already in use: 1080"
On several tries, i get the same error.

Is there anyway I can force a port relase while kill the process?

[T G Manikandan]

first find the process using the port using the lsof utility

download it from
ftp://ftp.cerias.purdue.edu/pub/tools/unix/sysutils/lsof/

Then you can do a

lsof -i tcp:1080
to find the process

Then you can stop the process.

Also you could try using a
kill
so that it will terminate the process instead using kill -9.

Also you can use

#netstat |grep


THanks

[Maarten van Rossen]

Two things:

1)It can take a little time before a port is released after being used
2)Is this port registered in /etc/services? if not an other process might get this port
especially sinds this port is not lowwer than 1024.
You could download a utillity called lsof from the internet. This utillity can show you which process is using what port.

I hope this helps you

[T G Manikandan]

Also check this thread to use ndd instead killing the process.

http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0xbe06a22d6d27d5118fef0090279cd0f9,00.html


Thanks

[Hai Nguyen_1]

I think that it depends on your tcp/ip settings. You cannot force it to release right away. You may modify some tcp/ip settings to have a port released faster. I do not remember what they are.

Hai

[Sajid_1]

hello,

the best tool will be lsof. You could see which process is running on the specific port and if needed you can kill it using this tool. Download it from the porting centre, it's free!

gl,

[Stefan Farrelly]

Yes, lsof is the way to id which pid is using the port, but killing the process may NOT free up the port - especially if there is a remote tcp connection to it. In this case you will need to either reboot the remote device to free it up or kill the stuck tcp socket with the ndd command;

To use the ndd -set /dev/tcp tcp_discon, you need the pointer to the TCP instance data. You can retrieve this via the ndd command tcp_status.

So, the scenario to find the TCP instance data and then use tcp_discon to remove the instance is as follows:

# ndd -get /dev/tcp tcp_status
TCP dest snxt suna swnd cwnd rnxt rack rwnd rto mss [lport,fport] state

0183b8b4 015.043.233.086 533cb8ce 533cb8ce 00008000 00003000 533bc583 533bc583
00000000 02812 04096 [c00a,cea9] TCP_CLOSE_WAIT

So, if you wanted to remove this connection:
# ndd -set /dev/tcp tcp_discon 0x0183b8b4

[V. V. Ravi Kumar_1]

hi,
lsof -i:1080
u will get the process id which is holding this port. just kill it.

regds

[harry d brown jr]

Vasudevan,

There is a feature in your profile that allows you to find previous Questions you have posted, which makes it easier to take care of this:

This member has assigned points to 49 of 101 responses to his/her questions.

http://forums.itrc.hp.com/cm/TopSolutions/1,,CA697517!1!questions,00.html

live free or die
harry

[Vasudevan MV]

The port is in /etc/services, so it cannnot be used by any other process.
I kill the process (which uses this port), using kill -9 , so even if any tool shows me the PID, as suggested by Stefan, killing the process may NOT free up the port - especially if there is a remote tcp connection to it.

How can I see & modify the tcp/ip settings for a port release?
Can ndd be used on HP-UX 10.2 machine?

[rick jones]

That the RMI server will not restart after a 20 second wait implies the RMI server has a bug in it - it is not attempting to set SO_REUSEADDR before trying to bind to it's well-known port number.

setting SO_REUSEADDR will allow the RMI server to restart and bind to its port number so long as there are no TCP endpoints in the LISTEN state on that port. endpoints still in TIME_WAIT or FIN_WAIT_2 or ESTABLISHED, etc will not prevent the restart if SO_REUSEADDR is set.

now, if the RMI server forks child processes and those children do not close the listen endpoint, that too may be construed as a bug in the RMI server that needs to be fixed - their continued life means the reference count on the LISTEN endpoint does not go to zero.

i would strongly caution AGAINST using the ndd disconnect kludges. frankly, those are things that should never have left the lab. all it takes is killing the wrong connection by mistake and knuth only knows what sort of trouble could be caused.

besides, with properly written application code, those features should never be needed.