☰

プロセスはどのファイルシステムにも存在しない inode を開きましたか?

tag-icon • tag-icon solaris process inode
プロセスはどのファイルシステムにも存在しない inode を開きましたか?

そこで、プロセスが通常とは異なる場所にリダイレクトされているかどうかを調べようとしていますstderr(これは Java プロセスであり、スレッド ダンプが必要なのですが、起動スクリプトのネストを介して起動されています)。

私は を使って自分のプロセスを見つけpgrep、 を使用してpfilesそこに何があるかを確認します。

4366: /foo/bar/platform/solaris2/jre_1.5.0/bin/java -Xmx2048m -Xms10
現在の rlimit: 65536 ファイル記述子
 0: S_IFCHR モード:0666 dev:302,0 ino:6815752 uid:0 gid:3 rdev:13,2
    O_RDONLY|O_LARGEFILE
    /デバイス/疑似/mm@0:null
 1: S_IFREG モード:0640 dev:85,56 ino:26471 uid:0 gid:0 サイズ:10485812
    O_WRONLY|O_LARGEFILE
 2: S_IFREG モード:0640 dev:85,56 ino:26471 uid:0 gid:0 サイズ:10485812
    O_WRONLY|O_LARGEFILE
 3: S_IFCHR モード:0666 dev:302,0 ino:6815772 uid:0 gid:3 rdev:13,12

stdoutつまり、stderr(ファイル記述子 1 と 2) が同じ場所を指していることがわかります。これらは起動スクリプトで同じファイルにリダイレクトされていると思うので、一致しています。

しかし、inode 番号 26471 のファイルを検索すると、次のようになります。

# 検索 / -inum 26471
/usr/share/man/man3mlib/mlib_MatrixScale_S16_U8_Sat.3mlib
4366 の fd は 1 です。
4366 の fd は 2 です。
4366 の fd は 83 です。

最初のヒットは (私は確信していますが) 別のファイルシステム上のファイルです。 の 3 つのエントリは、/proc私のプロセスが開いている fd です。

を覗いてみると/proc/4366、 から得られる情報以上のものは見つかりませんpfiles。

# ls -li 0 1 2 3
   6815752 c--------- 1 ルート sys 13, 2 1月 20 14:10 0
     26471 --w------- 0 ルート ルート 10485812 1月20日 13:42 1
     26471 --w------- 0 ルート ルート 10485812 1月20日 13:42 2
   6815772 c--------- 1 ルート sys 13, 12 2009年6月7日 3
# ファイル 0 1 2 3
0: キャラクタースペシャル (13/2)
1: ASCIIテキスト
2: ASCIIテキスト
3: キャラクタースペシャル (13/12)

(これらの fd の 1 つを tail して、どのファイルがそのファイルであるかを判別できます。fd と inode の関係を十分に深く理解していないため、質問しています)。

私のプロセスは、何か(あるデバイスで、inode 26471 を使用)、その後、データは別の inode 番号を持つファイルに格納されます。この何かが何なのか、誰か教えてくれませんか (または、これまでの私の推論が完全に間違っているかどうかも教えてください)?

答え1

私の知る限り、findファイルシステムのディレクトリを検索します。そのファイルが削除されたが、開いているためにまだ存在している場合 (UNIX では一般的なトリック)、 では見つかりませんfind。

Solarisでは試していませんが、ここ削除されたが開いているファイルをlsof識別し、cat /proc/<procid>/fd/<fdid> > /tmp/xxxx

編集:

すでにこのことが事実であると認識されているようですが、それがどのように可能なのかまだ疑問に思われます。以下に簡単な説明を示します。

POSIX ファイルシステムでは、ファイルは によって処理されinode、ディレクトリは「パス => inode」マッピングにすぎません。同じ inode を指すパスを複数持つことができ (ハードリンクと呼ばれます)、inode はリンクの数を保持します。コマンドはrm単にこのパスを呼び出すだけでunlink()、リンク数を減らし、ファイル自体を削除する可能性があります。

しかし、ディレクトリ ツリー上のパスは、inode への唯一の可能な参照ではなく、fd実行中のプロセスでのオープンもカウントされ、「削除された」ファイルは 0 になるまで実際には削除されません。

上でも触れましたが、これはよくあるトリックです。プロセスの実行が終了した後に保持する必要のない一時ファイルがある場合は、それを開いてすぐに「削除」します。開いたハンドルは確実に機能し、プロセスが終了すると (正常終了、強制終了、またはクラッシュ)、システムはハンドルを削除し、一時ファイルをきれいに削除します。

ログファイルは、このような「隠れた自動削除」ファイルの候補にはなり得ませんが、誤って削除してしまう可能性は低くありません。

削除されたログファイルはまだ有効でデータを収集しているので、単に内容をコピーするだけではあまり役に立たないようです。そのため、 のような /proc//fd/ ファイルへの新しいハードリンクを作成してみてくださいln /proc/4366/fd/1 /tmp/xxxx。フラグがないため-s、lnシンボリック リンク (既存のパスへのポインターにすぎず、必要なものではありません) ではなく、元のファイルと同じ inode を持つ新しいハードリンクを作成する必要があることに注意してください。

編集:

/proc と /tmp が異なるファイルシステムにあるため、コマンドln /proc/... /tmp/...は機能しません。残念ながら、既存の inode のパス名を作成する方法がわかりません。syscall がlink()inode 番号とパスを取得することを望むのですが、ソース パスと宛先パスも取得します。

関連情報