Linux 命名空间是使用unshare(2)系统调用创建的。该unshare程序只是unshare(2)系统调用的一个瘦包装器，它以一种与底层系统调用一样灵活的方式公开命名空间功能。
对于大多数命名空间，unshare(2)修改调用进程运行时环境，将其与父命名空间分离，并将其与新的、通常为空的命名空间相关联。例如，从网络命名空间取消共享自身的进程会立即看到一个没有设备的新的空网络命名空间。
但是，PID 命名空间的工作方式不同。当unshare()被调用来分离一个PID命名空间时，它不会修改调用进程的运行环境，而是使a之后的子进程fork()进入新的pid命名空间，并在新的命名空间内接收PID 1。PID 1 是为init进程保留的。
至于为什么--fork和--mount-proc不是默认选项的可能原因：
--fork可能不是默认值，因为没有其他命名空间需要 fork，并且将--fork用作单独的选项可以使选项的行为--pid与其他命名空间选项直接映射到unshare(2)标志的方式保持一致。
--mount-proc可能不是默认值，因为它暗示了一个挂载命名空间 ( --mount)，这类似于--fork除了unshare(2)使用适当的标志之外执行其他操作。
要正确使用 PID 命名空间，需要一个专门设计的特殊程序，以init在新命名空间中扮演角色。在新的 PID 命名空间中，pid与其他进程相比，具有1的进程具有三个独特的功能：
1) 它会自动接收默认信号处理器。这意味着发送给它的信号将被忽略，除非进程显式注册信号处理程序。
2) 如果命名空间中的另一个进程在它的子进程之前死亡，它的子进程将被重新分配给 pid 1 的进程。这允许init从进程中收集退出状态，以便内核可以将它从进程表中删除。
3) 如果 PID 为 1 的进程死亡，pid 命名空间中的所有其他进程都将被强制终止并销毁命名空间。
由于这些原因，应用程序进程通常不适合在 PID 命名空间内作为 PID 1 运行。
为各种内核控制的资源添加命名空间的主要动机是容器技术，特别是系统容器，它提供与传统虚拟机(VMS)非常相似的环境，但没有运行单独的内核模拟硬件到 VM 所带来的开销。 . 早先命名空间被引入 Linux 内核（主要在 Linux 2.4.19 - 3.8 之间），PID 命名空间是在 Mount、UTS、IPC 和网络命名空间之后引入的。早期版本为unshare不同命名空间选项的行为方式开创了先例。
在成熟的容器框架（如LXC和Docker）可用之前，unshare可以用作临时实用程序，在新容器（由新的 PID 命名空间和可能的其他非共享命名空间组成）内生成init守护程序（如systemd）。此类框架包括自己的功能，无需unshare. 的现代版本systemd也支持此功能，而无需单独的unshare实用程序。