問題タブ [lsof]

ポート 7054 で Python SimpleHTTPServer を起動しようとしました:

そのため、次のコマンドを実行しました。

しかし、私には結果がありません。

Javaで現在開いているファイル記述子をリストする方法と、開いているファイル記述子の数の制限を知っている人はいますか?

これまでに見つけた最高のものはhttps://gist.github.com/jtai/5408684です。これにより、Unix FD システムの最大値と現在開いている記述子の数を出力できます。ただし、実際に開いているファイルのパス/名前をリストする純粋なJavaの方法は見つかりませんでした。また、開いているファイル記述子の数に対するプロセスごとの制限をリストする純粋な Java の方法も見つかりませんでした。

私は主に Solaris とおそらく Linux プラットフォームに興味がありますが、純粋な Java は何かを実行するよりも優れています。pfiles (Solaris の場合)、lsof (Linux の場合)、および ulimit (両方の場合) を使用できることはわかっていますが、もっと良いものを探しています。

編集 1: 私は主に、現在のプロセス/jvm の開いている記述子の数と、その jvm の制限について心配しています。ただし、システム全体の統計と制限もプラスです。

ファイルは、fcntl (ノンブロッキング) またはカスタムの方法でロックされます。だから私はlsofを使って、プロセスのpidがそこにあるかどうかをチェックしています。lsof が空白を返す場合、何も使用していません。

ただし、スクリプトの lsof には 200 ミリ秒かかります。

Windowsでファイルがロックされているかどうかをテストしようとすると、ファイルを開くだけで、エラーが発生するとロックされます。これには5msかかります。何かがファイルを保持しているかどうかを確認するための簡単なテストを行うための lsof の代替手段はありますか?

mySQL のデータ ウェアハウスのサイズはほぼ 1.4 TB ですが、mysql サーバー デーモンがアクセスしているファイルの数を確認したところ、驚きました。

cmd ユーザー : lsof | grep mysql cnd2 使用: lsof | grep mysql | wc -l 2598 これを減らす方法を提案してください。mysql のパフォーマンスに与える影響は何ですか。

ファイルを削除 (ゴミ箱) する方法について当惑していますが、プロセスによってリンクされていて、まだ書き込まれています。私の理解では、ファイル名は i ノードを指すディレクトリ内のエントリです。inode は、ファイルを構成する論理ブロックをリストするデータ構造です。ファイルが削除されると、そのディレクトリ エントリは削除されますが、データと inode は変更されません。カーネルは i ノードへの他のリンクがあるかどうかを確認し、存在しない場合は i ノードが削除され、メモリが再利用されます。しかし、このような名前のないファイルはどのようにして作成されるのでしょうか? ファイルを開いてPythonで読み書きすると、ファイルはディスク上に存在します。しかし、Mac でこのコマンドを発行すると、次のようになります。

300個のファイルのリストを取得します! 私が読んだところによると、これらはリンクが 1 つしかないファイルであり、それらに書き込むプロセスへのリンクです。これらのファイルのディレクトリ エントリもある場合は、少なくとも 2 つのリンクがあります。では、途中のどこかで、これらのファイルに書き込んでいるプロセスがディレクトリ エントリを削除したのでしょうか。なんで？どのように？

こんにちは、再起動後にセッションを復元する osx の最新機能が恋しいので、Preview.app で開いている PDF ファイルを保存する bash スクリプトを作成し、最後の 2 つのスクリプトの間にある場合は、preview.app でそのファイルを再度開くかどうかを尋ねますシステムが再起動しました。

私はから始めます

lsof | grep '^Preview*pdf$' >> listpreview.txt

しかし、パスを分離するための適切な正規表現を特定できません。lsof によって返される典型的な行は次のとおり
です。

プレビュー 4581 My_user txt REG 14,2 3254550 36522430 /arbitrary_path/filename_with_all_sort_of_character_and_spaces.pdf

1. lsof より直接的な方法はありますか?
2. preview.app で使用される pdf ファイルのパスのリストを含む .txt ファイル (?) を保存するにはどうすればよいですか?
3. ß のようなあらゆる種類の記号をどのようにエスケープしてファイル/フォルダ名に含めることができますか (すべきではありません)?

ご回答有難うございます。

