web-dev-qa-db-ja.com

`/ proc / self /`はどのプロセス用ですか？

https://www.centos.org/docs/5/html/5.2/Deployment_Guide/s3-proc-self.html は言う

/proc/self/ディレクトリは、現在実行中のプロセスへのリンクです。

常に複数のプロセスが同時に実行されているので、どのプロセスが「現在実行中のプロセス」ですか？

「現在実行中のプロセス」は、コンテキストの切り替えを考慮して、CPUで現在実行中のプロセスと何か関係がありますか？

「現在実行中のプロセス」は、フォアグラウンドおよびバックグラウンドプロセスとは関係ありませんか？

linuxprocessproc
43
Tim

これは、フォアグラウンドおよびバックグラウンドプロセスとは関係ありません。現在実行中のプロセスとのみ関係があります。カーネルが「/proc/selfは何を指しているか」という質問に答える必要がある場合、単純に 現在スケジュールされているpidを取り出します 、ie現在実行中のプロセス（現在の論理CPU上）。その結果、/proc/selfは常に要求元プログラムのPIDを指します。あなたが走れば

ls -l /proc/self

lsのpidが表示されます。/proc/selfを使用するコードを作成すると、そのコードは独自のpidを表示します。

69
Stephen Kitt

シンボリックリンクにアクセスするもの（それに対してreadlink（）を呼び出すか、それを通るパスに対してopen（）を呼び出します）。当時はCPUで実行されていましたが、それは関係ありません。マルチプロセッサシステムでは、CPUで同時に複数のプロセスを実行できます。

フォアグラウンドプロセスとバックグラウンドプロセスは、ほとんどがシェルコンストラクトであり、システム上のすべてのシェルセッションにフォアグラウンドプロセスがあるため、固有のフォアグラウンドプロセスもありません。

40
ilkkachu

言い回しの方が良かったかもしれませんが、繰り返しますが、自己参照のアイデアを表現するために作成しようとする言い回しは混乱します。私の意見では、ディレクトリの名前はより説明的です。

基本的に、/proc/self/は/proc/self/を読み取っているプロセスを表します。したがって、Cプログラムから/proc/self/を開こうとすると、そのプログラムを表します。シェルから実行しようとすると、シェルなどになります。

しかし、実際のマルチタスクではなく、4つのプロセスを同時に実行できるクアッドコアCPUがある場合はどうなりますか？

次に、各プロセスは実際には異なる/proc/self/を参照しますが、互いの/proc/self/を参照することはできません。

これはどのように機能しますか？

まあ、/proc/self/は実際にはフォルダではありません。これは、アクセスしようとすると、たまたまフォルダとして公開されるデバイスドライバです。これは、フォルダに必要なAPIを実装しているためです。これを行うのは/proc/self/ディレクトリだけではありません。リモートサーバーからマウントされた共有フォルダー、またはUSBサムドライブまたはドロップボックスのマウントを検討してください。これらはすべて、フォルダのように動作させる同じAPIセットを実装することで機能します。

プロセスが/proc/self/にアクセスしようとすると、デバイスドライバーはそのプロセスからデータを読み取ることにより、そのコンテンツを動的に生成します。したがって、/proc/self/のファイルは実際には存在しません。それは、それを見ようとするプロセスを振り返る鏡のようなものです。

本当にデバイスドライバーですか？単純化しすぎているように聞こえます！

はい、そうです。熟考したい場合は、カーネルモジュールです。しかし、さまざまなLinux開発者チャネルでusenetの投稿を確認すると、ほとんどのカーネル開発者は「デバイスドライバー」と「カーネルモジュール」を同じ意味で使用しています。以前は、Linux用のデバイスドライバー、エラー...カーネルモジュールを作成していました。 /proc/で独自のインターフェースを作成する場合、たとえば、このウェブサイトからの投稿を返す/proc/unix.stackexchange/ファイルシステムが必要な場合は、由緒ある「Linuxデバイスドライバー」の本でその方法を読むことができます。 O'Reillyによって発行されました。オンラインのソフトコピーとしても利用できます。

28
slebetman

これは、/proc/selfまたはその中のファイル/フォルダにアクセスしているプロセスです。

cat /proc/self/cmdlineをお試しください。驚きのサプライズcat /proc/self/cmdlineが表示されます（実際には、スペースの代わりに、tと/の間にヌル文字があります）。この疑似ファイル。

