TCP接続がCLOSE_WAIT状態になり、永久に見えるように接続を蓄積する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 configはこれらの値がデフォルトであるため、正気のようです、マニュアルページごとに:
# cat /proc/sys/net/ipv4/tcp_fin_timeout
60
# cat /proc/sys/net/ipv4/tcp_keepalive_time
7200
だから何を与えるのですか?タイマーが時間切れになった場合、スタックはこの内容を自動的にクリアすべきではありませんか?これらが蓄積するにつれて、長期的なDoSを効果的に行っています。
いいえ、CLOSE_WAIT
のタイムアウトはありません。出力でoff
が意味するところだと思います。
CLOSE_WAIT
から抜け出すには、アプリケーションが明示的にソケットを閉じる(または終了する)必要があります。
CLOSE_WAITを解除する方法 を参照してください。
netstat
がプロセス列に-
を表示している場合:
CLOSE_WAIT
は、クライアントが接続を閉じているが、アプリケーションがまだ接続を閉じていないか、クライアントが閉じていないことを示します。この問題が発生しているプログラムを特定する必要があります。使ってみてください
netstat -tonp 2>&1 | grep CLOSE
接続を保持しているプログラムを判別します。
プログラムがリストされていない場合、サービスはカーネルによって提供されています。これらは、nfs
やrpc.lockd
などのRPCサービスである可能性があります。リスニングカーネルサービスは、
netstat -lntp 2>&1 | grep -- -
RPCサービスが固定ポートにバインドされていない限り、接続が表示されているように見えるため、それらは一時ポートにバインドされます。他のサーバーのプロセスとマウントを確認することもできます。
次の操作を行うと、NFSサービスを固定ポートにバインドできる場合があります。
/etc/services
に追加しますrpc.statd-bc 32763/udp#RCP statd broadcast rpc.statd-bc 32763/tcp rpc.statd 32764/udp#RCP statd listen rpc.statd 32764/tcp rpc.mountd 32765/udp#RPC mountd rpc.mountd 32765/tcp rpc.lockd 32766/udp#RPC lockd/nlockmgr rpc.lockd 32766/tcp
--port 32763 --outgoing-port 32764
--port 32765
を使用するようにrpcmountdを構成します