小编Ada*_*nek的帖子

我有一个叫长寿命过程中的问题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 bug-tracker报告了一个问题，但我想了解为什么 Linux 内核没有关闭此类连接。

根据其文档（搜索 tcp_fin_timeout），处于 FIN_WAIT2 状态的连接应该在 X 秒后被内核关闭，其中 X 可以从 /proc 读取。在我的机器上它设置为 60：

$ cat /proc/sys/net/ipv4/tcp_fin_timeout
60

所以如果我理解正确的话，这样的连接应该在 60 秒后关闭。但事实并非如此，他们在这种状态下停留了几个小时。

虽然我也明白 FIN_WAIT2 连接非常不寻常（这意味着主机正在等待来自连接远程端的一些 ACK，但它可能已经消失了）我不明白为什么这些连接没有被系统“关闭” .

有什么我可以做的吗？

请注意，重新启动相关进程是最后的手段。