企业官网建设流程全解析

干过几年Linux服务端开发的兄弟，应该都有过被信号折磨的经历。某个进程诡异退出、某个服务莫名卡住、某个后台任务怎么都杀不掉——排查到最后，十有八九都跟信号处理细节有关。上一篇我们把信号的产生、生命周期、默认动作这些地基过了一遍，这篇进入正题，专门聊那些让新手挠头、让老手也会翻车的地方：sigaction和signal的恩恩怨怨、信号集的本质操作、标准信号为什么会丢、实时信号怎么用、多线程程序里信号到底发给谁，以及我这些年踩过的信号坑和排查套路。

这篇是下篇，核心把"信号处理的高级玩法"和"实战中的信号问题"讲透。适合已经了解信号基本概念（比如SIGINT、SIGKILL、signal()函数）但想在工程里把信号用明白的同学，也适合那些被信号搞到怀疑人生的运维和后台开发。

1. 从signal()到sigaction()——信号处理函数的正确姿势

1.1 signal()的"黑历史"：为什么工程代码里没人用它

很多教材入门都是signal()，但你在真实项目里几乎看不到它。这不是因为它不能用，而是它的行为在各个系统上实在不够统一，而且有两个在工程上很致命的缺陷。

第一个缺陷是早期的System V实现里，信号处理函数执行完一次之后，信号处置会重置回默认动作。这意味着你第一次用signal(SIGINT, handler)注册好处理函数，进程收到SIGINT后调用了handler，但如果紧接着又来一个SIGINT，可能就直接走默认动作退出了。教科书里最经典的防死循环写法：

signal(SIGINT, handler);

如果handler里没有重新调用signal(SIGINT, handler)把自己再注册一遍，第二次SIGINT就能把进程干掉。而这个"需要重新注册"的行为在不同的Unix衍生版本上还不一样，BSD版本就不会重置，Linux完全继承了System V的这一套。同样的代码，换个平台跑起来行为直接分叉，这种不确定性在工程里是绝对不能容忍的。

第二个缺陷更隐蔽也更麻烦：signal()在信号处理函数执行期间，会阻塞当前正在处理的信号，但其他的信号并不保证阻塞。换句话说，如果handler正在执行，这时进程又收到了别的信号，那handler可能被一个新的信号处理函数打断。你的处理函数本来就在做某些很敏感的操作，结果被"嵌套调用"了，一旦处理函数不是可重入的，数据就乱了。

所以在后来的POSIX标准里，真正被推荐的接口是sigaction()。它不是简单地"注册一下"，而是把信号处理的所有细节都暴露给你：处理函数、信号掩码、标志位、可选的旧行为返回。工程上几乎所有严谨的信号处理代码，底层都是sigaction()。

1.2 sigaction()结构体使用详解

sigaction()的签名是：

#include <signal.h> int sigaction(int signum, const struct sigaction *act, struct sigaction *oldact);

核心是struct sigaction，里面几个字段我拆开讲：

