Sure. I've actually tried to reproduce it here unsuccessfully.
As a starter, I would suggest turning on transport debugging:
# echo 256 > /proc/sys/sunrpc/rpc_debug
Here are my thoughts on how it is supposed to work. Trond if this doesn't match
your understanding, please let me know.
For the case where the client closes the connection first
because it's timeout is shorter (5min vs. 6), the sequence of events should be:
client server
close
sends FIN goes to FIN-WAIT-1
receives FIN replies with ACK
and goes to CLOSE-WAIT
receives ACK goes to FIN-WAIT-2
calls tcp_state_change callback on socket
svc_tcp_state_change sets XPT_CLOSE on
the transport and enqueues transport for
servicing by svc thread.
thread gets dequeued, calls svc_recv
svc_recv sees XPT_CLOSE and calls
svc_xprt_destroy that closes the socket
TCP sends FIN/ACK after close
receives FIN/ACK goes to TIME-WAIT
since state is TIME-WAIT and
reuse port is set, we can re-connect
There's a couple places we could be getting stuck:
- The state-change callback never gets called.
- The state-change callback gets called but svsk is null and it ignores the event
- svc_tcp_state_change enqueues the transport, but due to a race bug, the transport
doesn't actually get queued and since there is no activity it never closes
- something else
The message log with RPCDBG_SVCXPRT (256) enabled as shown above would help figure
out where it's happening.
If Ian is willing to create the log (or already has one), I'm certainly willing to
look at it.
Tom
--
