2
为什么Linux内核没有关闭FIN_WAIT2状态的连接?
我有一个叫长寿命过程中的问题KUBE-代理的存在部分Kubernetes。 问题是,连接有时不处于FIN_WAIT2状态。 $ sudo netstat -tpn | grep FIN_WAIT2 tcp6 0 0 10.244.0.1:33132 10.244.0.35:48936 FIN_WAIT2 14125/kube-proxy tcp6 0 0 10.244.0.1:48340 10.244.0.35:56339 FIN_WAIT2 14125/kube-proxy tcp6 0 0 10.244.0.1:52619 10.244.0.35:57859 FIN_WAIT2 14125/kube-proxy tcp6 0 0 10.244.0.1:33132 10.244.0.50:36466 FIN_WAIT2 14125/kube-proxy 这些连接会随着时间的推移而堆积,从而导致过程异常。我已经向Kubernetes错误跟踪器报告了一个问题,但是我想了解为什么Linux内核没有关闭这种连接。 根据其文档(搜索tcp_fin_timeout),处于FIN_WAIT2状态的连接应在X秒钟后由内核关闭,其中可以从/ proc读取X。在我的机器上,它设置为60: $ cat /proc/sys/net/ipv4/tcp_fin_timeout 60 因此,如果我理解正确,则此类连接应在60秒内关闭。但是事实并非如此,它们会处于这种状态数小时。 虽然我也知道FIN_WAIT2连接是非常不寻常的(这意味着主机正在等待连接的远程端可能已经消失的ACK),但我不明白为什么这些连接不会被系统“关闭” 。 有什么我可以做的吗? 请注意,重启相关过程是万不得已的方法。