NFS Mount Hangs

[Rick Macklem]

Michael Tuexen wrote:
>> On 18. Mar 2021, at 13:42, Scheffenegger, Richard <Richard.Scheffenegger at 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?
Did you mean to say "client closing the connection here?"

The server should call soclose() { it never calls soshutdown() } when
soreceive(with MSG_WAIT) returns 0 bytes or an error that indicates
the socket is broken.
--> The soreceive() call is triggered by an upcall for the rcv side of the socket.
So, are you saying the FreeBSD NFS server did not call soclose() for this case?

rick

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 at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"