> On 18. Mar 2021, at 13:42, Scheffenegger, Richard > <richard.scheffeneg...@netapp.com> wrote: > >>> 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. Jason noted:
When the issue occurs, this is what I see on the NFS Server. tcp4 0 0 NFS.Server.IP.X.2049 NFS.Client.IP.X.51550 CLOSE_WAIT which corresponds to the state on the client side. The server received the FIN from the client and acked it. The server is waiting for a close call to happen. So the question is: Is the server also closing the connection? Best regards Michael > This will last for ~2 min or so, but is asynchronous. However, the same > 4-tuple can not be reused during this time. > > 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) > > > _______________________________________________ > 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" _______________________________________________ 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"
