登录
推荐 文章 Go 技术 课程 下载 专题 AI
首页 >  文章 >  linux

Linux namespace 中为什么看不到宿主机的进程

来源:17golang原创

时间:2026-09-09 11:14:00 412浏览 收藏

容器里执行 ps 看不到宿主机进程,通常不是进程真的消失了,而是当前进程处在子 PID namespace 中。Linux 把进程 ID 空间按层级隔离:子 namespace 能看到自己和后代的进程,不能向上看到父 namespace 的进程;而 /proc 又会按照它被挂载时关联的 PID namespace 展示目录。因此,排查时要把“进程属于哪一层”和“ps 读的是哪份 procfs”分开。

要点速览
  • PID namespace 的可见性方向是向下的,容器默认不能查看宿主机进程。
  • /proc/1/proc/self/ns/pid 和 procfs 挂载关系,分别回答不同问题。
  • 测试隔离视图可用 unshare --fork --pid --mount-proc;需要查看宿主机视图时再考虑宿主机边界的 nsenter

为什么子 namespace 看不到宿主机进程

PID namespace 隔离的是进程 ID 数字空间。新 namespace 的第一个进程会拿到 PID 1,后续子进程只在本层和祖先层拥有可见的 PID。宿主机位于父 namespace,容器位于子 namespace,所以容器里的进程不能把宿主机进程当成自己的可操作对象。

这条规则也解释了一个容易混淆的现象:同一个进程可能在不同层有不同 PID,数字相同不代表是同一个可见对象。父 namespace 可以看到子 namespace 内的进程,反方向却不成立。容器的 PID 1 负责接收并处理本层的孤儿进程;如果它退出,内核会结束该 namespace 里的其他进程。

Linux PID namespace 中宿主机进程、容器 PID 1 与 procfs 视图的父子可见性边界关系图
图1:PID namespace 的父子边界决定进程可见性,子 namespace 不会向上看到宿主机进程。

先分清 PID 身份和 /proc 视图

值班排查先不要急着加权限或修改容器启动参数。下面几项检查可以帮助你确认当前处于哪一层,命令只读取本地内核提供的链接:

# 记录当前 shell 与本层 PID 1 的 namespace 身份
printf 'self: '; readlink /proc/self/ns/pid
printf 'pid1: '; readlink /proc/1/ns/pid

# 观察当前 procfs 能提供哪些进程目录
ls -1 /proc | awk '$0 ~ /^[0-9]+$/ {print $0}' | head

# 记录 /proc 的挂载参数,确认它不是沿用了另一层的 procfs
findmnt -T /proc -o TARGET,FSTYPE,OPTIONS

/proc/self/ns/pid 表示调用进程已经加入的 PID namespace;/proc/1/ns/pid 通常帮助确认本层的 init 进程。真正影响 ps 列表的,是 procfs 挂载时采用的 PID namespace 视图。只比较 PID 数字,无法判断这三者的关系。

调用进程、proc self PID namespace、PID 1、procfs 挂载实例和 ps 观察范围的 Linux 关系图
图2:进程身份与 procfs 挂载视图是两条相关但不同的排查线索。

用独立测试视图复现而不是猜权限

在有权限的测试机上,可以用 unshare 创建一个新的 PID namespace,并同时挂载匹配的 procfs。--fork 让后续 shell 成为新 namespace 的第一个子进程,--mount-procps 读取与这层 PID 视图匹配的 /proc

# 在测试环境创建独立 PID 视图,不修改宿主机的现有进程
unshare --fork --pid --mount-proc sh -c '
  # 新 namespace 的第一个进程通常显示为 PID 1
  printf "namespace pid: %s\n" "$$"
  # 这里只观察本层可见的进程
  ps -eo pid,ppid,comm
'

这个实验的关键不是输出多少行,而是确认 PID 1、procfs 和 ps 处于同一观察边界。如果只使用 --pid 而没有更新 procfs,工具可能继续读取旧的进程目录,导致“namespace 已变但列表没变”的错觉。

排障、进入与回滚怎么选

现象优先判断处理方向
容器内没有宿主机 PID正常的父子 namespace 隔离在宿主机侧查看,别把它当成进程丢失
ps 列表异常少或与预期不符procfs 挂载视图不匹配检查 findmnt -T /proc 与挂载时的 PID namespace
进入目标视图后仍看不到进程目标 PID、权限或 mount namespace 不对核对目标进程,再按需同时指定 -p -m

临时诊断宿主机上的容器进程时,可以在宿主机边界使用类似下面的命令;它需要足够权限,目标 PID 也必须是宿主机看到的 PID:

# host_pid 是宿主机视角的目标进程号,不是容器内的 PID
host_pid=12345
# 同时进入 PID 与 mount 视图,避免 ps 仍读取错误的 /proc
nsenter -t "$host_pid" -p -m ps -eo pid,ppid,comm

这类进入动作应该只用于短时排障,结束后退出 shell,不要把它固化成容器启动参数。若问题来自错误的 procfs 挂载,优先恢复原有挂载配置并重新创建测试容器;若只是观察范围预期不同,则保留隔离设置,把监控和进程检查放到宿主机或运行时管理边界。

相关问题

PID namespace 能不能从容器里反向进入宿主机?

普通容器进程不能凭 PID 数字直接进入父 namespace。Linux 的 PID namespace 进入方向受层级和权限约束,排障应在宿主机或受控运维入口执行。

为什么容器内的 PID 1 不是宿主机的 PID 1?

PID 1 是“对当前 namespace 可见的第一个进程”。同一个进程在宿主机层和容器层可以有不同 PID,所以两处的 PID 1 不必是同一对象。

只执行 ps 看不到宿主机进程,能说明进程不存在吗?

不能。先比较 namespace 链接和 /proc 挂载;若要判断宿主机进程是否存在,应从宿主机的 PID namespace 查询。

把 PID namespace 的层级可见性和 procfs 的挂载视图拆开后,这个现象就不再是“容器少了进程”,而是一个可以定位到边界的观察问题。

声明:本文转载于:17golang原创 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>