topic Re: Kill a socket that does not have a bg device in Operating System - OpenVMS

Kill a socket that does not have a bg device

stephenbrayshaw — Tue, 16 Aug 2016 15:44:08 GMT

I have an issue where I have a socket stuck in FIN_WAIT_1 that does not have a BG device.

I found it through tcpip netstat -a

how can I kill it?

the line is

tcp 0 62010 JANE.4101 10.4.20.106.51425 FIN_WAIT_1

I am running Itanium OpenVMS 8.4 TCPIP V5.7-13ECO2

Re: Kill a socket that does not have a bg device

KIP — Tue, 16 Aug 2016 19:21:50 GMT

I hope in advance that you may find this helpful:

My suggestion would be within TCPIP, to show services (*) and see if you do find a service associated with port 4101. Then if willing, disable or set no service on the service found to be associated with port 4101, Stop, Test - Systems, etc... and then add the service back in as before. It'd be important to save the results of sho service X to reinstate (Set Service Enable) again.

This suggestion is based on being able to see a single correlation with the port and service, where the found service is X above.

I'd proceed with caution, but the above may help or lead you to another solution path to see further into why FIN_WAIT_1 status is there.

Kip

Re: Kill a socket that does not have a bg device

Hoff — Tue, 16 Aug 2016 19:32:26 GMT

TCP/IP Services ECO5 is available. The application code involved looks broken, or some firewall stomped on something. FIN-WAIT-1 means the local app has started the socket close handshake, but the remote end hasn't answered.

That's if tcp_msl hasn't cleared this by now — that usually clears in a minute or three, too.

Might also try SO_REUSEADDR and SO_REUSEPORT on a somewhat recoded application socket request, as I'm guessing that you're getting stuck with a conflict here.

AFAIK, there's no way to clear that if the timers haven't done so already, short of a reboot.

Maybe use your reboot of at least TCP/IP Services to load the current patch?

Re: Kill a socket that does not have a bg device

stephenbrayshaw — Fri, 19 Aug 2016 10:37:06 GMT

Turns out the remote client was refusing to close any connections due to a prompt being left open asking the user if they wanted to close the connection and upon being forceably powered off the lingering socket has closed properly.

I will inform our customer of the available patch & work to get all of their systems patched.

We are unable to add the resuse as we are using the process to have virtual terminals for our application and blocking on duplicate name error is an additional safe guard.