为什么 unshare -p 不暗示 -f 和 --mount-proc？

Linux 命名空间是使用unshare(2)系统调用创建的。该unshare程序只是系统调用的一个薄包装器，unshare(2)它以一种与底层系统调用一样灵活的方式公开命名空间功能。

对于大多数命名空间，unshare(2)修改调用进程运行时环境，将其与父命名空间分离，并将其与新的、通常为空的命名空间相关联。例如，从网络命名空间中取消共享自己的进程会立即看到一个没有设备的新的空网络命名空间。

然而，PID 命名空间的工作方式不同。当unshare()被调用分离一个 PID 命名空间时，它不会修改调用进程的运行环境，而是使 a 之后的子进程fork()进入新的 pid 命名空间，并在新的命名空间内接收 PID 1。initPID 1 是为进程保留的。

--fork至于和--mount-proc不是默认选项的可能原因：

• --fork可能不是默认值，因为没有其他命名空间需要 fork，并且将 the--fork作为单独的选项使选项的行为--pid与其他命名空间选项直接映射到unshare(2)标志的方式一致。

• --mount-proc可能不是默认值，因为它暗示了一个挂载命名空间 ( )，并且除了使用适当的标志之外--mount，这类似于--fork执行其他操作。unshare(2)

init要正确使用 PID 命名空间，需要一个专门设计用于在新命名空间中扮演角色的特殊程序。在新的 PID 命名空间中，pid与其他进程相比，带有 1 的进程具有三个独特的特征：

1) 它会自动接收默认的信号处理器。这意味着发送给它的信号将被忽略，除非它显式地向信号处理程序注册信号。

2) 如果命名空间中的另一个进程在其子进程之前死亡，则其子进程将重新成为具有 pid 1 的进程的父进程。这允许init从进程中收集退出状态，以便内核可以将其从进程表中删除。

3) 如果 PID 为 1 的进程死亡，则 pid 命名空间中的所有其他进程都将被强制终止，命名空间被销毁。

由于这些原因，应用程序进程通常不适合在 PID 命名空间内作为 PID 1 运行。

为各种内核控制资源添加命名空间主要是由容器技术推动的，特别是系统容器，它提供了与传统虚拟机(VMS)非常相似的环境，但没有运行单独的内核模拟虚拟机硬件所带来的开销. 早期，命名空间被引入 Linux 内核（主要在 Linux 2.4.19 - 3.8 之间），PID 命名空间是在 Mount、UTS、IPC 和网络命名空间之后引入的。早期版本unshare开创了不同命名空间选项的预期行为方式。

在LXC和Docker等成熟的容器框架可用之前，unshare可以将其用作临时实用程序，以在新容器（由新的 PID 命名空间和可能的其他非共享命名空间组成）内生成init守护进程（例如systemd）。这样的框架包括它们自己的用于启动容器的功能，而无需unshare. 现代版本systemd也支持此功能，而无需单独的unshare实用程序。