struct sigaction { void (*sa_handler)(int); // 老式处理函数，或者 SIG_IGN / SIG_DFL void (*sa_sigaction)(int, siginfo_t *, void *); // 带信息的处理函数 sigset_t sa_mask; // 处理函数执行期间要额外阻塞的信号集 int sa_flags; // 一堆控制标志位 void (*sa_restorer)(void); // 已废弃，不要碰 };

sa_handler和sa_sigaction是共用同一块内存的，你只能二选一。想用带siginfo_t版本的话，要设sa_sigaction并在sa_flags里打开SA_SIGINFO。如果你只想用普通的handler，sa_handler就够了。

sa_mask是很多人忽略的细节。它指定的是：在处理函数运行期间，除了当前信号自动被阻塞之外，还要额外阻塞哪些信号。比如你写了一个handler需要操作某个全局链表，不希望被SIGUSR1打断，你就可以在sa_mask里加上SIGUSR1，这样handler跑的时候SIGUSR1会被挂起，等handler返回后再补处理。

sa_flags里最常用的是SA_RESTART。这个标志位在工程里能救你命，后面讲EINTR时会专门展开。还有SA_SIGINFO（启用siginfo_t）、SA_NOCLDWAIT（SIGCHLD通过waitpid等待时直接被丢弃细节）、SA_NOCLDSTOP（SIGCHLD不在子进程停止时产生），这几个我实际用过的场景也不同。

一个标准注册写法：

struct sigaction sa; memset(&sa, 0, sizeof(sa)); sa.sa_handler = my_handler; sigemptyset(&sa.sa_mask); sa.sa_flags = SA_RESTART; sigaction(SIGTERM, &sa, NULL);

注意我用了sigemptyset清空信号集，如果你直接不初始化就赋sa_mask，里面一堆随机比特位，等于随机阻塞一堆信号，这个bug排查起来极其隐蔽。我第一次在项目里这么干的时候，进程偶尔无故挂起，查了半天才发现是栈上未初始化的结构体导致。

1.3 可重入函数与volatile sig_atomic_t：处理函数里的安全红线

信号处理函数里最怕的一件事，就是"不安全的调用"。因为信号处理函数是异步执行的，它可能在你主程序执行到任何一条指令时突然插入。如果它调用了非可重入函数，而主程序刚好也在用那个函数，数据竞争甚至死锁就来了。

什么是不可重入函数？典型的像printf、malloc、free、strtok、getenv这一族，它们内部有静态缓冲区或者全局状态。比如printf，它内部可能加锁维护输出缓冲区，如果主程序刚进入printf，信号来了，handler里又调用printf，同一把锁被自己再锁一次，行为就是未定义的——运气好是输出乱序，运气差直接卡死。

安全的选择是只用可重入函数，比如write、read、open、sigaction这些系统调用级别的接口，或者自己写的不依赖全局状态的函数。如果实在需要在handler里标记某个状态，工程上推荐用volatile sig_atomic_t类型，它是C标准保证读写的原子性的一种整数类型，在信号处理函数里可以被安全地读写。典型用法是做标志位：

static volatile sig_atomic_t g_reload_flag = 0; void reload_handler(int sig) { g_reload_flag = 1; // 只做标记，不做重活 } int main() { struct sigaction sa; sa.sa_handler = reload_handler; sigemptyset(&sa.sa_mask); sa.sa_flags = 0; sigaction(SIGHUP, &sa, NULL); while (1) { if (g_reload_flag) { g_reload_flag = 0; do_reload(); // 重活在主循环里做 } // ...主业务逻辑 } }

我刚工作的时候，接过一个老项目，信号处理函数里直接调了malloc和printf，查一个诡异崩溃查了两周。后来把handler改成只置标志位、主循环里做实际逻辑，进程就再没出过问题。这条经验我现在每个项目都当铁律执行：信号处理函数里只干一件事，置标志位或者唤醒阻塞中的主循环线程，其他一律放到主逻辑里做。

2. 信号集操作与阻塞——让进程学会暂时"屏蔽"干扰

2.1 信号集sigset_t的本质：位图数组

sigset_t是信号集类型，本质是一个大位图（bitmap），每一个比特位对应一个信号编号。Linux下它内部是一个足够大的整数数组，每个信号的编号对应其中某一位。用位图的好处是操作成本极低，置位、测试、取反都是位运算。

信号集相关的五个基本操作函数必须闭眼能写出来：

#include <signal.h> int sigemptyset(sigset_t *set); // 清空整个位图 int sigfillset(sigset_t *set); // 将所有信号对应的位置1 int sigaddset(sigset_t *set, int signum); // 将signum对应的位置1 int sigdelset(sigset_t *set, int signum); // 将signum对应的位置清零 int sigismember(const sigset_t *set, int signum); // 测试signum是否在集合中

sigemptyset和sigfillset是起点。千万别忘了初始化，未经初始化就去sigaddset，等同于在一个随机位图上乱标，后果跟struct sigaction没初始化一样严重。

贴心提醒：SIGKILL和SIGSTOP这两个信号是"特等公民"，既不能注册自己的handler，也不能被阻塞，更不能被忽略。你就算把它们加进信号集里，内核直接无视。这是内核故意设计的逃生门——否则你写个程序把所有信号都屏蔽掉，系统就永远无法终止它了。

2.2 sigprocmask与sigpending：阻塞、解除阻塞、查询挂起信号

阻塞信号用的是sigprocmask()：

int sigprocmask(int how, const sigset_t *set, sigset_t *oldset);

how是三个宏之一：

• SIG_BLOCK：把set里的信号加到当前阻塞集合中。
• SIG_UNBLOCK：把set里的信号从当前阻塞集合中移除。
• SIG_SETMASK：直接用set替换当前阻塞集合。

三个都要配合信号集使用。最常用的场景是"临时屏蔽，再恢复"，代码模板长这样：

sigset_t new_set, old_set; sigemptyset(&new_set); sigaddset(&new_set, SIGUSR1); sigprocmask(SIG_BLOCK, &new_set, &old_set); // 这里执行的代码不会被SIGUSR1打断 sigprocmask(SIG_SETMASK, &old_set, NULL); // 恢复之前的屏蔽状态

注意最后恢复用的是SIG_SETMASK加上old_set。如果你用SIG_UNBLOCK，实际上是"从当前集合里移除SIGUSR1"，但在嵌套场景里，可能之前已经有人把SIGUSR1屏蔽了，你用SIG_UNBLOCK反而把别人的屏蔽也解除了。用SIG_SETMASK还原old_set是最安全的。

sigpending()用来查看当前有哪些信号被阻塞但已经挂起（pending）：

int sigpending(sigset_t *set);

它会返回一个信号集，里面标记了所有"已经被发送、但因为被阻塞而尚未递达"的信号。这个函数在排查"信号到底去哪了"的时候特别好用。有一次我怀疑一个SIGTERM丢失了，就在程序里某个检查点打印sigpending的结果，一看SIGTERM还在挂起集合里躺着，说明根本不是丢了，而是被某段代码屏蔽了还没解除。

说到"挂起"这个状态，有个容易踩的坎：标准信号不排队，如果同一个信号在阻塞期间被发送了多次，解除阻塞后只会递达一次。后面讲实时信号时会对比展开。

2.3 阻塞的典型场景：临界区保护

阻塞信号最常见的需求是保护临界区。比如你有一个全局配置结构体，更新它需要好几步操作：改几个字段、重新计算校验和、刷到共享内存里。如果不做任何保护，恰好在改了一半的时候来了个SIGINT，handler把服务热重载了，读取的配置就可能是一半新一半旧。

处理方式是：进入更新流程前先SIG_BLOCK屏蔽掉SIGINT、SIGHUP这类可能触发重载的信号，更新完再恢复。这样做的好处是信号不会丢，它被挂起在pending队列里，等你恢复屏蔽后再递达，重新加载一次就拿到新配置了。

另一个场景是主进程要优雅关停（graceful shutdown）。收到SIGTERM后，希望保证当前正在处理的请求完成，再退出。你可以先屏蔽SIGTERM，在业务处理的非关键点查询sigpending，确认有SIGTERM挂起，再开始走退出流程。这样避免了处理到一半被信号打断，也保证了在合理时间内对终止请求做出响应。

3. 可靠信号与实时信号——从"丢失"到"排队"的进化

3.1 标准信号为什么会丢

上一节提到标准信号不排队，这里展开讲背后的原理。Linux普通信号（1到31）的实现里，每个进程只有一张位图来记录挂起信号。位图只能记录"某类信号有没有pending"，不能记录"这类信号pending了几次"。

所以当进程阻塞了某个信号，然后在短时间内收到两次同样的信号，第一次把位图对应位置1，第二次再来的时候，发现位图已经是1了，就直接丢弃。等到解除阻塞，内核检查到位图是1，只会递达一次信号。这就是"信号丢失"的本质。

另外，Linux信号递达的时机也决定了它可能在某个环节被合并。如果两个相同的普通信号都在pending，第二次派发时发现proc的结构里已经标记了这个信号，就直接忽略新的。这种"合并"行为是内核有意的设计选择，目的就是高效——反正handler拿到的是"收到了信号"这个信息，至于收到几次，对大多数应用场景没区别。

但现实中，有些应用真是在意"收到几次"的，有些消息处理机制是基于信号计数实现的，这时候标准信号就能坑死人。

3.2 实时信号与排队机制

实时信号是范围在SIGRTMIN（Linux下是34）到SIGRTMAX（64）之间的一批信号，它们解决的核心问题就是"丢信号"。与标准信号不同的是，每个实时信号都维护了一个独立的排队队列，同一个信号即使连续发送几十次，也会全部排队。

你用siginfo_t里的si_value还可以携带一个整数或者指针值过去，接收方可以从siginfo_t里取出来。这一下子让信号从一个"粗粒度通知"变成了"可以带数据的消息"。

实时信号在低延迟场景下特别有用。比如一个后台服务用信号通知另一个模块有新的数据块到达，标准信号连着来10个可能只触发1次处理，数据块的索引就丢了；实时信号配合排队的si_value，一次不落全部递达，处理模块就知道该处理哪10个数据块。

我在一个网关进程里就干过类似的事：用SIGRTMIN+1作为新数据通知信号，处理线程收到信号后用sigwaitinfo取出si_value，拿到数据序号后直接从环形缓冲取数据。这样比在主循环里轮询环形缓冲索引效率高，而且实时性也更好。

3.3 sigqueue + sigwaitinfo 实战

发送实时信号用sigqueue()：

#include <signal.h> #include <signal.h> int sigqueue(pid_t pid, int sig, const union sigval value);

union sigval定义是：

union sigval { int sival_int; void *sival_ptr; };

可以传整数，也可以传指针。接收方用sigwaitinfo()或者处理函数里的siginfo_t来取：

#include <signal.h> int sigwaitinfo(const sigset_t *set, siginfo_t *info);

sigwaitinfo会阻塞等待set里的任意一个信号到达，比用pause或者忙等优雅得多。一旦有信号到达，它会返回该信号编号，同时把siginfo_t填好，里面有si_signo、si_pid、si_uid、si_value等信息。

一个典型的接收端伪代码：

sigset_t set; sigemptyset(&set); sigaddset(&set, SIGRTMIN+1); sigprocmask(SIG_BLOCK, &set, NULL); // 必须先阻塞，才能用sigwaitinfo接收 siginfo_t info; while (1) { int sig = sigwaitinfo(&set, &info); if (sig == SIGRTMIN+1) { process_data(info.si_value.sival_int); } }

注意，用sigwaitinfo接收信号的前提是这些信号要处于"阻塞"状态。因为sigwaitinfo把信号递达的天然流程绕过了，它直接从pending队列里取。如果不阻塞，信号会被默认动作处理掉，你根本等不到。这个顺序我在新手里看到反了不止一次。

还有一点，SIGRTMIN并不是一个固定数字，在有些架构或系统配置下实际值可能不同。代码里一定要用SIGRTMIN，不要自己硬编码34。为了保证使用实时信号，建议在代码里加一个编译期检查，确认SIGRTMIN+SIGRTMAX的组合合法。

4. 信号处理的内核视角——信号从内核到用户态的路程

4.1 信号的产生源头：硬件与软件

信号不是凭空冒出来的。一个完整的信号生命周期起始于"产生"。从源头分几类：

• 硬件异常类：比如SIGSEGV（非法内存访问，段错误）、SIGFPE（除零错误）、SIGILL（非法指令）。这类信号是CPU处理器在检测到异常后，通过异常处理机制触发，在内核态的异常向量中被转化成信号记录到进程的task_struct里。

• 终端按键类：Ctrl+C产生SIGINT，Ctrl+Z产生SIGTSTP。你的键盘输入经过tty设备，tty驱动检测到对应的字符串序列后，向前台进程组发送信号。这一层很多人没搞清楚：不是shell直接发信号，而是shell更底层的终端驱动干的。

• 软件条件类：包括kill、raise、alarm、setitimer、sigqueue这些，本质是系统调用或库函数向内核请求为某个进程创建信号。

有意思的是SIGPIPE（管道破裂）。当进程向一个读端已关闭的管道写数据时，内核在write路径上就会生成SIGPIPE给写进程，默认动作是直接终止进程。所以你在写管道程序时如果没屏蔽或处理SIGPIPE，一旦对端退出，你的进程会"莫名其妙"死掉。不少网络服务程序会在启动时屏蔽SIGPIPE或者设置signal(SIGPIPE, SIG_IGN)，原因就在这。

4.2 信号派发的内核路径与用户态的时机

信号被记录到进程的task_struct之后，并不是马上执行处理函数。内核的动作是"标记pending"，然后等待进程从内核态返回用户态之前，检查有没有pending信号需要递达。

这就是信号递达的黄金时机：进程从内核态切回用户态的那个边界。无论进程是被中断唤醒、系统调用返回，还是刚被调度上CPU，内核都会检查当前进程的信号pending队列。如果有信号要递达，并且没有阻塞，就进行递达动作。

递达动作的路径是这样的：如果信号有自定义的handler，内核会在进程的用户态栈上布置一个"信号处理帧"，伪造一个调用栈，把返回地址指到handler入口，同时保存当前程序的上下文（寄存器、指令指针、处理器状态）。然后进程从内核态返回时，"正好"跳到了handler里开始执行。handler执行完，通过特殊的系统调用sigreturn恢复之前保存的上下文，程序又回到之前被打断的位置继续跑。

这条路径里有一个工程上非常值得注意的点：如果进程的系统调用可以被信号中断（没有设置SA_RESTART），信号处理函数返回后，系统调用会返回EINTR错误。这是"信号处理完，但你的read/write被退出了"的底层原因。很多服务突然报EINTR并且开始空转，就是从这条路径上来的。

4.3 为什么信号处理函数里不能调用非可重入函数

结合上面这个"伪造栈帧中断正常执行流"的机制，你可以更深刻地理解为什么handler里要克制。

当handler被"插入"到进程的用户态执行流中时，它不是在主逻辑的某个安全点被调用的，而是在任意指令处被中断然后强行转入的。如果主逻辑此刻正在printf内部，已经拿到了一些内部锁，handler里再调用printf，就可能死锁或状态错乱。这种"任意点插入"的特性，就是信号处理函数必须使用可重入函数和volatile sig_atomic_t的根本原因。

此外，这与栈空间也有关。信号处理帧是压在用户栈上的，如果handler写得过深、递归调用太多，可能直接把栈压爆。比如主线程栈用了接近上限，突然来个信号，handler又要占用几百KB栈空间，直接就SIGSEGV了。这种bug特别诡异，因为问题出现在信号处理里面，而不是业务逻辑里。

5. 多线程程序中的信号——"发给进程"还是"发给线程"

5.1 线程与信号的关系

很多人的认知误区是"signal发给进程后，随便哪个线程处理都行"——这话对了一半，但细节里全部是坑。

POSIX标准规定：signal是进程级的，也就是同一个信号在被发送给进程时，任意一个"没有阻塞该信号的线程"都有可能被选中去处理。但如果某个线程通过pthread_sigmask屏蔽了该信号，内核在挑选线程时会自动跳过这个线程。

更关键的是，异步信号（由外部kill或者其他进程发来）只会被一个线程递达；而同步信号（比如SIGSEGV是因为某线程自己的非法内存访问产生的）会直接被递达给触发它的那个线程，这个行为是线程级的。

还有一点：如果进程里所有线程都屏蔽了某个信号，这个信号会一直挂在进程的pending集合里，没有线程能接收它。这种情况下用sigpending看的是线程特定的pending，换到进程角度还要结合线程组看，排查起来很绕。

5.2 pthread_sigmask设置线程信号掩码

在多线程程序里，给线程设置信号掩码要用pthread_sigmask，而不是sigprocmask。规范明确说明了sigprocmask在多线程环境下的行为是未定义的。pthread_sigmask的用法几乎一样：

int pthread_sigmask(int how, const sigset_t *set, sigset_t *oldset);

最实用的工程模式是：初始化线程之前，在主线程里用pthread_sigmask把想交给专用线程处理的信号屏蔽掉，这样新创建的线程会继承主线程的信号掩码。然后在子线程里重新放开这些信号，让它们只能被这个子线程接收。

我在设计网络框架时，会让主线程屏蔽所有业务信号（如SIGTERM、SIGUSR1），专门起一个"信号处理线程"，在这线程里sigwaitinfo等着。这样所有信号都在一个可控的线程里有序处理，不会出现多个线程同时抢一个信号、处理顺序乱的局面。同时主线程和其他工作线程也再也不用担心被信号随意打断，整个信号处理路径变成了"串行队列"，好调试多了。

具体代码框架：

// 主线程初始化阶段 sigset_t set; sigemptyset(&set); sigaddset(&set, SIGTERM); sigaddset(&set, SIGINT); sigaddset(&set, SIGUSR1); pthread_sigmask(SIG_BLOCK, &set, NULL); // 创建信号处理线程 pthread_t tid; pthread_create(&tid, NULL, signal_thread, &set); // 在signal_thread里 void *signal_thread(void *arg) { sigset_t *set = (sigset_t *)arg; siginfo_t info; while (1) { int sig = sigwaitinfo(set, &info); if (sig == SIGTERM || sig == SIGINT) { do_graceful_shutdown(); break; } else if (sig == SIGUSR1) { handle_reload(); } } return NULL; }

这个模式我强烈推荐给所有编写多线程服务端程序的人。它避开了信号在多个线程间随机选择的问题，也彻底解决了处理函数里"任意点插入"导致的竞态。

5.3 信号处理中的竞态与经典坑

多线程信号处理最容易踩的坑是：发送信号用的kill是进程级的，而sigwaitinfo的接收是线程级的。如果多个线程同时阻塞在一个sigwaitinfo上，同一个信号只会被其中一个线程接收并返回。这个"哪个线程被选到"是不确定的，所以如果业务上要求"某个特定线程处理信号"，其他线程必须通过pthread_sigmask屏蔽相关信号，或者用信号量机制做互斥。

另一个经典问题：主线程中调用pthread_create创建新线程时，新线程会继承当前信号的掩码。如果你在主线程创建线程之后才去pthread_sigmask屏蔽某信号，那些已经创建的线程不会受到影响，仍以创建时继承的掩码为准。所以在程序的初始化早期，就应该一次性把信号掩码设置好，然后基于这个掩码去创建线程。我见过一个项目，主线程在启动后期才屏蔽SIGTERM，结果一个工作线程还保留着不屏蔽的旧掩码，SIGTERM来了直接让那个工作线程退出了整个进程，优雅关停形同虚设。

还有fork和信号的一点关系：fork出来的子进程会继承父进程的信号处置（handler、忽略状态），但不会继承pending的信号集合。这一点在编写多进程服务按需重启时很有用，子进程启动时如果不想被父进程之前积累的pending信号干扰，可以主动清空或重新设置信号掩码。

6. 实战排查：那些年让我熬夜的信号坑

6.1 进程"无故退出"的排查套路

先说一个我自己被坑过很久的案例。有一个数据采集进程，偶尔会在运行几分钟后悄然消失。查日志没有任何输出，进程退出码也没有明确记录，看起来完全随机。

排查方法其实很系统：先看退出原因，再看信号，再看代码路径。第一步用系统日志，确认是不是被信号杀死的。对于直接被信号终止的进程，父进程可以通过waitpid拿到子进程的退出状态，用WIFSIGNALED宏判断是不是被信号杀死的：

int status; pid_t pid = waitpid(child_pid, &status, 0); if (WIFSIGNALED(status)) { int sig = WTERMSIG(status); // 拿到终止信号编号 }

有了信号编号，再回头查业务逻辑。我那次查出来是SIGPIPE，原因是一个内部通信管道往已关闭的对端写数据，写的时候没处理SIGPIPE，默认动作直接把进程干掉了。解决方式就是启动时统一signal(SIGPIPE, SIG_IGN)——但注意，这只是忽略信号让write返回EPIPE，你还要处理write的返回值和errno。

简单总结一下排查信号问题的流程：排查信号问题，第一步一定是确认"是什么信号"，然后确认"信号的来源和方向"，再结合代码上下文找原因。别一上来就盯着代码看，效率太低。

经验是，常遇到的"无故退出"原因多半就集中在SIGPIPE、SIGSEGV、SIGBUS、SIGABRT这几个上面。SIGABRT通常是assert或者abort()调起来的，SIGSEGV是野指针访问，SIGBUS大概率是内存映射文件访问越界，SIGPIPE就是管道对端关闭。这些信号在日志里一般都有对应关键字，核心转储文件（core dump）一定要打开，排查看信号问题core文件几乎不可或缺。

6.2 EINTR错误与SA_RESTART的取舍

EINTR是另一个高频坑：信号处理函数正常返回后，主程序里被中断的慢系统调用返回了EINTR错误。

先理解原因：慢系统调用（read、write、pause、wait等）可能在等待的时候被信号打断。如果handler执行完之后，系统调用不是被自动重新启动，而是直接返回错误，errno被设置为EINTR。这时的表现就是：进程活着，没有退出，但业务逻辑好像卡死或者空转了，日志里全是"read: Interrupted system call"。

解决方式有两个。一是给sigaction设置SA_RESTART标志，内核会在handler返回后自动重新启动被中断的系统调用：

struct sigaction sa; sa.sa_handler = handler; sigemptyset(&sa.sa_mask); sa.sa_flags = SA_RESTART; sigaction(SIGUSR1, &sa, NULL);

但SA_RESTART并不是对所有系统调用都管用。sleep、pause、sigwait、epoll_wait这类调用，即使设置了SA_RESTART，也依然会返回EINTR。这在工程上是个很重要的认知：你不应该在代码里假设SA_RESTART能覆盖所有场景。我见过很多服务在epoll_wait被EINTR打断后直接退出循环走cleanup，结果信号一来就相当于"重启了核心逻辑"，业务错乱。

推荐的通用写法是：在慢系统调用处显式处理EINTR，用循环重试：

do { n = epoll_wait(epfd, events, max_events, timeout); } while (n < 0 && errno == EINTR);

或者在read/write的地方做重试封装。有了这层处理，信号处理函数返回后主流程能自动恢复，不管SA_RESTART是否生效都不会出问题。这对长期运行的服务尤其重要，因为任何一次EINTR导致的意外分支都可能积累成一场事故。

6.3 handler延迟问题与实时信号的优先级

还有一个容易被人忽视的问题：信号处理的延迟。信号从产生到handler真正执行之间，会经过"发送->标记pending->返回用户态前检查->递达"的完整链路。如果进程一直在内核态执行某些不再返回到用户态的操作，或者信号被阻塞，handler的时机就不可预测。

在实时性要求高的场景里，比如工业控制器、自动化设备上的Linux程序，这种延迟是致命的。我做过的一个运动控制程序里，用标准信号SIGALRM去触发周期性的轨迹插值计算。结果发现有时候两个SIGALRM合并了，或者因为高优先级线程的调度延迟导致插值周期抖动，严重影响了运动平滑性。

后来改用实时信号SIGRTMIN，配合sigwaitinfo在一个高优先级实时线程里接收，加上sched_setscheduler设置为SCHED_FIFO调度策略，延迟和抖动都大幅降低。这个改进让我体会到了"实时信号"里"实时"二字的含义——它不只是不丢信号，更重要的是在排队和派发机制上更有保障。

还要提醒一句：信号处理函数本身执行时间越长，进程被"阻塞"在该处理函数里的时间越久，其他信号的递达和处理也会被推迟。如果你的handler里有耗时不短的操作，相当于把进程的整个响应路径都拖慢了。这也是为什么我一直强调，handler里一定要轻量，重活交给主逻辑。

6.4 信号处理函数中的死锁与"伪卡死"

最后一个常见的信号坑是"进程好像卡死但不退出"。这种情况通常是信号处理函数内部死锁了。

举个例子，一个多线程程序里，主线程持有一把互斥锁，正在临界区执行。此时某个线程触发了信号（或者外部发了信号），信号被递达，handler执行时试图获取同一把互斥锁——结果它自己持有锁，自己等锁，等锁过程中又被其他线程占用，死锁就出现了。这个过程如果不仔细看，表象就是进程不响应，日志也不输出，甚至kill -9都未必能处理（如果处于不可中断的睡眠状态）。

根本原因还是那句话：信号处理函数是异步插入的，它并不知道主程序当前持有什么锁。一旦handler和主程序在锁上有交集，死锁就是必然的。

解决这类问题，有两条路线：一是彻底规避，handler里不做加锁操作，只置标志位，让主线程在主循环里取锁处理；二是严格执行信号屏蔽纪律，在进入临界区前用pthread_sigmask把关键信号屏蔽掉，出临界区后再恢复。前者是"让handler无锁化"，后者是"让信号在错误时机不可达"，两者不是互斥的，可以同时采用。

排查这种"伪卡死"时，用gdb附加到进程上，看每个线程的堆栈，一般一眼就能看到两个线程互相等待锁。有时候还要用strace看系统调用的卡住位置，区分是卡在锁上还是卡在某个系统调用上。这两个工具配合起来，绝大多数信号导致的"卡死"都能快速定位。

最后几句掏心窝的话

信号这个东西，入门就是signal函数加几个宏定义，但真正在工程里不翻车，靠的全是对细节的敬畏。我自己总结下来，最核心的就五条：能用sigaction绝不用signal；信号处理函数里只置标志位，不干重活；多线程程序里一定用pthread_sigmask配合专用信号线程；慢系统调用一定要处理EINTR；排查信号问题先查信号再查代码。

这五条看着简单，每一条背后都是无数个加班的夜晚换来的。如果你现在正被某个信号相关的问题折磨得焦头烂额，希望这篇里的排查套路口诀能帮你少走一大截弯路。这篇文章里的所有经验，都是在实际项目里一行行代码和一次次gdb分析积累出来的，照着这个思路去梳理你的代码，大多数信号问题都能在一个可控范围内快速定位并解决。