孤儿进程被 PID 1 的 init 进程（或 systemd）收养；内核在父进程退出时硬编码将其 ppid 改为 1，确保所有顶层孤儿均由 PID 1 管理，且 init 仅负责退出后的资源回收，不干预运行状态。
孤儿进程被谁收养？内核硬编码保障
孤儿进程不会拖垮系统，根本原因是 Linux 内核在子进程父进程退出的瞬间，就强制将其 ppid 改为 1 —— 也就是 PID 为 1 的 init 进程（现代系统多为 systemd，但依然以 PID 1 身份运行）。这不是可选行为，而是内核路径中硬编码的逻辑：exit_notify() 函数里直接调用 forget_original_parent()，再通过 find_new_reaper() 指定新父进程为 PID 1。
这意味着：你无法绕过它。即使你用 prctl(PR_SET_CHILD_SUBREAPER, 1) 让某个普通进程当 subreaper，它也只能收养自己直系后代的孤儿，而**所有顶层孤儿（即原父进程非 subreaper）仍归 PID 1 管**。
init 只做“善后”，不干涉运行
很多人误以为 init 会“接管”孤儿进程的执行——其实完全不会。init 唯一做的就是等它退出后调用 waitpid(-1, NULL, WNOHANG) 回收资源。只要孤儿进程还在跑（比如一个长期运行的守护进程），init 就只是安静地当个名义上的“养父”，不发信号、不改调度、不重定向 stdin/stdout。
- 孤儿进程继续按原优先级、原 cgroup、原用户权限运行
- 它的文件描述符、内存、信号掩码全都不变
- init 不会主动 kill 它，也不会尝试读写它的管道或 socket
为什么桌面版 Ubuntu 看不到 ppid=1？
在较新桌面版 Ubuntu（如 22.04+ GNOME）中，你用 ps 查孤儿进程可能发现 PPID 不是 1，而是某个 session manager（如 gnome-session-binary）。这不是 bug，而是因为 systemd 启用了 Delegate=yes + 用户实例（user@.service）机制，让每个登录会话有自己的 subreaper 层级。此时真正收养的是该 session 的 manager，而非全局 PID 1 —— 但最终，这些 manager 自己仍是 PID 1 的子进程，资源回收链没断。
验证方法：用 ps -o pid,ppid,comm -p $PID 追一层父进程，大概率能看到它最终挂在 systemd --user 下，而后者又挂在 PID 1 的 systemd 下。
真正危险的不是孤儿，而是没回收的僵尸
孤儿进程本身不占资源；真正拖垮系统的，是大量未被回收的僵尸进程（Z 状态）。而孤儿进程恰恰**降低了僵尸风险**：因为 init 会定期轮询，只要它一退出，init 就立刻 wait() 掉它，释放 PID、内存页、打开的 fd 等。相比之下，如果父进程活着却忘了 waitpid()，子进程退出后就会卡在 Z 状态，直到父进程死亡或显式回收。
所以，与其担心孤儿，不如检查你的服务进程是否漏调 waitpid() 或设了 SIGCHLD handler 却没调 wait() —— 那才是僵尸温床。
