CLOSE_WAIT,FIN_WAIT_2

[vimali balakrishnan]

Hi

when I executed netstat -a|grep dsrpc,soe processes got listed with status as CLOSE_WAIT,FIN_WAIT_2.Does this indicate that the client connections to the server is closed and the port needs to be released?
How can we find out the time taken for the port to be released?
In my case,the status is CLOSE_WAIT,FIN_WAIT_2 for more than 2 hours.
can anyone help me out in resolving this?


Thanks

[ajith]

Hi

when I executed netstat -a|grep dsrpc,soe processes got listed with status as CLOSE_WAIT,FIN_WAIT_2.Does this indicate that the client connections to the server is closed and the port needs to be released?
How can we find out the time taken for the port to be released?
In my case,the status is CLOSE_WAIT,FIN_WAIT_2 for more than 2 hours.
can anyone help me out in resolving this?


Thanks

Try stopping and restarting the Datastage engine.


To stop the server engine, use:
# dshome/bin/uv -admin -stop
This shuts down the server engine and frees any resources held by server
engine processes.
To restart the server engine, use:
# dshome/bin/uv -admin -start
This ensures that all the server engine processes are started correctly.
You should leave some time between stopping and restarting. A minimum
of 30 seconds is recommended.

[ArndW]

the DS engine will not start up with processes attached in the FIN_ or CLOSE_ wait statuses. Have you brought down that instance? Also, which flavor of UNIX are you using - I recall issues with HP-UX where an OS bug prevented these sockets from being released.

[chulett]

These are the result of bringing the engine down with client connections currently open. Sometimes that's unavoidable because of broken connections, but you should always make an effort to ensure everyone is off that can get off before it comes down.

They should clear themselves with time. We're running H-PUX and while it can take up to 20 minutes sometimes it generally takes a few minutes for those ports to clear. And as Arnd notes, while the engine will start the dsrpcd deamon will not be able to bind to the port it uses if a single one of these still exists.

When times get long like that, get an SA involved. Root can clear those ports manually. Also keep in mind the fact that other servers can be keeping the port open - once had a situation where even rebooting the UNIX server DataStage lived on did not clear the ports - blew my mind until we figured that out. This was a clustered configuration so probably had something to do with it.

[ray.wurlod]

On some variations of UNIX the ndd command can report (and be used by root to change) the TCP wait timeout.