Linux lsns 怎样查看进程所属命名空间

查看一个 Linux 进程到底加入了哪些命名空间，最直接的入口是 lsns --task PID。它从当前可访问的 /proc 文件系统读取命名空间信息，并把命名空间 inode、类型、进程数和关联命令整理出来。先记住一个判断：同一个命名空间 inode 表示进程共享同一个命名空间实例；查询结果为空或不完整时，不能立刻推断进程没有加入命名空间，还要结合 /proc 的可见范围与权限判断。

参考手册：https://man7.org/linux/man-pages/man8/lsns.8.html

日常排查可以从 lsns -p PID 开始；需要稳定地给脚本消费时，再显式指定 --type、--output 或 --json。不要把默认表格列当成长期稳定的接口。

先搞清楚 lsns 到底在查看什么

命名空间不是进程的一个普通字符串属性。Linux 会为不同隔离维度维护独立的命名空间实例，进程通过 /proc/PID/ns/ 下的链接暴露自己当前所在的实例。lsns 读取这些信息，把链接背后的 inode 编号作为命名空间标识，再按类型组织结果。

常见类型包括挂载命名空间 mnt、网络命名空间 net、PID 命名空间 pid、用户命名空间 user、UTS 命名空间 uts、IPC 命名空间 ipc、cgroup 命名空间 cgroup 和时间命名空间 time。一个进程通常会同时出现在多种类型中，所以不要只看一行就下结论。

按 PID 查看进程所属的全部命名空间

假设要排查 PID 为 2718 的服务，先用任务筛选：

# 只查看 PID 2718 持有的命名空间，先建立全貌
lsns --task 2718

# 只查看网络命名空间，缩小到网络隔离问题
lsns --type net --task 2718

# 同时保留进程名和进程数，便于判断是否有其他进程共享该实例
lsns --task 2718 --output NS,TYPE,NPROCS,COMMAND

--task PID 的含义是“显示这个进程持有的命名空间”，不是按进程号给所有结果排序。--type 可以重复使用，但排查时最好从一个明确的类型开始，避免把网络问题和挂载问题混在同一张表里。

用 NS、TYPE 和 NPROCS 判断共享关系

固定列之后，关注三列就够完成第一轮判断：

这里的“相同”要同时满足类型和 NS 都相同。不同类型即使显示相同数字，也不能直接当成同一个命名空间使用。NPROCS 也不是全系统绝对进程数，它受当前 /proc 视图和权限影响，适合做辅助证据，不适合单独作为结论。

让查询结果适合脚本和复查

手工看表格时默认输出很方便，但命令手册明确提醒默认列和默认输出形式可能变化。部署脚本、巡检脚本或故障记录应显式指定输出模式：

# 只输出需要归档的字段，避免默认列变化影响解析
lsns --task 2718 --output NS,TYPE,NPROCS,COMMAND

# 用 JSON 交给后续脚本处理，减少空格对分列的影响
lsns --json --task 2718 --output NS,TYPE,NPROCS,COMMAND

# 需要查看所有可用字段时先列出列名，再选择固定集合
lsns --list-columns

如果只想看某一种隔离维度，可以把类型放在固定命令里：

# 只归档网络命名空间的稳定字段
lsns --type net --task 2718 --output NS,TYPE,NPROCS,COMMAND

# 让多行字段变成单行表示，便于日志系统接收
lsns --type net --nowrap --task 2718 --output NS,TYPE,NPROCS,COMMAND

结果为空时先排查可见性和权限

lsns 直接从 /proc 读取信息。未授权用户可能只能得到不完整结果，当前进程看到的 /proc 还可能因为 PID 命名空间或挂载方式不同而不同。因此，目标进程在宿主机上存在，并不保证当前诊断环境可以完整枚举它。

# 先确认目标 PID 在当前视图是否可见
ps -p 2718 -o pid,comm

# 再确认对应的命名空间链接是否存在
ls -l /proc/2718/ns

# 目标可见但结果仍不完整时，记录执行身份和诊断环境
id
mount | grep ' on /proc '

# 最后再用 lsns 复查，避免把权限问题误判成没有命名空间
lsns --task 2718 --output NS,TYPE,NPROCS,COMMAND

上面几步只是建立证据链，不代表要为了“看全”而随意改变生产环境的挂载或权限。对容器场景尤其要记录命令是在宿主机、容器内还是另一个 PID 命名空间中执行的；执行位置不同，/proc 视图就可能不同。

把常见现象和处理方向对上

还有一个边界：没有进程、但通过绑定挂载长期保存的持久命名空间，lsns 不一定能直接看到。遇到这种场景，不能用“当前列表没有这一行”证明实例不存在；应结合持久化路径和创建方式另行确认。

复查清单

• 目标 PID 是否在当前执行环境的 /proc 中可见。
• 是否先用 --task PID 建立全貌，再按 --type 缩小范围。
• 比较共享关系时是否同时比较 TYPE 和 NS。
• 脚本是否显式指定了 --output，而不是依赖默认表格。
• 出现缺失结果时，是否记录了权限、PID 命名空间和 /proc 挂载视图。

常见问题

同一个 NS 数字在不同 TYPE 中出现，说明共享吗？

不能这样判断。NS 是某个命名空间实例的 inode 标识，比较时必须先限定同一种 TYPE。正确做法是分别比较 net、mnt 或 pid 等类型下的 NS。

lsns 默认输出可以直接写进监控脚本吗？

不建议。默认列和格式可能变化，应该使用 --output 明确列集合；需要程序处理时可以选 --json，多行字段还要根据接收端选择 --nowrap。

看不到目标 PID 就代表它没有命名空间吗？

不代表。先确认执行位置、当前 PID 命名空间、/proc 挂载和权限，再解释结果。lsns 的信息范围受当前可访问的 /proc 限制。

把这项排查压缩成一句话：先用 lsns -p PID 找到进程所属的各类命名空间，再用固定列或 JSON 记录 NS 与 TYPE；结果不完整时优先检查当前 /proc 视图和权限，而不是直接否定命名空间的存在。