docker top 和容器内 ps 显示不同 PID，按进程号诊断时找不到目标

docker top 显示某个服务的 PID 是 24031，进入容器运行 ps，同一个服务却是 PID 1。拿 24031 去读容器里的 /proc/24031/status，可能提示文件不存在；反过来，在宿主机检查 /proc/1，看到的又是宿主机自己的 init。

这通常是 PID 命名空间的视角不同。同一个 Linux 进程在容器内部和宿主机上可以有不同的编号，不能把一侧的 PID 原样拿到另一侧使用。

以下诊断限定 Docker Engine 运行在原生 Linux 上、容器使用独立 PID 命名空间，且操作者能读取 daemon 所在宿主机的 /proc。共享宿主机或其他容器 PID 命名空间、rootless 的嵌套环境、Windows 容器需要按实际配置判断。Docker Desktop 的 Linux 容器运行在虚拟机里，也不能直接用 macOS 或 Windows 的进程列表解释这些号码。

先区分命令在哪一侧读取进程

demo-service 是示例容器名，应替换成需要诊断的运行中容器。先看 Docker 返回的进程列表：

docker top demo-service

Linux 端的 Docker daemon 调用所在环境的进程查看工具，再筛选出属于该容器的进程。因此，这里列出的 PID 是 daemon 一侧看到的编号，不是 Docker CLI 所在电脑的编号。连接远程 Docker 时，本机 /proc 更不能用于核对它。

若镜像已有支持 -ef 的 ps，可从容器内部读取：

docker exec demo-service ps -ef

这是容器内部的进程视角。精简镜像可能没有 ps，或只支持不同选项；工具不存在不表示服务已经退出，也不需要为了这次查看临时给业务容器安装整套诊断软件。

先用命令名称、参数和启动关系找到候选进程，但不要只靠名称建立最终对应关系。多个 worker 可以使用相同命令行，两个快照之间进程也可能已经退出。命令参数还可能含凭据，保存诊断记录前应遮蔽敏感值。

用宿主机的状态文件确认命名空间编号

Linux 4.1 起，/proc/PID/status 提供 NStgid 等命名空间编号字段。对刚从 docker top 确认的宿主机进程 PID，在同一台 Linux 宿主机读取状态，例如：

grep -E '^(Name|Tgid|Pid|NStgid|NSpid):' /proc/24031/status

24031 只是占位数字，必须替换为当前观察到的进程号。普通的“宿主机加一层容器 PID 命名空间”中，可能看到这样的示意结果：

Name:   demo-server
Tgid:   24031
Pid:    24031
NStgid: 24031 1
NSpid:  24031 1

NStgid 表示同一个进程的线程组 ID，也就是通常使用的进程 PID，在各层命名空间中的值。最左侧相对于挂载该 procfs 的命名空间，随后依次向内。这里宿主机看到 24031，一层容器里看到 1，两者对应同一个进程。

NSpid 则是各层的线程 ID。查询进程的主线程时两行经常相同，但排查线程列表时不要把线程 ID 和进程 PID 混为一谈。若出现三个或更多编号，说明不能再套用简单的“两列对应”解释，应先确认嵌套层次和目标容器所在的层。

读不到文件时，重新查看容器状态和进程列表，排除进程已退出或重启。权限拒绝与文件不存在也要分开处理：应通过已有授权的运维入口读取，不应为了观察 PID 放宽全机 /proc 访问控制。

把诊断命令留在取得 PID 的环境中

使用宿主机上的进程工具或 /proc 时，使用已经核对过的宿主机编号；通过 docker exec 调用容器内部工具时，使用容器内部编号。最好在诊断记录中同时保存容器标识、观察时间、命名空间编号和命令名称，而不是只留一个裸数字。

PID 会随进程重新创建而变化，也可能被复用。前一次排查记下的数字，不能直接用于下一次重启后的诊断，更不能直接用于发送信号。No such process 不一定说明 Docker 没有正常运行；它也可能说明调用者所在的命名空间里没有这个编号。

这里的编号差异本身无需修复容器隔离设置。不要为了让两边显示同一个数字改用宿主机 PID 模式，也不要根据一份旧快照发送强制终止信号。宿主机具备相应权限时能够影响容器进程，PID 隔离并不意味着“宿主机无法终止它”。

核对成功的标准

在进程稳定运行期间，宿主机状态文件中的命名空间编号应能对应容器内部看到的目标进程。对多 worker 服务应逐个确认，不能因为其中一个对应成功就把所有同名进程套用同一映射。

以上命令只读取状态或启动一次容器内 ps，不改变服务配置。若只是纠正了监控或排查脚本中的 PID 来源，保留原脚本即可回退；不要把错误 PID 对应的其他进程信息继续写入该容器的故障记录。需要停止服务时，应另按业务既有停止流程处理，不能把本次只读映射验证当作终止操作的授权或成功证明。