Linux signalfd 怎样把信号转成文件描述符事件

在一个同时监听网络连接、定时器和管道的 Linux 服务里，退出信号如果还走异步 signal handler，处理逻辑就会被拆成两套：主循环处理文件描述符，信号处理器却在任意时刻修改共享状态。更麻烦的是，处理器里能安全调用的函数很有限，日志、锁和资源清理很容易变成隐患。

这个场景可以用 signalfd 收拢：先阻塞目标信号，再把信号集合交给 signalfd()，得到一个文件描述符，最后把它加入 epoll。信号到达后不再直接打断业务代码，而是变成可读取的 signalfd_siginfo 记录。

核心顺序是“先阻塞，再创建 signalfd，最后加入 epoll”。只创建 signalfd 而没有阻塞同一组信号，默认处理或旧的异步 handler 仍可能先接管信号；只读取一次也不够，非阻塞 fd 需要持续读到 EAGAIN。

故障现场：退出信号没有和网络事件走同一条路

假设服务已经有一个 epoll_wait() 主循环。收到 SIGTERM 时，旧代码在 handler 里直接设置全局变量；主循环下一次醒来才看到变量变化。这个做法表面简单，却有三个边界问题：

• handler 与主循环可能同时访问状态，变量本身即使是原子类型，关联的清理动作也不一定原子。
• handler 中不能随意调用日志、内存分配和锁相关函数，排错信息往往不完整。
• 一个线程阻塞了信号，不代表其他线程也按同样方式处理；多线程服务更容易出现“偶尔由另一个线程收到”的现象。

所以要先把问题改写成一个文件描述符问题：目标信号属于哪个集合、谁负责阻塞、哪个 fd 接收、主循环读到后设置什么退出状态。这样才有机会用已有的 epoll 监控和收尾路径来处理。

先阻塞目标信号，再创建 signalfd

signalfd(2) 的关键不是“注册一个新的 handler”，而是为调用进程创建一个接收信号的文件描述符。通常先用 sigemptyset() 和 sigaddset() 构造集合，再用 sigprocmask() 阻塞它。被阻塞的信号会保持 pending，之后由 signalfd 读取。

#include 
#include 
#include 

static int create_signal_fd(void) {
    sigset_t mask;

    // 只收拢服务生命周期相关信号，不能接收 SIGKILL 和 SIGSTOP。
    if (sigemptyset(&mask) == -1 ||
        sigaddset(&mask, SIGTERM) == -1 ||
        sigaddset(&mask, SIGINT) == -1 ||
        sigaddset(&mask, SIGHUP) == -1) {
        return -1;
    }

    // 先阻塞同一组信号，避免它们沿默认处理或旧 handler 路径离开。
    if (sigprocmask(SIG_BLOCK, &mask, NULL) == -1) {
        return -1;
    }

    // 非阻塞让主循环可以一次读空，CLOEXEC 防止 fd 泄漏到 exec 后的程序。
    return signalfd(-1, &mask, SFD_NONBLOCK | SFD_CLOEXEC);
}

这里的 mask 必须和阻塞动作使用同一组信号。SFD_NONBLOCK 让读取路径能在没有更多 pending 信号时返回 EAGAIN；SFD_CLOEXEC 则把文件描述符生命周期限制在当前进程映像内。创建失败时要保留 errno 现场，调用方负责决定是否终止启动。

为什么 signalfd 能和 epoll 放在一起

因为 signalfd 返回的就是文件描述符，epoll_ctl() 不需要知道它背后是信号，只需要把它当作一个可读对象。网络连接可以继续使用连接 fd，定时器继续使用 timerfd，退出与重载信号则由 signal fd 承担。事件循环只需要为每个 fd 约定一个稳定的类型标识。

#include 

enum event_kind {
    EVENT_SIGNAL = 1,
    EVENT_CLIENT = 2
};

static int add_signal_to_epoll(int epoll_fd, int signal_fd) {
    struct epoll_event event = {0};

    // 用 data.u32 区分信号 fd 和普通客户端 fd，避免把业务 fd 当成信号读。
    event.events = EPOLLIN;
    event.data.u32 = EVENT_SIGNAL;
    return epoll_ctl(epoll_fd, EPOLL_CTL_ADD, signal_fd, &event);
}

