Linux pidfd 怎样减少 PID 重用误杀风险

当守护进程只保存一个 PID 数值时，目标进程退出后这个数值可能被内核分配给另一个进程。此时再调用 kill(pid, SIGTERM)，真正被操作的对象可能已经不是原来的任务。Linux 的 pidfd 把目标任务表示成文件描述符：拿到这个引用后，发信号、等待退出和清理都围绕同一个内核对象展开，因此能明显减少 PID 重用造成的误杀。

官方资料：https://www.kernel.org/doc/html/latest/、https://man7.org/linux/man-pages/man2/pidfd_open.2.html、https://man7.org/linux/man-pages/man2/pidfd_send_signal.2.html

最实用的判断是：如果程序需要长期管理一个可能退出并被替换的进程，就不要只保存 PID；先取得 pidfd，再用 pidfd_send_signal 操作它，用 poll/epoll 观察它的生命周期，最后关闭 pidfd。若进程由本程序创建，优先考虑在创建阶段直接取得 pidfd。

先分清 PID 数值和 pidfd 引用

PID 是进程在某个 PID namespace 中的数值标识，适合展示、日志和调用普通接口，但它本身不是一个带生命周期的对象句柄。进程结束后，内核可以把同一个数值重新分配给别的进程，保存 PID 的管理器就需要面对“我看到的还是同一个数字，但目标已经换了”的窗口。

pidfd 则是文件描述符形式的任务引用。pidfd_send_signal() 根据 pidfd 指向的任务发送信号，而不是再次根据一个可能已经过期的 PID 数值查找目标。目标终止后，对该引用的后续操作会反映原任务已经结束，不能静默地落到一个新任务上。

这并不意味着 pidfd 绕过权限检查，也不意味着获取 pidfd 之前的 PID 查找不存在竞态。如果管理器先从不可信来源拿到一个 PID，再调用 pidfd_open()，它仍然需要确认这个 PID 当时代表的就是预期任务；pidfd 的价值从“引用已经建立”开始体现。

用 pidfd_open 获取已有进程的引用

对于已经存在的进程，常见入口是 pidfd_open(pid, flags)。当前接口的 flags 通常传 0；返回值是一个文件描述符，成功后应像管理其他 FD 一样保存、传递并在生命周期结束时关闭。man-pages 还说明该描述符带有 close-on-exec 语义，能降低无意泄漏到后续 exec 程序的风险。

glibc 并不总是提供同名的便捷包装，低层程序可以通过 syscall() 调用系统调用。下面的示例只展示“打开引用并等待退出”的骨架；它没有执行目标进程，也没有把示例输出当作真实运行结果。

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

static int open_task_fd(pid_t pid) {
    // pidfd_open 返回的是稳定的任务引用，而不是新的 PID 数值。
    return (int)syscall(SYS_pidfd_open, pid, 0);
}

