web-dev-qa-db-ja.com

/ proc / <pid> / 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リンクはどのように機能しますか？

linuxsymlinkproc
24
muru

/proc/<pid>/exeは、シンボリックリンクの通常のセマンティクスに従いません。技術的には、これはPOSIXの違反としてカウントされる可能性がありますが、/procは結局のところ特別なファイルシステムです。

/proc/<pid>/exeをstatすると、シンボリックリンクのように見えます。これは、カーネルがプロセスの実行可能ファイルについて知っているパス名をエクスポートするための便利な方法です。しかし、実際にその「ファイル」を開いた場合、シンボリックリンクの内容を読み取る通常の手順はありません。代わりに、カーネルは開いているファイルのエントリに直接アクセスできるようにします。

ls -l a /proc/<pid>/exe実行可能ファイルが削除されたプロセスの疑似ファイルのシンボリックリンクターゲットの末尾には、文字列「（削除済み）」があります。これは通常、シンボリックリンクでは意味がありません。「（削除済み）」で終わる名前のターゲットパスに存在するファイルは絶対にありません。

tl; drprocファイルシステムの実装は、パス名解決で独自の魔法のことを行います。

21
Celada

/ procのmanページによると、Linux 2.2以降では、ファイルは実行されたコマンドの実際のパス名を含むシンボリックリンクです。どうやら、バイナリはメモリにロードされ、/proc/[pid]/exeは、バイナリの内容を指しますメモリ内。

一方、Linux 2.0以前では、/proc/[pid]/exeは、実行されたfile（ファイルシステム内）へのポインタです。

したがって、Linux 2.0以前で同じコマンドリストを実行した場合、おそらく「そのようなファイルまたはディレクトリはありません」というエラーが発生します。

4
dr_