示例只展示静态映射，真正的服务通常还会把 fd 本身或连接对象放到 data.ptr。关键是不要依赖“第一个事件一定是信号”，也不要把信号到达的先后当成业务请求的顺序。epoll 给出的是当前可处理的就绪集合。

循环读取 signalfd_siginfo，不要只读一次

signalfd 的一次 read() 可能返回多个 signalfd_siginfo 结构。对于非阻塞 fd，正确的处理边界是：只要读到完整结构，就按 ssi_signo 分派；读到 EAGAIN，说明本轮已经读空；返回短长度或其他错误，则按异常路径记录并停止继续解释缓冲区。

#include 
#include 

static int drain_signal_fd(int signal_fd, int *should_stop) {
    struct signalfd_siginfo records[8];

    for (;;) {
        // 一次准备多个槽位，允许内核把当前 pending 信号批量交给用户态。
        ssize_t bytes = read(signal_fd, records, sizeof(records));
        if (bytes 

这里的循环有两个作用：处理批量记录，并把“暂时没有更多信号”与“发生读取错误”区分开。ssi_pid、ssi_uid 等字段可以用于审计，但不要把任何一个字段当成稳定的业务身份，具体含义应以信号类型为准。

多线程和 exec 场景是最容易漏掉的触发条件

如果服务在创建工作线程前就阻塞目标信号，线程通常会继承这份信号屏蔽字；如果线程创建后才阻塞，已有线程的屏蔽状态可能不同。工程上应把“设置 mask、创建 signalfd、启动工作线程”当成同一个启动阶段，不要让每个线程各自猜一套规则。

另一个常见问题是文件描述符继承。没有 SFD_CLOEXEC 时，服务执行外部程序可能把 signal fd 带过去，导致资源边界变得不清晰。即使当前服务暂时没有 exec，也建议在创建时设置该标志，而不是等到后面再依赖一次额外的 fcntl()。

修复动作：把信号处理变成主循环状态转换

收到 SIGTERM 后，不要在读取分支里直接释放所有连接。更稳妥的做法是设置一个“准备退出”的状态，让主循环停止接收新任务，再由统一的收尾函数关闭监听 fd、等待必要的工作、关闭 signal fd 和 epoll fd。SIGHUP 则可以只设置“需要重载”的状态，避免把重载和退出混在一起。

static void apply_signal_state(uint32_t signo, int *stop, int *reload) {
    // 状态转换只记录意图，真正的资源释放留在主循环安全点执行。
    if (signo == SIGTERM || signo == SIGINT) {
        *stop = 1;
    } else if (signo == SIGHUP) {
        *reload = 1;
    }
}

static void close_runtime_fds(int epoll_fd, int signal_fd) {
    // 关闭顺序与业务无关，但每个成功创建的 fd 都必须有明确归属。
    if (signal_fd >= 0) {
        close(signal_fd);
    }
    if (epoll_fd >= 0) {
        close(epoll_fd);
    }
}

这样改完后，复查重点不再是“handler 有没有执行”，而是四个可观察边界：目标信号是否已阻塞、signal fd 是否加入 epoll、读取是否持续到 EAGAIN、退出状态是否只在主循环安全点触发清理。

最后的检查清单

相关问题

signalfd 能接收 SIGKILL 吗？

不能。SIGKILL 和 SIGSTOP 不能被 signalfd 接收，把它们放进集合也不会改变这个限制。

为什么 signalfd 读取会返回 EAGAIN？

如果 fd 使用了 SFD_NONBLOCK，当前没有更多目标信号时，read 会以 EAGAIN 或 EWOULDBLOCK 表示已经读空，这不是信号丢失的单独证据。

signalfd 和 signal handler 应该二选一吗？

对同一组信号，最好明确一个接收路径。若同时保留旧 handler，要先梳理屏蔽字和线程归属，否则事件循环可能永远等不到本来想交给 signalfd 的信号。