:On May 29, 2008, at 3:12 PM, Matthew Dillon wrote:
:> I guess nobody mentioned the obvious thing to check: Make sure
:> TCP keepalive is turned on.
:>
:> sysctl net.inet.tcp.always_keepalive=1
:
:
:Thanks Matt.
:
:I also thought that a keepalives were not running and sessions just
:stuck around forever, however I do have:
:
:
:net.inet.tcp.keepidle=900000
:net.inet.tcp.keepintvl=30000
:net.inet.tcp.msl=5000
:net.inet.tcp.always_keepalive=1 (default)
:
:
:I believe keep idle was defaulted to 2hrs, I changed it to 15 minutes
:with a 30 second tick... I still found FIN_WAIT_1 sessions stuck for
:several hours, if not infinite.
:
:Nonet he less, I have a new server up running 7.0-p1, I'll be pumping
:a lot of traffic to that box soon and I'll see how that makes out.
:
:--
:Robert Blayzor, BOFH
:INOC, LLC
:[EMAIL PROTECTED]
:http://www.inoc.net/~rblayzor/
If it is still giving you trouble I recommend using tcpdump to observe
the IP/port pair of one of the stuck connections over the keepalive
period and see if the keepalives are still being sent and, if they are,
what kind of response you get from the other end.
It is quite possible that the other ends of the connection are still
live and that the issue could very well be a timeout setting in the
server config file instead of something in the TCP stack.
This is what you should see when a keepalive occurs over an idle
connection:
* A TCP packet w/ 0 data sent to the remote
* A response from the remote: Either a pure ACK, or a TCP RESET
If no response occurs from the remote the keepalive code will then
retry a couple of times over keepintvl (every 30 seconds in your case),
and if it still gets no response after I think 3 retries (30+30+30 = 90
seconds later) it should terminate the connection state.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
