/proc/ どのように/exeシンボリックリンクは通常のシンボリックリンクとどう違いますか?

/proc/ どのように/exeシンボリックリンクは通常のシンボリックリンクとどう違いますか?

プロセスを開始してからそのバイナリを削除しても、以下から復元できます/proc/<pid>/exe

$ cp `which sleep` .
$ ./sleep 10m &
[1] 13728
$ rm sleep
$ readlink /proc/13728/exe                           
/tmp/sleep (deleted)
$ cp /proc/13728/exe ./sleep-copy
$ diff sleep-copy `which sleep` && echo not different
not different
$ stat /proc/13728/exe 
  File: ‘/proc/13728/exe’ -> ‘/tmp/sleep (deleted)’
  Size: 0           Blocks: 0          IO Block: 1024   symbolic link

一方、私が直接シンボリックリンクを作成している場合は、ターゲットを削除してコピーしてみてください。

cp: cannot stat ‘sleep’: No such file or directory

/procカーネルのインタフェースです。それでは、このシンボリックリンクは実際にメモリにロードされたコピーを指していますが、より有用な名前を持っていますか?このリンクは正確にどのようにexe機能しますか?

ベストアンサー1

/proc/<pid>/exeシンボリックリンクの一般的な意味に従わない。技術的にはこれはPOSIX違反と見なすことができますが、/proc最終的には特別なファイルシステムです。

/proc/<pid>/exe使用するとシンボリックリンクのように見えますstat。これは、カーネルが知っているプロセス実行可能ファイルのパス名をエクスポートする便利な方法です。しかし、実際にその「ファイル」を開くと、シンボリックリンクの下の内容を読む一般的なプロセスはありません。代わりに、カーネルは開いているファイルエントリへの直接アクセスのみを提供します。

ls -l実行可能ファイルが削除されたプロセスのダミーファイルを生成すると、/proc/<pid>/exeシンボリックリンクターゲットの末尾に「(削除済み)」という文字列があります。これは通常、シンボリックリンクでは意味がありません。名前が「(削除済み)」で終わるファイルは、確実に宛先パスには存在しません。

長すぎます。ファイルシステムのproc実装は、パス名解決を通じて独自の魔法を実行します。

おすすめ記事