Operating System - HP-UX
1833797 Members
4533 Online
110063 Solutions
New Discussion

Socket connection release

 
SOLVED
Go to solution
Herve BRANGIER
Respected Contributor

Socket connection release

Hi,

Do you known how to force a socket release ?

Our problem is that sometimes after a server
crash, the port is not release and we can't
restart this software. So we need to force
release of this port at system level.

Thanks

Herve
3 REPLIES 3
James R. Ferguson
Acclaimed Contributor

Re: Socket connection release

Hi:

You may be faced with a reboot to clear the port.

While 'netstat -an' will show you the ports in use, you will need 'lsof' to determine what process is bound to the port.

See also, my comments in this thread:

http://my1.itrc.hp.com/cm/QuestionAnswer/1,1150,0xacfe5f260cafd4118fef0090279cd0f9,00.html

A very good discussion of what you are seeing can be found in this thread:

http://my1.itrc.hp.com/cm/QuestionAnswer/1,1150,0xdc968d77ef20d411b66300108302854d!1,00.html

...JRF...
Craig Gilmore
Trusted Contributor
Solution

Re: Socket connection release

James is right, you might be faced with a system reboot to clear this problem. However, you did not specify if you were running HP-UX 11.00 or 10.20.

On 10.20, the only way to clear a port in use where the application using the port did not clear it is to reboot.

However starting with 10.30 and on 11.00 you can use ndd and tcp_discon_by_addr to free up a hung TCP connected port, even if the process that owned the port is no longer running.

You will need the full IP and PORT number for both sides of the connection. This needs to be converted to a 32 byte hex number. But it usually is less intrusive than a full system reboot.
rick jones
Honored Contributor

Re: Socket connection release

sigh - i would suggest that folks not get into the habit of using the unsupported tcp_discon_mumble mechanisms to clear perceived hung ports. knuth only knows what sort of havoc it could wreak.

if an application will not restart while there are still TCP connections in various states, it indicates a bug in that application. Specifically, the application should be using setsockopt() to set SO_REUSEADDR _before_ it tries to bind() to its well-known port number.

This will allow the app to be restarted while there are still old connections laying around. The only place it will not work is if the old instance of the app is still running and still has a TCP endpoint in the LISTEN state bound to that port number.

So, don't treat the symptom, cure the disease - get the app fixed.
there is no rest for the wicked yet the virtuous have no pillows