Linux pidfd_send_signal怎样向指定进程安全发送信号

Linux pidfd_send_signal 通过进程文件描述符发送信号。正确用法是先在目标身份可信时取得 pidfd，并在该进程实例的管理周期内持有它；需要停止时向同一个 pidfd 发送 SIGTERM。这样即使原进程退出、数字 PID 被复用，旧句柄也不会转而指向后来占用该 PID 的进程。

这里的“安全”指减少发错进程的竞争条件，并不代表绕过信号权限，也不代表 SIGTERM 返回成功就一定已经退出。示例只讨论管理器负责的普通进程，不扩展到线程定向或进程组广播。

Linux man-pages 官方项目地址：https://www.kernel.org/doc/man-pages/

停止请求必须绑定进程实例

假设任务管理器保存了某次工作进程的 PID。几分钟后，用户点击停止；如果工作进程早已退出，保存的数字就可能已经属于另一进程。此时直接调用 kill(pid, SIGTERM)，内核按调用当时的 PID 找目标，不知道应用原本想停止哪个任务。

先调用 kill(pid, 0) 再发信号，也不能把两次调用合成一次原子身份确认。中间仍有进程退出与 PID 复用的机会。sig 为 0 仅检查相应目标的存在性与权限，本身不发送信号。

pidfd 改变的是管理器保存的对象：任务记录里不只存数字，还保存绑定特定实例的句柄。它像文件描述符一样由管理器持有，但引用的是目标进程身份。业务任务编号仍要单独保留，用来关联用户请求和日志。

不过，若从一个过期 PID 文件中取出数字，等到发送前才调用 pidfd_open，获取句柄之前仍可能已经发生复用。成功打开只能说明绑定到了那一刻的目标，无法证明它就是几分钟前的旧任务。因此句柄要尽早取得，不能拿它弥补不可信的进程来源。

拿到句柄后把它放进任务记录

对于已有且身份可信的进程，可调用 pidfd_open(pid, 0) 取得 pidfd。对于管理器自己创建的子进程，可以研究在创建时使用 CLONE_PIDFD 直接取得句柄，减少从“创建返回PID”到“另行打开句柄”的身份管理负担。

如果采用 fork 后再 pidfd_open 的组合，必须保证子进程不会在这期间被提前回收。man-pages 特别列出了 SIGCHLD 被忽略、SA_NOCLDWAIT 或其他线程提前执行 wait 等会破坏相应保证的情况。多线程管理器应统一创建、回收与任务登记的职责，不能仅凭“这是我的子进程”就忽略这些条件。

任务记录可以包含 task_id、pid_for_log、pidfd、stop_requested 和 exit_observed。其中 pidfd 是当前进程里的文件描述符编号；不能把这个整数持久化到数据库后，期待管理器重启仍可直接使用。管理器恢复需要重新建立受控的进程关联方案。

用同一pidfd发送SIGTERM

下面是原创的管理器集成片段。它不解析任意用户输入，也不在函数内部重新查找 PID。调用方负责在可信绑定阶段取得句柄；发送阶段只接受已经持有的 pidfd。示例使用 syscall 形式，要求编译头文件提供对应 SYS 常量。

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

/* 仅在目标身份已有可靠来源时调用；成功返回由调用方负责关闭的句柄。 */
static int bind_process(pid_t trusted_pid)
{
    if (trusted_pid 

这两个辅助函数把系统调用的 -1 + errno 转成了负错误码；这种约定是示例自己的接口设计，不要与原始系统调用返回方式混淆。绑定成功后把 fd 放进任务记录，后续停止请求复用它，而不是重新把 pid_for_log 转回新句柄。

函数返回 0 时可记录“停止信号已请求”，不要直接写“任务已停止”。目标可以捕获、阻塞或忽略 SIGTERM；应用还可能需要完成清理。若设置停止宽限期，计时与后续动作也应关联同一任务记录和同一持有句柄。

把发送结果和退出结果分开记录

管理器需要独立的退出观察。pidfd 可以接入 poll 或 epoll；事件表示目标的相关退出状态已可观察，不能像管道一样调用 read 读取一段进程输出。进程日志仍应来自单独的日志文件或管道。

对于本管理器的子进程，可使用 waitid(P_PIDFD, ...) 取得等待信息并执行相应回收。普通非子进程并不会因为你持有 pidfd 就自动变成可 wait 的子进程；此时不能把 ECHILD 一概当作 pidfd 无效。

任务层应分别记录信号请求结果、退出事件和最终业务结果。比如信号已发送但仍在等待，或尚未请求停止就已经自然退出，这些都应有可表达的状态。子进程退出码、终止信号和业务输出是否完整，也不能由发送接口的返回值代替。

异常处理和句柄关闭一起设计

pidfd 并不授予额外信号权限。目标凭据、调用方身份以及命名空间关系仍受系统规则约束。部署时也要区分“创建句柄成功”和“具有发送信号权限”两个事实，不能把前者当成后者的保证。

关闭句柄应由单一所有者执行：先撤销事件监听、停止其他线程借用，再关闭 fd 并从任务记录移除。若一个线程关闭句柄，另一个线程仍用那个整数，描述符编号也可能被本进程复用；这会重新引入另一类资源管理错误。pidfd 解决目标 PID 身份稳定性，不替应用解决本地 fd 的并发所有权。

pidfd_send_signal支持哪些内核？

man-pages 记载发送接口从 Linux 5.1 引入，pidfd_open 从 Linux 5.3 引入。若使用本文两接口组合，需要同时满足它们的运行能力与编译头文件要求；不要仅按其中一个版本判断部署条件。

用0号信号能确认服务健康吗？

不能。它不执行应用层健康检查，也不能证明下一次请求时目标仍处于同样状态。服务是否能处理业务，应由服务自己的健康协议判断。

管理器关闭pidfd会让目标退出吗？

不会。关闭句柄只是释放管理器持有的文件描述符，发送信号、观察退出和回收子进程分别是其他操作。

接口资料：https://man7.org/linux/man-pages/man2/pidfd_send_signal.2.html；https://man7.org/linux/man-pages/man2/pidfd_open.2.html；https://man7.org/linux/man-pages/man2/waitid.2.html。