struct pid_namespace这个名字在多数人眼里不过是一行C语言结构体声明但Linux内核里整个容器世界的进程隔离、PID重编号、进程回收底层全是它在兜底。我第一次认真抠它是因为排查一个容器内进程级联退出的故障翻到include/linux/pid_namespace.h时才发现之前很多想当然的判断都是错的。这篇文章我就用自己消化过的内容把这个结构体的设计动机、每个字段的作用、以及怎么在运行时验证它的行为完完整整讲一遍。适合正在读内核源码的、做容器运行时二次开发的以及被容器里PID对不上这种问题折磨过的读者。你不需要先精通内核只要写过C、用过Linux命令就能跟着走下来。1. 没有pid命名空间时容器只是看起来隔离1.1 进程视图共享引发的三大问题先回到没有pid命名空间的时代。早期容器实现很粗糙只是用chroot加cgroup把进程圈起来但进程看到的进程表是全局共享的。这意味着在容器里执行ps -ef你能看到宿主机上的所有进程甚至能看到隔壁容器里的进程。这在隔离性上等于裸奔。带来最直接的三个问题。第一信息泄露容器内可以轻易枚举宿主机上跑了哪些服务进程的命令行参数、环境变量都暴露在/proc下面。第二误操作风险容器里的管理工具拿到全局PID后一个kill -9 1717可能杀掉的不是你容器里的进程而是宿主机上某个关键服务。第三PID复用混淆宿主机上进程创建销毁频繁PID会被反复使用。你在容器里记录了一个PID过一会儿再查它可能已经变成了另一个完全不相干的进程。要解决这些问题就得让每个容器里的进程认为自己是一台独立机器上的第一批进程。于是内核引入了pid namespace机制而struct pid_namespace就是承载这套机制的核心结构体。1.2 struct pid_namespace在整个机制里的位置要理解这个结构体得先弄清楚它挂在哪个环节上。每个进程的task_struct里有一个nsproxy指针nsproxy里挂着各类命名空间mount namespace、uts namespace、ipc namespace、net namespace以及我们今天的主角pid_ns_for_children。注意这个名字它叫for_children。它表示的是当前进程后续fork出来的子进程会被放进哪个pid namespace。当前进程自己属于哪个pid namespace则记录在它的struct pid结构体里。struct pid才是进程在内核中的身份证里面存着该进程在所有相关pid namespace中的编号列表而struct pid_namespace是户籍系统定义了一套编号规则、编号上限、回收孤儿进程的人选。一个容器里的所有进程共享同一个struct pid_namespace。它们各自的struct pid不同但指向同一个namespace结构体。我在读代码时常犯一个误区以为fork会复制整个pid namespace其实完全不是这样。fork时copy_namespaces只是让子进程的nsproxy和父进程共享同一个pid_namespace内部通过kref增加一次引用计数。也就是说容器里每fork一个进程不是多了一份户籍系统而是多了一个户籍登记人。只有调用unshare或clone带有CLONE_NEWPID标志时才会真的创建一套新户籍系统。2. 逐字段啃一遍struct pid_namespace先放一个接近当前主线版本的简化定义不同内核版本字段略有出入但你手里那份源码大概率长这样struct pid_namespace { struct kref kref; // 引用计数 struct idr idr; // pid整数到struct pid的映射表 struct rcu_head rcu; // RCU延迟释放头 unsigned int pid_allocated; // 当前已分配的pid数量 unsigned int pid_limit; // pid数量上限 int last_pid; // 下次分配pid时从哪儿开始找 unsigned int nr_hashed; // 哈希表里的pid数量 struct task_struct *child_reaper; // 本命名空间负责收尸的init进程 struct kmem_cache *pid_cachep; // struct pid的slab缓存 unsigned int level; // 嵌套层数 struct pid_namespace *parent; // 父命名空间 struct user_namespace *user_ns; // 关联的用户命名空间 struct ucounts *ucounts; // 用户资源计数 kgid_t pid_gid; // /proc/sys/kernel/pid_max 的属组 int hide_pid; // /proc 的 hidepid 选项 struct file *proc_mnt; // 本命名空间关联的proc实例 };光看名字能猜个大概但每个字段为什么这样设计才是真正值得花时间的地方。2.1 生命周期三件套kref、rcu、level/parentkref是内核标准的引用计数器。为什么不用普通的atomic_t因为kref提供了一套约定俗成的get/put语义kref_get拿引用kref_put释放引用当计数降到0时自动调用release函数。这样可以避免自己手写原子操作时漏掉release回调。一个pid namespace被多少进程、多少挂载点引用kref都记得清清楚楚。只要还有一个引用没释放整个结构体就停留在内存里容器内进程全退光但/proc还挂在某个地方这个struct pid_namespace就不会被销毁。rcu_head配合RCU机制做延迟释放。为什么需要延迟因为可能存在一些代码路径正在遍历pid namespace而没持有锁这时如果直接把结构体释放掉那些读者就会踩到已释放的内存。RCU的思路是标记删除后等一个宽限期确保所有读者都离开临界区了再真正执行free。这个字段就是让等宽限期结束再释放成为可能。level和parent描述的是嵌套结构。pid namespace可以层层嵌套你可以在一个容器里再创建一套pid namespace形成父子关系。parent指向上层命名空间level表示当前是第几层最外层init namespace的level是0。为了限制嵌套深度内核定义了MAX_PID_NS_LEVEL这个值通常是32。超过32层再创建新pid namespace会直接失败。很多人不知道这个限制在做多层沙箱嵌套时踩到过。2.2 分配器字段idr、pid_allocated、pid_limit、last_pididr是本命名空间维护的PID分配表。内核需要根据一个整数PID快速找到对应的struct pid。idr内部是一棵基数树查找、插入、删除都是对数级复杂度比线性遍历快得多也比普通的哈希表更适合这种整数ID稀疏分配的场景。pid_allocated和pid_limit是配对的前者记录这个namespace里已分配了多少个PID后者是上限。pid_limit是从/proc/sys/kernel/pid_max继承来的默认值通常是32768大内存机器上可能是4194304。当pid_allocated逼近pid_limit时分配器会扫描并回收已经僵死的PID编号。很多人把容器里fork失败以为只是内存不够其实有时纯粹是pid_limit撞顶了。我自己印象最深的是last_pid这个字段。它记录下一次分配PID时从哪个编号开始找。实现上分配器不会每次从头扫描而是从last_pid后面继续找空位这样能利用局部性让最近释放的编号优先被复用。但这也带来了PID回绕问题当编号循环一圈回到某个刚被复用的值时如果用户态还残存着旧进程的引用就会发生挂羊头卖狗肉的混乱。2.3 child_reaper每个命名空间都要有自己的孤儿院院长这是整个结构体里最具有人文关怀的字段。child_reaper指向本命名空间的init进程。它的职责是收养所有被父进程抛弃的孤儿进程并且在子进程变成僵尸时负责回收。一个Linux系统没有init进程是活不下去的——没人收尸僵尸进程堆积最终把PID表耗尽。所以每个pid namespace一创建就必须有一个init进程也就是PID 1。在容器里你指定的entrypoint就是这里的init。child_reaper指向它。一旦这个init进程退出整个命名空间就失去了孤儿院院长。内核的做法很果断通过zap_pid_ns_processes给该命名空间里的所有进程发送SIGKILL把这个namespace清干净。你在容器里跑一个后台任务主进程一退出后台任务全部消失底层逻辑就是这里。这也是很多人疑惑为什么我的容器进程一退其他子进程全没了的真正原因。2.4 user_ns、ucounts、hide_pid、pid_gid、proc_mnt权限与proc绑定的字段user_ns把pid namespace和user namespace绑定在一起。它限定了这个pid namespace归属哪个用户命名空间权限检查时用的就是这一层关系。ucounts则负责记账记录该命名空间内的进程数量和RLIMIT_NPROC配合实现用户进程数限制。pid_gid和hide_pid是给/proc文件系统用的。挂载proc时如果带上hidepid选项普通进程就看不到其他进程的目录这组字段就是为这个特性服务的。pid_gid指定哪个组有权限看全部信息hide_pid保存挂载时传入的隐藏等级。proc_mnt指向本命名空间对应的proc文件系统实例。每个pid namespace都有一套独立的/proc视图这个实例的根就存在这里。注意proc_mnt本身又是一个引用源——即使进程全退光了只要还有地方保持着这个proc挂载的引用kref就不归零namespace就无法释放。这是我排查句柄泄漏时最关注的字段之一。3. 用代码和系统调试验证结构体的行为3.1 同一进程两种PID理解一个内核结构体最好的办法是造一个场景看它的行为。最简单的验证是unshare# 宿主机上查看当前shell的PID记下来 echo $$ # 进入新的pid namespace并挂载新的proc unshare -pf --mount-proc bash # 此时在这个新shell里 echo $$输出结果是1。原因是在新的pid namespace中这个bash进程就是整个namespace的第一个进程也就是init进程自然拿到PID 1。但切换到另一个终端在宿主机视角用ps -ef | grep bash找到这个进程它的PID是另一个值比如11452。同一个task_struct在宿主机的pid namespace里编号11452在容器内的pid namespace里编号1。这不是伪装而是这个进程的struct pid里同时存了两个编号每个编号对应一个namespace。这个过程就是struct pid_namespace里那条idr在新namespace中完成了第一次登记。3.2 setns后的getpid不变pid namespace的特殊规则getpid缓存问题我专门做过测试。先写这么一段程序#define _GNU_SOURCE #include stdio.h #include unistd.h #include fcntl.h #include sched.h int main(int argc, char **argv) { if (argc 2) return 1; int fd open(argv[1], O_RDONLY); if (fd 0) return 1; if (setns(fd, 0) ! 0) return 1; pid_t p fork(); if (p 0) printf(child in new ns: getpid()%d\n, getpid()); else printf(parent after setns: getpid()%d\n, getpid()); return 0; }把这个程序编译后先创建一个新pid namespace再拿它的namespace文件路径作为参数运行。结果你会发现父进程的getpid()没有任何变化子进程拿到的却是一个和原编号完全不同的新PID。原因是setns修改的是nsproxy-pid_ns_for_children它并不会让调用者自己马上搬到新namespace。当前进程在自己的struct pid里的编号还是旧的所以单独调用setns后打印getpid()得到的还是旧值。只有下次fork时子进程才会按照新的pid_ns_for_children去登记新编号。这算是PID namespace和mount namespace一个很重要的区别。网上很多文章说setns进入pid namespace后getpid不变是glibc缓存的问题那是把现象解释错了。真正的机制是PID namespace对调用者本人就是下次生效glibc缓存只是加深了误解。如果你用/proc/self/stat直接解析PID结果也一样不变因为调用者真的没有换编号。3.3 如何从用户空间推断level和parentlevel和parent是内核内部字段用户态没有直接接口能读。但可以通过/proc/self/ns/pid这个虚拟文件的inode号来间接判断两个进程是否处于同一个pid namespace#include stdio.h #include sys/stat.h int main(void) { struct stat st; if (stat(/proc/self/ns/pid, st) 0) printf(pid namespace inode: %lu\n, st.st_ino); return 0; }同一namespace里的任何进程这个inode号都相同不同namespace则不同。当你在一层层嵌套的容器里运行这段程序每次得到的inode号都不一样这就是parent链逐层变化的外部表现。虽然看不到level的数值但你可以通过每进一层inode变一次来体会嵌套关系的存在。有个很容易忽略的点/proc本身也是跟着pid namespace走的。如果你在容器里没有重新挂载/proc那读到的是挂载时刻那个namespace的视图和当前进程实际所属的namespace可能已经不一致。这类姿势错误在内核调试现场几乎每周都能碰到。3.4 压一下pid_limit分配器是怎么扛不住的试着在一个pid namespace里快速创建大量进程for i in $(seq 1 100000); do (sleep 30 ) done一般跑到一半就会报Resource temporarily unavailable或者Cannot allocate memory。如果是前者多半是触发了RLIMIT_NPROC如果是后者并且确认内存足够就该怀疑是不是pid_allocated顶到pid_limit了。在分配器逻辑里到达上限后它会尝试扫描并回收stale pid如果回收不过来就返回-EAGAIN。用户态看到的就是fork失败。注意pid_limit是整个pid namespace共享的不是每个进程私有。一个容器里PID被占满其他进程哪怕只想fork一个线程都困难。这常被误报成内存耗尽实际上查/proc/sys/kernel/pid_max和当前分配量才是正路。4. 理解结构体之后那些经典故障就有了答案4.1 进程列表和信号隔离的边界到底在哪很多人以为容器里ps看不到宿主机进程是因为容器运行时做了什么过滤。其实单纯的pid namespace并不能隐藏进程——关键在/proc的挂载方式。如果不带--mount-proc进入新pid namespace你仍然看到的是旧的/proc里面一样有宿主机进程。同时信号的边界是由PID编号决定的。内核在发送信号时会解析目标进程在你当前namespace中的编号。你kill 1234如果1234这个编号在你当前的pid namespace里指向的是你的容器进程那就只影响它如果这个编号没有对应进程就报No such process。这才有了隔离的边界。有个很实用的经验判断一个进程能不能被某个容器操作不是看它在不在容器里而是看它的/proc/self/ns/pid和那个容器是不是同一个inode。用这个标准去排查误杀问题比猜容器运行时行为可靠得多。4.2 容器init进程退出后的级联清理容器主进程退出经常伴随容器内其他进程全部消失。这个现象用child_reaper来解释就很清晰。主进程就是当前pid namespace的init进程它一旦退出child_reaper就指向空。内核发现这个namespace失去了reaper会立刻对所有剩余进程执行清理流程。我排查过一个场景容器里有个监控脚本理论上主进程退出后脚本还能继续跑一会儿但每次都是瞬间消失。最初以为是监控脚本被杀死看了内核日志才发现是pid namespace的级联清理生效。这类问题如果你不理解child_reaper的角色会花很长时间去找一个根本不存在的凶手。4.3 僵尸进程堆积和namespace延迟释放僵尸进程和parent exit有关但很多人没意识到僵尸进程没有完全消失之前它持有的pid namespace引用也不会释放。换句话说只要还有一个僵尸进程赖在某个已死容器里那个容器的struct pid_namespace就会一直留在内存中idr里的编号也一直占着。更隐蔽的是proc_mnt引用。容器里的/proc被某个进程通过bind mount挂到了别的地方或者有fd一直打开着即使容器所有进程都退了kref也降不到0。我在排查容器停止后内存不释放时用lsof找出那些指向已删除/proc挂载点的fd问题就水落石出了。这类泄漏查起来非常费劲但一旦你知道struct pid_namespace有这些引用源排查方向就清晰很多。4.4 不要小看32层嵌套限制MAX_PID_NS_LEVEL这个限制很少被测试到但确实真实存在。它定义在include/linux/pid_namespace.h值为32。当你尝试在第32层里再创建一个pid namespace内核会直接拒绝。实际应用中一些沙箱产品会做多层嵌套外层容器装沙箱沙箱里再套一个隔离环境一不注意就叠了五六层。虽然离32还有距离但如果你做的是极深嵌套的运行时就需要提前把这个限制考虑进去。还有一点每多一层嵌套进程编号的翻译链路就会多一跳struct pid里的编号数组也会变长。所以不要无缘无故加深嵌套层级对性能和复杂度都没好处。最后分享一个我自己的调试习惯遇到任何和PID相关的内核诡异问题第一件事不是翻日志而是先确定当前进程的struct pid_namespace是谁/proc/self/ns/pid的inode号是多少和怀疑对象是不是同一套。这个判断一旦做对后面至少能省掉一半的排查时间。结构体里的字段一个个看过去你会发现Linux的隔离设计并不是堆上去的奇技淫巧而是每一个细节都在回答一个真实的工程问题。理解了它你再回头看容器的一些怪现象基本都能猜到内核在背后干了什么。