問題タブ [lsof]

Linux で PID 25426 の Java アプリケーションを実行していますlsof -p 25426。

この結果はどのように解釈されるべきですか？

開いているファイルが多すぎる問題のトラブルシューティングを行っており、この観察結果が関連しているかどうかを理解しようとしています。

アプリケーションの実行が続くと、pipeエントリの数が変化します (上下します)。

次のコマンドを使用して、ファイル記述子が開いているかどうかを確認します。

そうでない場合は、いくつかのアクションを実行します。ファイルは からスプールされたログsqlplusです。

ファイル記述子が開かれていないことが時々lsofわかりますが、このファイルに新しいデータがいくつか見つかります。めったに発生しないので、再現できません。

1. その理由は何ですか？
2. SQLスプールはどのように機能しますか? SPOOLファイルコマンドからSPOOL OFFコマンドまでファイル記述子を開いたままにしますか、それともファイル記述子を数回開いて閉じますか?

lsof 出力を介して開かれたすべてのファイルを一覧表示するスクリプトを作成中です。特定のファイルをチェックサムし、その出力からディレクトリを無視したいのですが、効果的にそうすることができません。例：（私はFreeBSDを使用しています）

プリント:

私がやりたいことは次のとおりです。その出力から、ディレクトリを無視し、ファイル（ディレクトリではない）でmd5を実行します。

ポインタはありますか？

この質問は、 「ネットワーク ポートが開いていますが、プロセスが接続されていませんか?」に似ています。netstat は pid のないリッスン ポートを表示しますが、lsof は表示しません。しかし、それらへの答えは私のものを解決することはできません。

lpsポート 8588 で tcp 接続を待機するというサーバー アプリケーションがあります。

ご覧のとおり、リッスン ソケットに問題はありませんが、2000、3000、または 4000 の数千のテスト クライアント (別の同僚によって作成された) をサーバーに接続すると、常に 5 つのクライアントがありました (これもランダム) に接続してログイン要求をサーバーに送信しますが、応答を受信できません。例として 3000 クライアントを取り上げます。これはnetstatコマンドが与えるものです：

そして、これはlsofコマンド出力です:

その 5 つの接続がここにあります。

上記の 5 は、ポート 8588 でサーバーに接続されているが、プログラムが接続されていないことを示しています。2 番目の列 ( RECV-Q) は、クライアントが要求を送信するにつれて増加し続けます。

上記のリンクは、NFS マウントと RPC について述べています。RPCに関しては、コマンドを使用しましたrcpinfo -pが、結果はポート8588とは何の関係もありません。そして、NFSマウント、nfssta出力は言うError: No Client Stats (/proc/net/rpc/nfs: No such file or directory).

質問 : これはどのように起こりますか? 常に 5 であり、同じ 5 クライアントからではありません。他のクライアントも同じサーバーIPとポートに接続されており、それらはすべてサーバーによって適切に処理されるため、ポートの競合ではないと思います。

注:epollクライアントの要求を受け入れるために Linux を使用しています。acceptまた、プログラムにデバッグ コードを記述し、返されたが 5 つの接続が見つからないすべてのソケットを (クライアントの情報と共に) 記録します。これはuname -a出力です：

ご親切にありがとうございました! 私は本当に混乱しています。

2013 年 6 月 8 日更新: システムを CentOS 6.4 にアップグレードした後、同じ問題が発生します。最後に に戻ったところlisten fd をノンブロッキングに設定し、エラーが返るまでと書かれているページepollを見つけましそして、はい、それは動作します。保留中の接続はこれ以上ありません。しかし、それはなぜですか？Unix Network Programming Volume 1は言うacceptEAGAINEWOULDBLOCK

では、完了した接続がまだキューにある場合、プロセスがスリープ状態になるのはなぜでしょうか?

更新2013-7-1: リッスン ソケットを追加するときに使用遭遇するEPOLLETまで受け入れを維持しないと、すべてを受け入れることができませんEAGAIN私はちょうどこの問題に気づきました。私のせいです。覚えておいてください:ソケットをリッスンしている場合でも、alwaysreadまたはacceptuntilEAGAINが出てきEPOLLETテスト プログラムで私を証明してくれた Matthew に再び感謝します。

ファイル記述子に設定されたソケット オプションを見つける必要があります。

たとえば、accept 呼び出しは FD を返します。いくつかのソケット オプションを設定しました。次に、ソケット オプションが実際に FD に設定されているかどうかを確認する必要があります。

PS: setsockopt はエラーを返しませんが、fd の動作はオプションと一致していません。したがって、これを確認する必要があります。