int main(int argc, char **argv) {
    if (argc != 2) {
        fprintf(stderr, "用法：%s PID\n", argv[0]);
        return EXIT_FAILURE;
    }

    char *end = NULL;
    long parsed = strtol(argv[1], &end, 10);
    if (*argv[1] == '\0' || *end != '\0' || parsed 

示例中的 poll 不是读取 pidfd 的内容。当前实现里，直接对 pidfd 调用 read 会失败；它的意义是让等待接口观察引用所代表的任务状态。错误路径也要关闭 pidfd，否则长期运行的管理器可能把每个被管理进程都变成一个 FD 泄漏。

用 pidfd_send_signal 操作同一个目标

拿到 pidfd 后，可以用 pidfd_send_signal(pidfd, sig, info, flags) 发送信号。flags 目前应传 0；调用者仍要满足信号权限和 PID namespace 关系。若原任务已经结束并被回收，系统会返回错误，而不是因为相同的 PID 已经被新任务占用就把信号送给新任务。

#define _GNU_SOURCE
#include 
#include 
#include 
#include 

static int signal_task_fd(int pidfd, int sig) {
    // info 传 NULL 时使用普通 kill 风格的信号来源，flags 保留为 0。
    return (int)syscall(SYS_pidfd_send_signal, pidfd, sig, NULL, 0);
}

int request_stop(int pidfd) {
    if (signal_task_fd(pidfd, SIGTERM) == -1) {
        // ESRCH 说明引用对应的任务已不存在，不能改用旧 PID 继续发送。
        perror("pidfd_send_signal");
        return -1;
    }
    return 0;
}

这里应该保留失败语义：EBADF 通常意味着句柄已经被关闭或不是 pidfd，EPERM 表示权限不足，ESRCH 则表示目标任务已经不存在。把所有错误都转换成“进程没响应”会让上层误判，也可能诱发危险的 PID 回退逻辑。

用 poll 或 epoll 观察退出，而不是轮询 PID

pidfd 可以交给 poll、select 或 epoll。当它指向的任务终止并进入 zombie 状态时，等待接口会报告可读事件；任务被回收后可以看到挂起事件。两种状态都应该被当成生命周期信号，而不是尝试从 FD 里读取文本。

如果管理器同时看多个任务，把 pidfd 放进现有的 epoll 集合通常比定时调用 kill(pid, 0) 更清晰：事件对象就是已经保存的引用，超时、重试和清理策略可以由同一个事件循环统一管理。这里的“可读”是内核对状态变化的通知，不代表有一段可读的进程输出。

创建阶段取得 pidfd，生命周期更容易闭合

如果目标进程由管理器自己创建，Linux 还提供通过 clone 或 clone3 配合 CLONE_PIDFD 取得 pidfd 的路径。这样可以把“创建子进程”和“保存对应引用”放进同一个设计里，避免先创建、后根据 PID 查找时的额外窗口。

对于作为子进程的目标，pidfd 还能与 waitid() 配合完成等待和回收。一个比较稳妥的职责划分是：pidfd_send_signal 负责对引用目标发信号，poll/epoll 负责接收生命周期事件，waitid 负责符合父子关系时的回收语义，close 负责释放管理器持有的文件描述符。不要用其中一个接口冒充另外三个接口。

三个容易误用的边界

pidfd 不是权限通行证

稳定引用只解决“目标是否换了”的问题，不能替代权限检查。跨 PID namespace 发信号、向不属于当前用户的任务发信号，都仍受内核规则约束。

pidfd 不是完整的进程监督器

它能提供对象引用和生命周期事件，但重启策略、退出码记录、超时升级为 SIGKILL、日志归属和资源隔离仍属于上层监督逻辑。

获取时机决定风险边界

对外部传入的 PID，先做身份确认再获取 pidfd；对自己创建的子进程，优先在创建阶段请求 pidfd。无论哪种方式，保存 pidfd 后不要在失败路径里偷偷退回到旧 PID 发送信号。

总结

Linux pidfd 的核心不是“把 PID 换成另一种写法”，而是把进程控制从容易过期的数值标识提升为文件描述符引用。已有进程用 pidfd_open 建立引用，信号用 pidfd_send_signal，退出观察交给 poll/epoll，父子回收按 waitid 的语义处理，最后统一 close。只要把这条生命周期边界保持完整，就能减少 PID 重用导致的误杀风险。

相关问题

pidfd 能完全消除 PID 竞态吗？

不能。它能保护已经建立的任务引用；如果在获取 pidfd 前就错误地把一个过期 PID 当成目标，问题仍然发生，所以创建时机和身份确认同样重要。

为什么不能直接 read pidfd？

pidfd 是用于引用和等待状态的描述符，不是进程输出流。应通过 poll、epoll 或适合的等待接口观察它。

进程退出后应该立即 close pidfd 吗？

当上层已经记录所需状态且不再需要等待或发信号时就应关闭；若还要完成父子回收或读取生命周期结论，则按对应接口的职责处理后再关闭。