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

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

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

あなたがいることに注意してください実行可能なプロセスのための疑似ファイルはそれの終わりに「（削除）」シンボリックリンクのターゲットは、文字列を持って削除されています。これは通常、シンボリックリンクでは無意味です。「（deleted）」で終わる名前のターゲットパスに存在するファイルは絶対にありません。ls -l/proc/<pid>/exe

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

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

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

したがって、Linux 2.0以前で同じコマンドのリストを実行した場合、「no such file or directory」というエラーが表示されると思われます。