close() 後に fd が消えると予想したため閉じられていないようですが、壊れたシンボリックリンクがある fd -> ソケット [xxxxx] 項目が多く残っており、より速くないようです。この状態の原因は何ですか?
答え1
シンボリックリンクターゲットのテキストは、ファイルを参照せず、/proc/net/tcp
各ソケットを記述するためにエンコードされたテキストフィールドを使用するテーブル内のエントリを参照します。たとえば、私のシステムには以下が表示されます。
$ ls -l /proc/24724/fd/7
lrwx------ 1 vagrant vagrant 64 Feb 13 15:08 /proc/24724/fd/7 -> socket:[19164451]
tcp
テーブルの次の行に対応します。
$ grep 19164451 /proc/net/tcp
433: 0100007F:C8AA 0100007F:0C8A 01 00000000:00000000 02:00000286 00000000 1000 0 19164451 2 0000000000000000 20 4 1 10 27
クイック Google 検索では、これらの行を復号化するために必要な多くのリソースを見つけることができます。 2つの例:
http://www.onlamp.com/pub/a/linux/2000/11/16/LinuxAdmin.html https://stackoverflow.com/questions/5992211/list-of-possible-internal-socket-statuses-from-proc
これを処理するツールが必要な場合は、どのプロセスがどのソケットに属しているかを知るためにすべてのリンクを読み取るように指示するオプションを使用するnetstat
ことができます。努力する:-p
/proc
fd
netstat -tuapn
答え2
ソケット[xxxxx]シンボリックリンクは常に切断されます。指定された inode 番号でソケットを開くためのアクセス可能なパスはありません。
試してみましたが、/proc/pidX/fd/Y
ソケットを参照するファイルを開くことができないようです。ただし、物理ファイルを参照している場合は、そのファイルが削除された場合でもこれを行うことができます。厳密に言えば、シンボリックリンクではありません。それは魔法です。つまり、特別な状況です。