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を待っていることを意味します。 。

何かできることはありますか？

関連プロセスの再起動は最後の手段であることに注意してください。

カーネルタイムアウトは、接続が孤立している場合にのみ適用されます。接続がまだソケットに接続されている場合、そのソケットを所有するプログラムが接続のシャットダウンのタイムアウトを担当します。おそらく呼び出してshutdownおり、接続が正常にシャットダウンするのを待っています。シャットダウンが完了するまで、アプリケーションは待機することができます。

典型的なクリーンシャットダウンフローは次のようになります。

1. アプリケーションは、接続をシャットダウンすることを決定し、接続の書き込み側をシャットダウンします。

2. アプリケーションは、相手側が接続の半分をシャットダウンするのを待ちます。

3. アプリケーションは、接続の相手側のシャットダウンを検出し、そのソケットを閉じます。

アプリケーションは、好きなだけステップ2で待機できます。

アプリケーションにはタイムアウトが必要なようです。接続をシャットダウンすることを決定したら、ある程度の時間の後、相手側がクリーンシャットダウンを行うのを待つのをshouldめます。

ソケットがshutdown（）で、まだclose（）ではない場合、ソケットはFIN_WAIT2状態のままになります。また、アプリケーションはまだファイル記述子を所有しているため、カーネルは面倒なことはしません。