web-dev-qa-db-ja.com

/ proc / $ PID / fd /のシンボリックリンクがハードリンクとして機能するのはなぜですか？

シンボリックリンクのターゲットが削除されると、それは何も指さず、削除されたターゲットのコンテンツに到達する方法がありません。

/proc/$PID/fd/内のファイルはシンボリックリンクとして表示されますが、ここで説明するように、削除されたターゲットのコンテンツにアクセスできます。 削除されたLinuxファイルをlsof 。

それはどのように機能しますか？シンボリックリンクとして機能しないのに、なぜシンボリックリンクとして表示されるのですか？ファイルのiノードへの参照を保持するのはprocファイルシステムのシンボリックリンク実装ですか？

linuxsymbolic-linkproc
6
user300811

ターゲットが削除された場合、ls(1)またはfile(1)を使用すると、_/proc/$PID/fd/_内のエンティティは壊れたシンボリックリンクとして表示されますが、open(2)。

Debian 9では、strace(1)を使用して、シンボリックリンクを読み取ろうとするとどうなるかを確認しました。コマンドは_Sudo strace cat "$symlink"_です。 stderrからの関連行は

  • どちらかOK

    _open("$symlink", O_RDONLY)                   = 3
_

  • またはENOENT

    _open("$symlink", O_RDONLY)                   = -1 ENOENT (No such file or directory)
_

（注：これらがすべてopen(2)の一般的な結果であると言っているわけではありません）。

結果：

_               | regular symlink | /proc/$PID/fd/$N |
---------------+-----------------+------------------+
exists, valid  |       OK        |        OK        |
exists, broken |     ENOENT      |        OK        | <- the difference
doesn't exist  |     ENOENT      |      ENOENT      |
---------------+-----------------+------------------+
_

また、_file "$symlink"_を実行すると、lstat(2)、readlink(2)、およびstat(2)が呼び出されることも学びました。これらは、ファイル記述子ではなく、パスに基づくシステムコールです。シンボリックリンクが存在する場合（有効または破損）、open(2)が呼び出されてシンボリックリンクまたはそのターゲットが開かれることはありません。 stat(2)のENOENTは、リンクが壊れていることを示します。

私の結論は次のとおりです。「リンク切れ」は、いくつかのシステムコールの出力から派生したプロパティです。しかし、_/proc/$PID/fd/_からリンクを開くと、open(2)はそれをどう処理するかを知っているだけで、他のツールが何を生成するかは気にしません。

_/proc_全体が「通常の」ファイルシステムのみを偽造していることに注意してください。いくつかの癖：

  • ファイルには動的コンテンツが含まれている可能性がありますが、システムコールで変更されていません（inotifywaitを試してください）。
  • オブジェクトは（消えて）表示される場合がありますが、システムコールで作成または削除されていません（ここでもinotifywait）。
  • ある意味では、オブジェクトを操作するまでオブジェクトは存在しない可能性があります。 bashを実行し、数分待ちます。 _ls -l /proc/$$/fd_を呼び出して、ファイル記述子を確認します。おそらくctimesは「この瞬間」を表示します。ただし、コマンドを数秒ごとに繰り返すと、ctimesが変更されないことがわかります。 （雑学クイズ：最初はこの質問に答えることができましたが ファイルが開いている時間を確認してください with statと_/proc/$PID/fd/_のシンボリックリンクですが、私は間違っていました。理由がわかりました）。

あなたが尋ねるこれらのシンボリックリンクが、状況によっては通常のシンボリックリンクのように動作しないのも不思議ではありません。 _/proc_全体は、動作が多少異なるように設計されています。 open(2)は意図的にそれを利用する能力を与えられたと思います。

3
Kamil Maciorowski