ls -l /proc/selfを実行すると、lsプロセス自体のpidが表示されます。または、ls -l /proc/self/exeはどうですか？ ls実行可能ファイルを指します。

または、変更のためにこれを試してください：

$ cp /proc/self/cmdline /tmp/cmd
$ hexdump -C /tmp/cmd
00000000  63 70 00 2f 70 72 6f 63  2f 73 65 6c 66 2f 63 6d  |cp./proc/self/cm|
00000010  64 6c 69 6e 65 00 2f 74  6d 70 2f 63 6d 64 00     |dline./tmp/cmd.|
0000001f

あるいは

$ hexdump -C /proc/self/cmdline 
00000000  68 65 78 64 75 6d 70 00  2d 43 00 2f 70 72 6f 63  |hexdump.-C./proc|
00000010  2f 73 65 6c 66 2f 63 6d  64 6c 69 6e 65 00        |/self/cmdline.|
0000001e

私が言ったように、それは/proc/selfまたはその中のファイル/フォルダにアクセスしているプロセスです。

11
Viktor Toth

/ proc/selfは構文糖です。これは、/ proc /を汚染し、getpid（）システムコールの結果（メタ変数$$としてbashでアクセス可能）へのショートカットです。シェルスクリプトの場合、ステートメントの多くが他のプロセスを呼び出すため、混乱する可能性があります。独自のPIDを使用して完了します。多くの場合、デッドプロセスを参照するPID検討してください：

root@vps01:~# ls -l /proc/self/fd
total 0
lrwx------ 1 root root 64 Jan  1 01:51 0 -> /dev/pts/0
lrwx------ 1 root root 64 Jan  1 01:51 1 -> /dev/pts/0
lrwx------ 1 root root 64 Jan  1 01:51 2 -> /dev/pts/0
lr-x------ 1 root root 64 Jan  1 01:51 3 -> /proc/26562/fd
root@vps01:~# echo $$
593

'/ bin/ls'はディレクトリへのパスを評価し、/ proc/26563として解決します。これは、プロセスのPID-新しく作成された/ bin/lsプロセス-がディレクトリの内容を読み取るためです。しかし、シェルスクリプトの場合はパイプラインの次のプロセスまでに、またはインタラクティブシェルの場合はプロンプトが戻ってくるまでにパスはもう存在しませんと情報出力は、存在しないプロセスを参照しています。

ただし、これは外部コマンドにのみ適用されます（シェル自体に組み込まれるのではなく、実際の実行可能プログラムファイルです）。したがって、パス名を外部プロセス/ bin/lsに渡すのではなく、ファイル名のグロビングを使用してディレクトリの内容のリストを取得すると、異なる結果が得られます。

root@vps01:~# ls /proc/self/fd
0  1  2  3
root@vps01:~/specs# echo /proc/self/fd/*
/proc/self/fd/0 /proc/self/fd/1 /proc/self/fd/2 /proc/self/fd/255 /proc/self/fd/3

最初の行で、シェルはexec（）システムコールを介して新しいプロセス '/ bin/ls'を生成し、argv [1]として "/ proc/self/fd"を渡しました。 '/ bin/ls'は、次に、ディレクトリ/ proc/self/fdを開き、その内容を繰り返しながら、その内容を読み取ってから出力しました。

ただし、2行目は、背後でglob（）を使用してファイル名のリストを展開しています。これらは、エコーする文字列の配列として渡されます。 （通常、内部コマンドとして実装されますが、/ bin/echoバイナリもしばしば存在します...しかし、echoは文字列のみを処理するため、その部分は実際には無関係です。パス名に関連するシステムコールにフィードされることはありません。）

ここで、次のケースを考えます。

root@vps01:~# cd /proc/self/fd
root@vps01:~# ls
0  1  2  255

ここで、シェル、親プロセス/bin/lsは、/ proc/selfのサブディレクトリを現在のディレクトリにしました。したがって、相対パス名はその観点から評価されます。私の推測では、これはPOSIXファイルのセマンティクスに関連し、ファイルへの複数のハードリンクを作成できる含む開いているファイル記述子。したがって、今回は/ bin/lsは/ proc/$$/fd/*をエコーするように動作します。

2
Barry J. Burns