Linux中不存在“init/systemd未及时回收孤儿进程”问题，因为孤儿进程被systemd收养后正常运行，真正需回收的是其退出后形成的僵尸进程；排查应聚焦PPID=1的长期运行进程及systemd对非服务进程不主动wait的特性。
先分清：孤儿进程 ≠ 僵尸进程
孤儿进程是活着的子进程，只是父进程没了，被 systemd（PID=1）收养了，PPID 变成 1，继续跑；
僵尸进程是已经死了的子进程，但父进程（或收养它的 systemd）还没调用 wait() 拿它的退出码，内核里还留着一条记录，状态为 Z。
所以你真正要排查和清理的，不是“孤儿进程”，而是它退出后可能变成的僵尸进程——尤其是当 systemd 没有主动 wait 它的时候。
查 PPID=1 的长期运行进程（识别潜在风险点）
虽然孤儿进程本身无害，但若它运行时间过长、资源占用异常，或退出后没人收尸，就可能埋下隐患。用这条命令找出被收养且已运行超 1 小时的进程：
ps -eo pid,ppid,etimes,comm --no-headers | awk '$2 == 1 && $1 != 1 && $3 > 3600 {print}'- 对每个输出的 PID，再执行：
ps -o pid,ppid,stat,etime,cmd -p <font color="green"><strong>PID</strong></font>，看它是不是还在R或S状态、命令是否可信、启动时间是否合理 - 特别注意
cmd字段里有没有可疑脚本、无名二进制、或大量打开文件（可用lsof -p PID验证）
确认 systemd 是否会自动回收它
systemd 只对它直接管理的服务（即通过 .service 文件启动的）保证 wait；对 shell 后台启动的孤儿进程（如 sleep 3600 &），它默认不主动等待——等它退出后，就会变成僵尸，卡在进程表里，直到 systemd 下次做周期性清理（行为因版本而异，不可靠）。
- 如果你发现某个孤儿进程退出后变成了 Z 状态，且 PPID 还是 1，说明 systemd 没及时回收它
- 这不是 bug，是设计使然：systemd 不监控所有收养进程的生命周期，只管自己启动的服务
- 验证方式：手动
kill -9 PID结束该孤儿进程，然后立刻ps aux | grep ' Z '—— 若出现 Z 状态且 PPID=1，就证实了这点
真正有效的清理与预防手段
与其等 systemd “想起来回收”，不如从源头控制：
- Shell 脚本中避免裸奔后台：
sleep 100 &→ 改成sleep 100 & wait或用setsid sleep 100 &让它彻底脱离会话，不依赖父 shell - 容器环境必须用
tini作为 init 进程（entrypoint），它专为处理僵尸而生，会自动 reap 所有子进程 - 自研服务代码里，fork 后务必配对
waitpid()；或至少设置signal(SIGCHLD, SIG_IGN)让内核自动回收（适用于不关心子进程退出码的场景） - 若已发现僵尸且父进程是 systemd（PPID=1），无法发 SIGCHLD 触发回收，唯一可靠办法是重启对应服务单元：
systemctl restart your-service.service，让 systemd 重建进程树
