Application locking port - CLOSE_WAIT

[Adam Noble]

Hi all,

We have an application that attempts to use a specific port when it starts up. Unfortunately we can't start the application as the port is in use. It looks like poor coding as a netstat -a shows 2 entries one in a CLOSE_WAIT state and one in FIN_WAIT2. As far as I am aware I cannot release the port. I have seen threads suggesting things to do to prevent this happening. Can I confirm that I would need to reboot to clear this port lock. There are no processes running for the application so I can't kill a process to rectify this.

[Ivan Krastev · Accepted solution]

Try to close it manually instead of reboot - http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1000913

regards,
ivan

[Peter Godron]

Adam,
I have been in similar situation a number of times, and the only reliable way to clear the port was to reboot.
Sorry !
Hope somebody else managed to find a solution for this, I couldn't.

[Adam Noble]

lsof did the trick much appreciated I was able to see a process holding this port open even tho it was not owned by application.

[rick jones]

An application which cannot restart (ie bind its well-known port number) while there are still TCP endpoints in states other than LISTEN is broken.

It needs to be setting SO_REUSEADDR so it can rebind to the well-known port number while old endpoints (other than LINSTEN) remain.

99 times out of 10, CLOSE_WAIT means either the application forgot to pay attention to the read return of zero which it got when the other end went to FIN_WAIT_2, or the application forked() after accepting the connection and forgot to close the extra reference to that socket. IE that also means, 99 times out of 10 that the application is buggy.

Any ndd "kill the endpoint" stuff is simply a massive kludge.