> >>Output from the NFS Client when the issue occurs # netstat -an | grep > >>NFS.Server.IP.X > >>tcp 0 0 NFS.Client.IP.X:46896 NFS.Server.IP.X:2049 > >>FIN_WAIT2 > >I'm no TCP guy. Hopefully others might know why the client would be stuck in > >FIN_WAIT2 (I vaguely recall this means it is waiting for a fin/ack, but > >could be wrong?) > > When the client is in Fin-Wait2 this is the state you end up when the Client > side actively close() the tcp session, and then the server also ACKed the > FIN. > This will last for ~2 min or so, but is asynchronous. However, the same > 4-tuple can not be reused during this time.
I do not think this is the full story. If infact the Client did call close() you are correct, you would end up in FIN_WAIT2 for upto what ever the timeout is set to, IIRC default on that is 60 seconds, further in this case the socket is disconnected from the application and only the kernel has knowledge of it. The socket can stay in FIN_WAIT2 indefanitly if the application calls shutdown(2) on it, and never follows up with a close(2). Which situation exists can be determined by looking at fstat to see if the socket has an associted PID or not, not sure if that works on Linux though. > > With other words, from the socket / TCP, a properly executed active close() > will end up in this state. (If the other side initiated the close, a passive > close, will not end in this state) But only for a brief period. Stuck in this state indicates close(2) was not called, but shutdown(2) was. I believe it is also possible to get sockets stuck in this state when a client side port number reuse colides with a server side socket that is still in s CLOSE_WAIT state, oh wait, that ends up in no response to the SYN, hummmm... > freebsd-net@freebsd.org mailing list -- Rod Grimes rgri...@freebsd.org _______________________________________________ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
