使用unshare后台创建PID命名空间启动shell后会话异常终止问题咨询

核心原因 #

当你使用unshare --fork --pid /bin/bash &后台启动PID命名空间时，bash会成为新PID命名空间的init进程（PID 1），而PID 1的信号处理行为和普通进程存在本质差异：

• 普通后台进程尝试读取终端输入时，会收到SIGTTIN信号并被暂停（这也是UTS命名空间中bash处于Stopped状态的原因）；
• 但PID 1会忽略未显式处理的信号，不会被暂停。当它尝试读取无控制权的终端输入时，会直接因读取失败退出。

同时PID命名空间有个关键特性：一旦init进程退出，命名空间内所有进程会被强制发送SIGKILL终止。虽然这里bash是命名空间内的唯一进程，但它的退出会导致终端关联出现异常，进而触发你的SSH会话直接关闭。

可行的解决方法 #

要在后台正常运行PID命名空间内的shell，需要给它分配独立终端或避免终端依赖：

1. 分配伪终端：使用--pty参数让unshare为新shell创建伪终端，后台运行也能正常交互：

   unshare --fork --pid --pty /bin/bash &
   

   之后可以用jobs查看进程状态，再用fg切换到前台交互。

2. 前台启动后分离会话：直接前台启动后，用Ctrl+Z暂停进程，再用bg将其放到后台；或者结合nohup让进程脱离终端：

   nohup unshare --fork --pid /bin/bash &
   

   这种方式适合运行非交互式任务，无法直接进行终端交互。

3. 使用终端复用工具：用screen或tmux在独立会话中启动，完全避免和原SSH终端冲突：

   screen -dmS ns_session unshare --fork --pid /bin/bash
   

   后续可通过screen -r ns_session连接到该会话。

相关规则参考 #

PID命名空间的init进程行为和命名空间销毁规则，在unshare的man手册（执行man unshare查看）及Linux内核文档中有明确说明：

• 创建PID命名空间时，第一个进入该命名空间的进程会成为PID 1，承担init进程的核心职责；
• PID 1退出时，内核会向命名空间内所有剩余进程发送SIGKILL信号，强制终止它们。

内容的提问来源于stack exchange，提问作者Rocath