8:50 a.m.
11 is EAGAIN, which means the socket would have blocked. This is
strange, as 2.8 does blocking writes, so we should never get EAGAIN from
a write. That said, why are you using UDP mounts? TCP mounts are
generally considered to be better in every way (and are the default), so
you might want to try that as a workaround.
Daniel
On 3/11/20 11:17 PM, Todd Pfaff wrote:
Daniel,
Thanks for the guidance about logging. I haven't done packet captures
yet but this is what I'm seeing logged around the time of the error
condition:
11/03/2020 21:51:34 : epoch 5e6994c3 : nfs-server-hostname :
ganesha.nfsd-168948[svc_18] rpc :TIRPC :F_DBG :svc_dg_reply:
0x7f35640008c0 fd 13 sendmsg failed (will set dead)
11/03/2020 21:51:34 : epoch 5e6994c3 : nfs-server-hostname :
ganesha.nfsd-168948[svc_18] complete_request :DISP :DEBUG :NFS
DISPATCHER: FAILURE: Error while calling svc_sendreply on a new
request.
rpcxid=3984287200 socket=13 function:nfs3_read
client:::ffff:10.1.2.3 program:100003 nfs version:3 proc:6 errno: 11
and from the client's perspective nothing can be done with the nfs
mount until the nfs-ganesha server is restarted.
Do you have any suggestions for a recommended tcpdump command line to
capture all useful traffic?
Thanks,
Todd