这手册页指定您可能有兴趣在创建 PID 命名空间时使用--fork和--mount-proc，但为什么这些选项不是默认选项？
答案1
Linux 命名空间是使用以下命令创建的unshare(2)系统调用。这unshare程序只是一个薄薄的包装纸unshare(2)以与底层系统调用一样灵活的方式公开名称空间功能的系统调用。
对于大多数命名空间来说，unshare(2)修改调用进程运行时环境，将其与父命名空间分离，并将其与新的（通常为空的命名空间）关联。例如，一个进程从网络命名空间立即看到一个新的、空的网络命名空间，没有任何设备。
这PID命名空间，但工作方式不同。当unshare()调用 分离 PID 命名空间时，它不会修改调用进程的运行时环境，而是使 a 之后的子进程fork()进入新的 pid 命名空间，并在新命名空间内接收 PID 1。 PID 1 是为该init进程保留的。
至于--fork和--mount-proc不是默认选项的可能原因：
--fork可能不是默认值没有其他命名空间需要分叉，并且将--fork作为单独的选项使该选项的行为--pid与其他命名空间选项直接映射到的方式保持一致unshare(2)旗帜。--mount-proc可能不是默认值，因为它意味着安装命名空间 (--mount)，这类似于除了使用适当的标志--fork之外还执行其他操作。unshare(2)
为了正确地使用 PID 命名空间，需要一个专门设计的特殊程序来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和Network命名空间之后引入的。早期版本unshare为不同命名空间选项的预期行为树立先例。
在成熟的容器框架之前，例如LXC和码头工人可用，unshare可以用作临时实用程序，在新容器（由新的 PID 命名空间和可能的其他非共享命名空间组成）内生成init守护程序（例如）。systemd此类框架包含自己的启动容器功能，无需unshare。现代版本systemd也支持此功能，无需单独的unshare实用程序。