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