Debian与红帽系发行版中kill(pid, SIGINT)行为差异排查

核心差异来自glibc版本及信号处理函数的默认行为差异，结合exec系列函数的信号掩码保留特性共同导致：

1. exec函数的信号处理规则
   exec系列函数仅会将自定义信号处理函数重置为SIG_DFL（默认终止/忽略行为），但不会修改进程的信号掩码。如果子进程在exec前阻塞了某个信号，exec后的进程会持续保持该信号的阻塞状态，导致信号无法被递送。

2. signal()函数的行为分化

   • CentOS 7使用的glibc 2.19及g++4.8.5中，signal()默认采用BSD风格：调用signal(SIGINT, handler)时，不会将SIGINT加入信号掩码，子进程信号掩码无阻塞。exec后SIGINT处理重置为SIG_DFL，父进程发送的信号可正常递送，触发进程终止。
   • Debian 12使用的glibc 2.36及g++12.2.0中，signal()默认遵循POSIX规定的System V风格：调用signal(SIGINT, handler)时，会自动将SIGINT添加到信号掩码中（阻塞该信号）。exec后信号掩码保持阻塞状态，父进程发送的SIGINT无法被递送到子进程，因此ping会执行完所有迭代，自定义循环程序也不会终止。

3. sigaction()尝试未解决的原因
   若你使用sigaction()时未显式设置SA_NODEFER标志，sigaction默认会阻塞当前处理的信号（与System V风格的signal()行为一致），exec后信号掩码仍保持阻塞，问题无法解决。

• 在子进程调用exec前，显式解除SIGINT的阻塞：

  sigset_t mask;
  sigemptyset(&mask);
  sigaddset(&mask, SIGINT);
  sigprocmask(SIG_UNBLOCK, &mask, NULL);
  

• 或使用sigaction()时设置SA_NODEFER标志，避免阻塞信号：

  struct sigaction sa;
  sa.sa_handler = your_handler;
  sigemptyset(&sa.sa_mask);
  sa.sa_flags = SA_NODEFER; // 关键：不阻塞当前信号
  sigaction(SIGINT, &sa, NULL);
  

内容的提问来源于stack exchange，提问作者user23642012