為什麼 unshare -p 並不意味著 -f 和 –mount-proc？
手冊頁指定您可能對使用和
--fork創建--mount-procPID 命名空間感興趣，但為什麼這些選項不是預設選項？
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 的程序具有三個獨特的特徵：
它會自動接收預設的信號處理器。這意味著發送給它的信號將被忽略，除非它顯式地向信號處理程序註冊信號。
如果命名空間中的另一個程序在其子程序之前死亡，則其子程序將重新成為具有 pid 1 的程序的父程序。這允許
init從程序中收集退出狀態，以便核心可以將其從程序表中刪除。如果 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實用程序。