My original Question : >> Ram Kumar wrote: >> > >> >hi.. >> > >> >can anyone throw some light into the "netstat -a" output which at times >> >gives, the status as "FIN_WAIT". >> > >> >if the status remains "FIN_WAIT" for a long time, what changes are needed >on >> >the system..? >> > >> >cheers & smiles >> >ram >> > Replies (few of them...) >On Thu, 8 Apr 1999 16:40:19 -0700 (PDT), Raymond Wong (negativl@netcom.com) wrote: > >> >> This isn't entirely accurate, but it's basically what's happening. >> >> FIN_WAIT means it's waiting for a FIN_ACK reply confirming that a >connection >> has been closed. There are actually 2 ACKs required at when connections >close, >> many tcp/ip stacks (i.e. Microsoft) don't send the second one. If you've >got >> a lot of PCs connecting, you'll end up with FIN_WAITs hanging around until >they >> timeout on on the server end (10 minutes). Usually doesn't hurt things >unless >> you're running out of available connections. >> --------------------------- Darren Dunham ddunham@taos.com Probably nothing. It's more likely a problem with something else. There is no FIN_WAIT. There is FIN_WAIT_1, FIN_WAIT_2, and TIME_WAIT. Assuming you meant one of the first two... The first is the state after the connection has been closed remotely. The OS is attempting to signal the local process that the connection has been closed. The process has not yet acknowleged this. (Probable bug in the code of the local process) The second is a sign of the opposite problem. The local process has asked to close the connection. However, no acknowledgement of this has been received from the remote side. This can indicate a problem with the remote server, or a problem in communication between the two. ------------------------------ Nick Czeczulin nickc@TheAlliedGroup.com hope this helps. tcp_fin_wait_2_flush_interval BSD 675000, default 675000, recommended 67500 (one zero less) This values seems to describe the (BSD) timer interval which prohibits a connection to stay in the FIN_WAIT_2 state forever. FIN_WAIT_2 is reached, if a connection closes actively. The FIN is acknowledged, but the FIN from the passive side didn't arrive yet - and maybe never will. Usually webservers and proxies actively close connections - as long as you don't use persistent connection and even those are closed from time to time. Apart from that HTTP/1.0 compliant server and proxies close connections after each transaction. A crashed or misbehaving browser may cause a server to use up a precious resource for a long time. You should consider decreasing this interval, if netstat -f inet shows many connections in the state FIN_WAIT_2. The timer is only used, if the connection is really idle. Mind that after a TCP half close a simplex data transmission is still available towards the actively closing end. TCP half closes are not yet supported by Squid, though many web servers do support them (certain HTTP drafts suggest an independent use of TCP connections). Nevertheless, as long as the client sends data after the server actively half closed an established connection the timer is not active. -------------------------------------- Franczyk, Gary" It should stay FIN_WAIT for 2 minutes... I think that is the default for Solaris. It means the socket is closed and waiting for any stray duplicates packets that come off the network... Otherwise, if you were to start a new copy of the program that bound to that port, it may catch some packets from the previous instance of the program that were cought in network congestion. ------------------------------------- "Richard Noonan" >From the netstat man page: ---start--- FIN_WAIT1 The socket is closed, and the connection is shutting down. FIN_WAIT2 Connection is closed, and the socket is waiting for a shut-down from the remote end. ---end--- These are being caused by sloppy servers you are connecting to and which are not properly closing their side of the connection. There's really nothing to be done about it. I suppose you could write a script that looks for sockets stuck in this state ... -Ric