unshare -pが-fと--mount-procを意味しないのはなぜですか？

Linux 名前空間は、次のコマンドを使用して生成されます。unshare(2)システムコール。これunshareプログラムちょうど薄い包装紙unshare(2)デフォルトのシステムコールと同じ柔軟な方法でネームスペース機能を公開するシステムコール。

ほとんどの名前空間の場合unshare(2)呼び出しプロセスランタイム環境を変更して親名前空間から分離し、新しい（通常は空の）名前空間に関連付けます。たとえば、プロセスは次から始まります。ネットワークネームスペースデバイスのない空の新しいネットワーク名前空間がすぐに表示されます。

これPID名前空間、しかし、異なる動作します。分離されたPID名前空間が呼び出されると、呼び出しunshare()プロセスの実行時環境は変更されませんが、後続の子プロセスはfork()新しいpid名前空間に入り、新しい名前空間からPID 1を受け取ります。 PID 1はinitこのプロセス用に予約されています。

--forkと--mount-procがデフォルトオプションではない可能性のある理由は次のとおりです。

• --forkデフォルトではない可能性があります他の名前空間は分岐する必要はありません。--forkこのオプションの動作は、--pid別の名前空間オプションが直接マッピングされる方法と一致するように別々のオプションとして提供されます。unshare(2)バナー。

• --mount-procおそらくデフォルトではありません。これは--mount、適切なフラグを使用する--forkことに加えて、他の操作を実行するのと同様の名前空間（）インストールを意味するためです。unshare(2)

PID名前空間を正しく使用するには、init新しい名前空間で動作するように設計された特別なプログラムが必要です。新しいPID名前空間でpidPID 1を使用するプロセスは、他のプロセスと比較して3つのユニークな機能を持ちます。

1) 基本信号ハンドラを自動的に受信します。これは、プロセスが明示的に信号ハンドラを登録しない限り、送信された信号が無視されることを意味します。

2）名前空間の他のプロセスが子プロセスの前に終了すると、その子プロセスはpid 1のプロセスにリセットされます。これにより、initプロセスの終了ステータスを収集して、カーネルがプロセステーブルからそのプロセスを削除できます。

3）PID 1のプロセスが終了すると、pid名前空間の他のすべてのプロセスが強制終了され、名前空間が破棄されます。

このため、アプリケーションプロセスは通常、PID名前空間内でPID 1として実行するのには適していません。

さまざまなカーネル制御リソースの名前空間を追加する主な動機は次のとおりです。コンテナ技術、特にシステムコンテナ既存の環境と非常に似た環境を提供仮想デバイス（VMS）ですが、仮想マシンのハードウェアをエミュレートする別のコアを実行するオーバーヘッドはありません。最初に、名前空間がLinuxカーネルに導入されました（主にLinux 2.4.19 - 3.8の間）、PID名前空間は、Mount、UTS、IPC、およびNetwork名前空間の後に導入されました。以前のバージョンunshareさまざまな名前空間オプションの期待される動作の先例を設定します。

成熟したコンテナフレームワークの移転。LXCそしてルーストアバウト利用可能、unshare新しいPID名前空間と他の非共有名前空間で構成される新しいコンテナ内にinitデーモン（たとえば）を作成するための一時ユーティリティとして使用できます。systemdこれらのフレームワークには、特別な作業なしでコンテナを起動するための独自の機能が含まれています。unshare。現代バージョンsystemdunshareこの機能は、別途ユーティリティなしでサポートされます。。