Linux pidfd_open 如何避免 PID 复用误杀：pidfd_send_signal 的进程生命周期核对

服务守护脚本最危险的 bug 之一，不是信号发不出去，而是它保存的 PID 已经失效，随后这个数字被内核分配给了另一进程。脚本再次执行 kill(pid, SIGTERM) 时，表面上“找到了目标”，实际可能误伤无关服务。Linux 的 pidfd 方案把目标从一个会复用的整数 PID，换成一个指向特定进程的文件描述符。

需要避免 PID 复用竞态时，用 pidfd_open 获取稳定引用，再把这个 fd 交给 pidfd_send_signal；目标已经退出时，发送操作应以 ESRCH 作为失效证据，而不是重新对旧 PID 执行 kill。

为什么只保存 PID 会留下竞态

传统写法通常是启动子进程，记录它的 PID，过一段时间再用 kill 发送停止信号。竞态发生在两次操作之间：原进程退出，系统回收它的 PID；另一个进程随后拿到了同一个数字。此时旧的 PID 文件仍然存在，但它已经不能证明目标身份。

把“PID 数字”和“进程对象”分开看很重要。PID 适合做日志和人工定位，不能独自承担跨时间的身份凭证。pidfd 的价值正是在这个间隔里保留内核对具体任务的引用。

从 PID 到稳定引用：pidfd_open、PIDFD、pidfd_send_signal

pidfd_open 接收一个 PID，返回一个文件描述符；后续调用不再只依赖那个整数。下面的最小示例用系统调用接口展示核心关系，错误处理故意保留在现场，便于观察每个边界：

int pidfd = syscall(SYS_pidfd_open, pid, 0);
if (pidfd == -1) {
    perror("pidfd_open");
    return 1;
}

if (syscall(SYS_pidfd_send_signal, pidfd, SIGTERM, NULL, 0) == -1) {
    if (errno == ESRCH) {
        /* 目标已退出，pidfd 没有跟随 PID 复用 */
    } else {
        perror("pidfd_send_signal");
    }
}

这条路径可以压缩成三个真实节点：pidfd_open 建立引用，PIDFD 保存引用，pidfd_send_signal 使用引用发信号。它解决的是“目标身份被 PID 复用改变”的问题，并不自动授予发送信号的权限。

把发送信号与退出观察放在一起

如果管理器只关心“停止请求是否发出”，调用 pidfd_send_signal 之后即可等待服务自己的退出确认。但需要避免轮询 PID 时，可以直接把 pidfd 交给 poll 或 epoll。目标任务结束后，文件描述符会出现可读或挂起事件，随后再按程序的回收策略调用 waitid 等接口完成收口。

struct pollfd pfd = {
    .fd = pidfd,
    .events = POLLIN
};

int ready = poll(&pfd, 1, 5000);
if (ready > 0 && (pfd.revents & POLLIN)) {
    /* pidfd 对应任务已结束，继续做 wait/reap */
}

发送信号成功并不等于进程已经退出。实际验收要把两个状态分开：信号调用返回 0，只说明请求被接受；poll 返回并带有 POLLIN，才说明可以进入退出处理。若进程在发送前已终止，pidfd_send_signal 可能返回 ESRCH，这也是一个明确的生命周期结果。

三个边界决定方案能否落地

内核与 libc 接口

pidfd_open 从 Linux 5.3 引入，pidfd_send_signal 从 Linux 5.1 引入。man-pages 的示例使用 syscall，原因是 libc 可能没有对应的便捷包装。部署前先确认目标发行版的内核和编译环境，不要只在开发机上看到头文件就判断线上可用。

权限与 PID 命名空间

调用方仍需满足向目标发送信号的权限，并且必须位于目标 PID 命名空间或其祖先命名空间。容器里拿到的 PID 可能只是命名空间内视图；如果管理器跨容器操作，先核对 namespace 层级，再解释 EPERM 或 EINVAL。

退出与回收

pidfd 是稳定引用，不是自动回收机制。目标结束后仍要按照创建方式和子进程关系完成等待、关闭 fd 以及状态记录。对非子进程场景，不要把“观察到 fd 可读”误写成“已经拿到了退出码”。

什么时候继续用 kill，什么时候换 pidfd

一次性人工命令、目标不会跨越长时间保存、且没有 PID 文件复用风险时，kill 仍然足够直白。长驻守护进程、任务超时清理器、容器运行时或需要把信号和退出事件关联起来的管理器，更适合保存 pidfd，并把 fd 生命周期纳入状态机。

• 只需发一次信号：仍可使用传统接口，但要在同一控制流程中确认目标身份。
• 需要跨多个事件操作同一进程：创建 pidfd 后保存 fd，不要重新用旧 PID 查找。
• 需要等待退出：把 pidfd 接入 poll 或 epoll，再执行等待和清理。
• 遇到 ESRCH：记录目标已结束，停止对旧 PID 的补发和重试。

相关问题

pidfd 能彻底替代 PID 吗？

不能。PID 仍适合展示、日志和部分旧接口的兼容层；pidfd 主要替代它作为跨时间保存的目标身份引用。

pidfd_send_signal 返回 ESRCH 是权限问题吗？

通常不是。ESRCH 表示目标进程已经终止并被等待；权限不足更应检查 EPERM，无效 fd 则检查 EBADF。

拿到 pidfd 后还要保存 PID 文件吗？

是否保存取决于外部运维需求。若需要跨进程传递身份，要设计好 fd 传递或重新建立引用的协议；单独保存旧 PID 不能替代 pidfd。

为什么 poll 看到事件后还要 wait 或 reap？

事件只说明生命周期进入可观察状态，子进程资源和退出状态的回收仍由等待接口负责。把观察、获取状态、关闭引用拆开记录，排查时更容易定位遗漏。

收口检查

把进程管理从“记住一个数字”改成“保存一个稳定引用”，重点不在 API 名字多新，而在生命周期是否闭环：创建时确认内核能力，发送时区分 ESRCH 与权限错误，等待时观察 pidfd 事件，最后完成状态回收。只要这四步都能留下证据，PID 复用就不会再悄悄改变信号的目标。