☰

CLOSE_WAIT状態から分離された接続

tag-icon • tag-icon linux networking tcp
CLOSE_WAIT状態から分離された接続

CLOSE_WAIT状態でTCP接続を累積し、決して発生しないSLESシステムがあります。これらの記述子は、最終的に利用可能なすべてのメモリを消費します。現在3037がありますが、最近急激に再起動する前は、その数がはるかに多かったです。

興味深いことに、これらの信号は、リスニングプロセスが予想されるローカルポートへの接続では発生しません。関連付けられたPIDがなく、タイマーが期限切れになっているようです。

# netstat -ton | grep CLOSE_WAIT
tcp      176      0 10.0.0.60:54882     10.0.0.12:31663      CLOSE_WAIT  off (0.00/0/0)
tcp       54      0 10.0.0.60:60957     10.0.0.12:4503       CLOSE_WAIT  off (0.00/0/0)
tcp       89      0 10.0.0.60:50959     10.0.0.12:3518       CLOSE_WAIT  off (0.00/0/0)

# netstat -tonp | grep CLOSE_WAIT
tcp       89      0 10.0.0.59:45598     10.0.0.12:1998       CLOSE_WAIT  -                   
tcp       15      0 10.0.0.59:60861     10.0.0.12:1938       CLOSE_WAIT  -                   
tcp        5      0 10.0.0.59:56173     10.0.0.12:1700       CLOSE_WAIT  -

私はTCPスタックやカーネルネットワーキングに関してはブラックベルトではありませんが、マニュアルページによると、次の値がデフォルトであるため、TCP設定は問題ありません。

# cat /proc/sys/net/ipv4/tcp_fin_timeout 
60
# cat /proc/sys/net/ipv4/tcp_keepalive_time 
7200

それでは何が与えられますか？タイマーが期限切れになると、スタックはこれらの項目を自動的に消去する必要はありませんか？このようなことが積み重なり、実際には長期間のサービス拒否を経験しました。

答え1

いいえ、タイムアウトはありませんCLOSE_WAIT。私はこれがoffあなたの結果が意味するものだと思います。

を終了するには、CLOSE_WAITアプリケーションが明示的にソケットを閉じるか終了する必要があります。

バラよりCLOSE_WAITを中断する方法。

netstatプロセスバーに表示されている場合：-

  • 適切な権限と機能（rootなど）を使用して実行していますか？
  • カーネルプロセス（たとえば、nfsd）です。

答え2

CLOSE_WAITクライアントが接続を閉じていても、アプリケーションが接続を閉じていないか、クライアントがまだ閉じていないことを示します。どのプログラムにこの問題があるかを確認する必要があります。試してみてください

netstat -tonp 2>&1 | grep CLOSE

どのプログラムが接続されているかを確認します。

プログラムがリストされていない場合、サービスはカーネルで提供されます。これはnfs、またはなどのRPCサービスですrpc.lockd。リスニングカーネルサービスを一覧表示できます。

netstat -lntp 2>&1 | grep -- -

RPC サービスが固定ポートにバインドされていない場合は、接続に表示される一時ポートにバインドされます。他のサーバーのプロセスとインストールを確認することもできます。

次の手順を実行して、NFSサービスを固定ポートにバインドできます。

  1. 未使用のNFSポート4つを選択します（ここでは32763-32766が使用されています）。
  2. NFS用の固定ポートの追加/etc/services 
    rpc.statd-bc 32763/udp # RCP statd ブロードキャスト
rpc.statd-bc 32763/tcp
rpc.statd 32764/udp # RCP statd モニタリング
rpc.statd 32764/tcp
rpc.mountd 32765/udp # RPC マウント
rpc.mountd 32765/tcp
rpc.lockd 32766/udp # RPC ロック/nlockmgr
rpc.lockd 32766/tcp
  3. オプションを使用するように statd を構成する--port 32763 --outgoing-port 32764
  4. このオプションを使用するには、rpcmountdを設定してください。--port 32765
  5. NFSおよびRPCサービスを終了して再起動します。

答え3

しかし、ミケルの答えNFSなどのカーネル側のソケットがこの問題を引き起こす可能性があることも事実かもしれません。CLOSE_WAIT -関連するFDを持たない項目がより一般的です。

listen()ローカルキューにある間、相手は以前に閉じた接続をaccept()呼び出すことができます。私の詳細な回答と再現はここにあります。

CLOSE_WAIT状態では永遠に続くようです。

彼らはあなたが出てくるまで永遠にその状態になります

  • accept()その後close()、それら、または
  • close()ソケット全体（解決策ではない可能性があります）

この記事にも詳しく説明されていますリンク回答。

これらの記述子は、最終的に利用可能なすべてのメモリを消費します。

man 2 listenキューの長さは次のようにlisten()制限されているため、これは発生しないでください。

/proc/sys/net/ipv4/tcp_max_syn_backlog  # default 4096
/proc/sys/net/core/somaxconn            # default 4096

もちろん、複数のソケットがある場合を除いて、listen()上記の制限は各ソケットに対するものです。

関連情報