問題タブ [lsof]

libstdc++ を使用していることがわかっているアプリケーションがありますが、スーパー ユーザーであっても、Mac OS X 10.6 Snow Leopard システムで /usr/lib/libstdc++.6.0.9.dylib が表示されません。

lsof | grep libstdc++

DYLD_LIBRARY_PATH を使用して libstdc++ の独自のコピーを使用すると、アプリの実行中にフル パスに表示されます。

これは実りのないグーグル検索の後です。Linux システムでは、すべてのユーザーが /usr/lib でライブラリを使用しているアプリケーションを確認できます。

私の結果が奇妙な出来事に遭遇しました

生産

一般的に私は見る

矢印の両側でポートが一致しない場合。lsofが前者の結果を生成している間、ソケットがSO_REUSEADDRとして構成されていても、ポート40006でリッスンしようとするアプリケーションを起動できませんでした。

これは起こり得ますか？それが必要ですか？

unameが与える：Linux femputer 2.6.32-24-サーバー＃39-Ubuntu SMP Wed Jul 28 06:21:40 UTC 2010 x86_64 GNU / Linux

c++を使用して、開いているすべてのソケットを取得する方法はありますか? 私はlsofコマンドを知っていて、これは私が探しているものですが、C++アプリケーションでどのように使用するのですか?

アイデアは、開いているソケットの FD をそのport番号とpid.

lsof|wc -l を使用して、crontab で開いているファイルの数を定期的に取得しようとしています。常にゼロを返します。直接実行すると正しい結果が得られます.この奇妙な動作について何か考えはありますか?結果が非常に大きくなる可能性があるため、パイプのサイズに関連していますか?どうもありがとう.

カカ

私はperlワーカーサブプロセスを備えた長時間実行のPythonスクリプトを持っています。データは、stdinおよびstdoutを介して子プロシージャに送受信されます。定期的に、子を再起動する必要があります。

残念ながら、しばらく実行すると、ファイルが不足します（「開いているファイルが多すぎます」）。lsofは、多くの開いているパイプを示しています。

Popenされたプロセスの後にクリーンアップする適切な方法は何ですか？これが私が今していることです：

ファイルをアーカイブするスクリプトまたはコードを作成しようとしていますが、現在開いているものはアーカイブしたくありません。ディレクトリ内のどのファイルが開いているかを判断する方法を見つける必要があります。Perl またはシェル スクリプトのいずれかを使用したいのですが、必要に応じて他の言語を使用することもできます。Linux 環境にあり、lsof を使用するオプションはありません。また、フューザーで一貫性のない結果が得られました。助けてくれてありがとう。

ディレクトリ内のログ ファイルを別のディレクトリに移動しようとしています。ただし、ファイルが開いている場合は、何もしたくありません。

私がする時

ある端末で実行してから別の端末で実行する

lsofコマンドの実行からo/pがリストされているのがわかります。

しかし、私がするとき

同じ端末で（findとして）実行し、（別の端末で）実行します

lsofコマンドから出力が得られません

なんで ？読み取りがbashに組み込まれているためですか？ここで何が起こっているのですか？

lsofはUnixの優れたツールであり、現在開いているすべてのファイルハンドルを表示します。

実行中のJVM内で開いているすべてのファイルを（JVMTIまたは同様のインターフェイスを介して）表示する同様のツールを知っている人はいますか？

この特定のケースでは、どのクラスがハンドルを開いているかを知るだけで十分です。メソッド/ラインまたはGCルートへのチェーン全体でさえ素晴らしいでしょうが、ハンドラー所有者クラスはすでに良いスタートです。

ヒープダンプを作成し、プロファイラーで開いてこれを見つけることができることはわかっていますが、これは、特に大きなヒープの場合、面倒な作業です。

ソケットの状態を確認するために「lsof -nl | egrep "TCP|UDP"」を実行すると、一覧に表示されるはずのソケットがまったく表示されないことに気付きますが、「netstat --tcp」を実行すると、それらはリストされていますが、CLOSE_WAIT 状態にあります。

私がこれまでに知っていることは、CLOSE_WAIT 状態は、アプリケーションがこのソケットを明示的に閉じる責任があることを示しているということです (ただし、追跡しようとしているバグがあり、このソケットが CLOSE_WAIT 状態のままになっています)。ソケットが存在する場合、それに関連付けられた開いているファイル記述子が必要であると考えたので、lsof の出力でそれが表示されることを期待していました。なぜそこに見えなかったのですか？

ありがとう、サンドラ

Java プロセス/アプリがあります。その Java プロセスで /usr/sbin/lsof -p を実行すると、多くの「プロトコルを識別できません」と表示されます。また、興味深いことに、ファイル記述子 (FD) は非常に安定した速度で増加しています。そして、作成中の FD には「プロトコルを識別できません」という記述があります。

それで、誰が多くのFDを作成しているかを突き止めるために、Javaプロセスを計測/プロファイルする方法はありますか。ツールに関する詳細な説明は、本当に役に立ちます。

Google で簡単に検索すると、strace は 1 つの方法ですが、IIUC では Java プロセスからの Linux システム コールが表示されます。どのシステム コールが生成されているかよりも、Java コードのどの部分の動作が悪いかということに関心があります。

繰り返しますが、どんなアイデアや提案も、単に素晴らしいものになるでしょう!