登录
推荐 文章 Go 技术 课程 下载 专题 AI
首页 >  文章 >  linux

Linux pidfd 如何避免按 PID 操作进程的竞态

来源:17golang原创

时间:2026-10-09 07:57:43 227浏览 收藏

我在做进程监管时,最容易低估的是“PID 只是一个会复用的数字”。如果程序先记住 PID,过一段时间再调用 kill(pid, SIGTERM),原进程退出而同一个数字已经分配给别的进程,就存在把信号发错对象的竞态。Linux pidfd 的解决方式是:尽早为目标任务取得一个文件描述符,后续围绕这个 fd 发送信号、等待退出和接入 poll/epoll。

要点速览
  • PID 适合做查询结果,跨时间控制进程时应保存 pidfd。
  • pidfd_open(pid, 0) 获取句柄,pidfd_send_signal 按句柄发信号。
  • pidfd 可以进入 poll/epoll,但线程目标、子进程创建和内核版本仍要单独处理。

先看竞态:PID 是数字,pidfd 是内核对象

PID 的生命周期和进程生命周期并不完全重合。一个进程退出、被回收后,内核可以把它的 PID 重新分配给另一个进程;如果监管程序把 PID 放进队列、定时器或重试任务,真正执行操作时就可能面对已经变化的对象。这个问题不是多加一次 kill 判断就能彻底消除的,因为“检查”和“使用”之间仍然有时间窗口。

pidfd 是内核返回的文件描述符,它指向目标任务的内核对象。描述符本身不会因为 PID 数字复用而自动改指向另一个进程,所以更适合作为跨异步边界保存的控制句柄。

对象适合做什么需要留意的边界
PID日志、查询、展示进程编号不能单独保证未来仍是同一任务
pidfd发信号、等待退出、接入 poll/epoll需要关闭 fd,并检查内核与权限支持
/proc/ fd读取进程信息的旧式入口不等价于可等待的 pidfd
Linux pidfd 结构说明图:PID、pidfd_open、pidfd 文件描述符与目标进程的静态关系
图1:结构说明图,PID 是定位输入,pidfd_open 将它转换为指向目标进程的文件描述符;这是静态关系示意,不是运行截图。

最小方案:先拿 fd,再监控和发信号

在需要控制一个已经存在的进程时,可以用 pidfd_open 获取 pidfd,再把它交给 pidfd_send_signal 或等待接口。glibc 没有为 pidfd_open 提供普通包装函数,示例因此直接通过 syscall 调用。下面的代码只展示接口关系,未在本机执行。

#define _GNU_SOURCE
#include 
#include 
#include 
#include 
#include 
#include 

static int open_pidfd(pid_t pid) {
    // flags 传 0,返回一个引用目标任务的文件描述符。
    return (int)syscall(SYS_pidfd_open, pid, 0U);
}

static int send_term(int pidfd) {
    // 按 pidfd 发信号,避免把稍后复用的 PID 当成同一对象。
    return (int)syscall(SYS_pidfd_send_signal, pidfd, SIGTERM, NULL, 0U);
}

int wait_process_exit(pid_t pid) {
    int pidfd = open_pidfd(pid);
    if (pidfd 

生产代码通常会先决定是否发送 SIGTERM,再等待 pidfd 变为可读;超时后是否升级到 SIGKILL,属于监管策略而不是 pidfd 自动提供的能力。目标退出并成为僵尸时,poll/epoll 可以观察到可读事件;被回收后还可能看到挂断事件。不要对 pidfd 调用 read 来获取退出信息,退出状态应通过适合的等待接口取得。

Linux pidfd 静态调用关系图:pidfd 文件描述符连接信号、poll/epoll 与进程退出状态
图2:关系说明图,展示 pidfd 文件描述符与 pidfd_send_signal、poll/epoll、目标进程和回收状态的静态连接,不代表真实执行顺序或终端输出。

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

第一,目标是已有进程还是将要创建的子进程。对已有进程可以调用 pidfd_open,但如果父进程担心子进程在获取 pidfd 前就退出,创建阶段更适合使用带 CLONE_PIDFD 的进程创建接口,并从创建结果直接得到 pidfd。

第二,进程和线程不是同一个观察对象。默认的 pidfd_open 面向进程;需要指向特定线程时,要确认内核支持 PIDFD_THREAD,并理解 poll 的可读时机可能与整个线程组不同。不要因为拿到了 fd,就默认它覆盖了所有线程。

第三,fd 不能绕过权限与兼容性。目标不存在会得到 ESRCH,文件描述符耗尽会得到 EMFILE,无效 flags 会得到 EINVAL。部署到老内核或受限容器时,要准备能力探测和清晰的降级策略;降级到 PID 操作时,应缩短检查与使用的间隔,并明确它重新承担了 PID 复用风险。

常见误用与检查清单

  • 只保存 PID、不保存 pidfd:把 PID 当永久主键,仍会留下竞态。
  • 每次重试都重新 pidfd_open:如果业务需要的是同一个目标,应复用原 fd,避免把新任务误当成旧任务。
  • 忘记关闭 fd:长时间监管会逐渐耗尽进程文件描述符额度。
  • 把 pidfd 当普通文件读取:它的价值是身份和事件语义,不是通过 read 返回文本。
  • 忽略回收者:子进程的退出状态仍要由父进程正确等待和回收,pidfd 不替代完整的子进程生命周期管理。

上线前我会按这张清单复查:句柄是否在创建后立即进入任务对象;超时路径是否关闭或转交 fd;信号范围是单个进程还是线程组;ESRCH、EAGAIN、EMFILE 是否分别记录;不支持 pidfd 时是否明确告警,而不是悄悄回到不安全的 PID 逻辑。

相关问题

pidfd 能完全替代 PID 吗?

不能。日志、命令行展示和部分查询接口仍然使用 PID;pidfd 主要替代的是跨时间的进程控制与生命周期观察。

pidfd_open 找不到进程怎么办?

先按 ESRCH 判断目标已经不存在,再结合业务决定丢弃任务、刷新目标,还是报告监管对象失效。

为什么不直接打开 /proc/进程号?

/proc/ fd 更偏向读取进程信息,不能提供 pidfd 的 poll 和 waitid 语义,也不能自然表达按任务句柄发信号。

声明:本文转载于:17golang原创 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>