タイトルを簡潔にしようとしましたが、質問を完全にカプセル化する方法が思いつきませんでした。私がやりたいことは次のとおりです。perlスクリプトを実行するとき、同じSTDERRストリームに接続している「自分」以外のプロセスがあるかどうかを知りたいです（現在のttyで、または同じストリームに追加/リダイレクトされる可能性があります） STDERR ファイル) であり、そうであれば、私の目標は、私のSTDERR エラー/警告/詳細メッセージ、および他の同時実行プログラムからのその他のメッセージ。これが可能性として検出されたら、STDERR に出力するすべてのメッセージにスクリプト名を追加して、メッセージがどのプロセスから来たか (または少なくともどのプロセスが私が書いたスクリプトからのものか) をユーザーが認識できるようにします。現時点では、これをどのように達成するか、またはソリューションがすべての可能性をカプセル化するかどうかは気にしません-今のところ、適切なデフォルト動作の適切な数のユースケースをキャプチャする概念実証と呼びましょう. そして、システムコールを介してこれを実行しようとしています。

説明したいシナリオが 2 つあります。兄弟プロセスからのメッセージは、パイプ処理された一連のコマンドで同時に実行され、他の子プロセスからのメッセージは、同じ親スクリプトによって連続して実行されます。同じ STDERR ストリームのハンドルを使用してバックグラウンド プロセスのケースを処理しようとするつもりはありませんが、それらがキャプチャされた場合、それはおまけになります。

最初のシナリオである兄弟プロセスについては、かなりうまく処理できていると思います。を使用して、兄弟プロセスのすべての PID を取得できますpgrep -P $ppid。兄弟プロセスが単純に存在するだけで、スクリプト名をメッセージの先頭に追加することを保証するのに十分ですが、さらに一歩進んで lsof を使用して、それらの stderr が自分と同じ STDERR ストリームに送られているかどうかを確認することもできます。それらはバックグラウンドで実行されており、STDERR が同じ TTY に送信されます (ファイル記述子 '2' によって推測されます)。perl の -p または -t 関数を使用して一連のパイプ コマンドの一部であるかどうかを確認することもできます (ただし、'<' または ' >' であるため、-p または -t だけでは機能しません)。関係なく、

私が十分に理解していないシナリオは、親スクリプトによって制御されるプロセスを連続して実行することです。私の考えは、親プロセスが対話型シェルなのか、それともスクリプトなのかについて、合理的な推測を試みることです。

これを行う方法があるかどうかを調べるために、lsof を読んでみました。インタラクティブなシェル/ターミナルからのエラーは、スクリプトと同じ STDERR ストリームに出力されないのではないかと推測していましたが、どうやらそうであるようです。 2 つのシナリオを区別するための親。

さまざまなコンテキストでのテストに使用するワンライナーを作成しました。

2 つのコンテキストで実行しました。1 つはコマンド ラインで直接実行し、もう 1 つはシェル スクリプト内から実行しました。親の PID で実行された lsof で確認できた唯一の違いは、コマンド ラインで実行すると、tty への 5 つの読み取り/書き込み接続があり、シェル スクリプトから実行すると、tty への 3 つの接続があり、シェル スクリプトの 1 つの読み取り専用読み取り。いずれの場合も、0、1、または 2 のファイル記述子はありませんでした。

インタラクティブシェル:

内部シェルスクリプト:

私の質問は次のとおりです。親プロセスが対話型シェルであるかどうかを合理的に推測するのに十分な情報はありますか?

親プロセスがインタラクティブな端末セッションではないファイルからの親プロセスの通常の読み取り専用読み取りから合理的に推測できますか? または、tty への 5 つの読み取り/書き込み接続の存在から、親が対話型シェルであると推測できますか?

このアイデアを少しテストするためにsleep 1、ワンライナーの上の行に a を追加して、長いスクリプトの実行中のある時点でスクリプトの読み取りが lsof 出力から消えるかどうかを確認してみました。また、実行時にシェルスクリプトへのリダイレクトとシェルスクリプトからのリダイレクトを試みました。

私の使用例では、違いはわかりますが、他のシェルがどのように動作するかはわかりません。私は本当にシェルスクリプトについてのみ心配しています。誰かが他の何かの中から perl スクリプトを呼び出す合理的なシナリオは考えられません...