2
LinuxカーネルによってFIN_WAIT2状態の接続が閉じられないのはなぜですか?
Kubernetesの一部であるkube-proxyと呼ばれる長命のプロセスに問題があります。 問題は、時々接続が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秒後にカーネルによって閉じられるはずです。Xは/ procから読み取ることができます。私のマシンでは、60に設定されています。 $ cat /proc/sys/net/ipv4/tcp_fin_timeout 60 正しく理解できれば、そのような接続は60秒で閉じられるはずです。しかし、これはそうではありません、彼らは何時間もそのような状態のままになります。 また、FIN_WAIT2接続は非常に珍しいことも理解していますが(これは、ホストが接続のリモートエンドからのACKを待っていることを意味します。 。 何かできることはありますか? 関連プロセスの再起動は最後の手段であることに注意してください。