1. 先搞明白信号到底是什么1.1 一个容易被忽略的进程通信方式很多人学Linux入门第一课肯定是文件操作、进程管理、网络编程等到真正碰见信号往往是程序莫名其妙死了系统弹出一句Segmentation fault (core dumped)才知道有这么个东西。信号signal本质上是内核发给进程的一条短消息告诉进程某件事件发生了。它没有复杂的数据结构就是一个整数编号——编号1到64每个编号代表一个预定义的事件。比如11号SIGSEGV代表非法内存访问2号SIGINT代表你按了CtrlC15号SIGTERM代表有人要求结束进程。你可以把它类比成手机上的来电提醒进程正在专心做自己的事情执行用户代码突然收到一条通知它可以选择挂掉默认动作、无视忽略、或者接起来处理一下自定义handler。整个过程完全异步——进程自己不知道信号什么时候来也无法预测下一秒会收到哪条通知。信号栈则是这套机制里最微妙、也是新手最容易忽略的一环。它解决的是一个非常实际的问题当信号到达时中断处理的那段代码handler到底在哪块内存上运行是正常的用户栈还是一片独立的备用空间想通这一点你对进程崩溃、调试、甚至后端服务的稳定性保障都会有完全不一样的理解。这篇文章我会从信号是什么讲起把信号从产生到处理的完整流程捋一遍然后重点拆解信号栈的原理和用法最后附一份可直接上手的实战代码和避坑清单。无论你是刚刚接触Linux的小白还是在排查生产环境问题的开发应该都能找到自己需要的那块拼图。1.2 信号从哪来三种主要来源分类信号的产生来源大体可以分为三类硬件异常、终端操作、软件条件。硬件异常是进程自己捅的娄子。比如你写了一个野指针进程访问了非法地址CPU在取指或读取内存时发现不对就触发一个异常内核把异常翻译成SIGSEGV送给进程除零会触发SIGFPE执行非法指令会触发SIGILL。这类信号的特点是它们不是外部主动发的而是进程自身执行过程中的事故报告。终端操作是最直观的。你按下CtrlC终端设备驱动检测到组合键把SIGINT发给前台进程组按下Ctrl\发SIGQUIT按下CtrlZ发SIGTSTP挂起。这里有一个容易被忽略的细节信号的发送方不是终端进程而是内核通过try发送机制完成的。第三种是软件条件与显式调用。子进程退出时父进程收到SIGCHLD定时器到期触发SIGALRM往已关闭的管道写入数据触发SIGPIPE进程A调用kill(pid, sig)主动给进程B发信号进程自己调用raise()给自己发信号。这类信号的生成逻辑完全由内核和系统调用控制。对比其他进程间通信手段——管道、消息队列、共享内存——信号是唯一的异步事件通知机制。共享内存需要双方协商格式管道需要轮询读取只有信号能在任何时候打断进程要求它立刻响应。这也是信号能够承担进程级紧急通知职责的根本原因。1.3 常用信号速查表与默认动作下表列出我日常开发中最常碰见的信号也顺带标注默认动作方便你快速建立认知。信号编号默认动作典型触发场景SIGINT2终止进程终端 CtrlCSIGQUIT3终止并生成 core终端 Ctrl\SIGKILL9终止不可捕获/屏蔽kill -9 强杀SIGSEGV11终止并生成 core空指针、非法访问SIGPIPE13终止进程写入已关闭管道SIGTERM15终止进程kill 命令默认信号SIGCHLD17忽略子进程停止/退出SIGUSR110终止进程用户自定义SIGUSR212终止进程用户自定义SIGSTOP19挂起不可捕获CtrlZ 调试挂起需要特别强调SIGKILL 和 SIGSTOP 是霸王信号进程不能捕获、不能屏蔽、不能忽略。只要内核递送了SIGKILL进程必死无疑——这是内核保证系统不会出现杀不掉的进程的兜底机制。而SIGCHLD配合wait/waitpid是后端服务守护子进程最常用的组合拳。此外还有实时信号编号从SIGRTMIN起通常为34到SIGRTMAX通常为64。传统信号不排队同一信号多次到达只记录一次实时信号支持排队且携带整数或指针数据。平时写应用层用不太到但在高并发任务分发、实时系统里很有价值。2. 信号的一生从产生到处理的完整链路2.1 信号的三种处理方式一个信号送达进程之后进程有三条路可走。第一种是默认处理。内核预定义了每个信号的默认动作比如SIGTERM默认终止进程、SIGCHLD默认忽略、SIGQUIT默认终止并生成core文件。如果你没有做任何配置信号到来时内核按默认动作执行。第二种是忽略处理也就是SIG_IGN。把某个信号的处理函数设置为SIG_IGN之后内核不会再让这个信号打扰进程。但再次强调SIGKILL和SIGSTOP不能忽略。这是一个容易踩的坑——有人想在程序里屏蔽CtrlC觉得把SIGINT设为SIG_IGN就行了这没问题但要是想着把SIGKILL也屏蔽掉那就想多了。第三种是捕获处理自定义handler。通过signal()或sigaction()注册一个函数信号到来时内核会切换到用户态执行这个函数执行完再回到原来被打断的地方继续运行。这是最常用也最需要小心的方式。经典例子一个守护进程收到SIGTERM需要在退出前释放资源、重写配置文件、记录日志。这就是典型的捕获SIGTERM做优雅退出。另一个例子MySQL在收到SIGTERM后做InnoDB刷盘然后才关闭进程。2.2 信号屏蔽、未决与递送的细节逻辑信号不是到了就立刻处理这么简单中间还有一个未决pending状态。每个线程都维护着一个信号掩码signal mask本质上是一个bitmap每个位对应一个信号编号。当一个信号被屏蔽时内核不会立刻让进程处理它而是把这个信号标记为未决状态放在一个等待队列里。直到进程解除对它的屏蔽内核才会执行真正的递送delivery动作。这里有一个让很多新手困惑的细节标准信号不排队。什么意思呢如果SIGINT已经被标记为未决你又连按了三次CtrlC内核不会攒三个SIGINT而是维持有一个SIGINT等待处理的状态。因为每个标准信号在pending集合里只有一个位。相比之下实时信号之所以实时一个重要特征就是每个实时信号可以排队多次带数据可以累积。在实际的代码里这种丢失未必是坏事。比如重启服务时你发了两个SIGTERM进程只需要处理一次就够了。操作信号掩码的系统调用是sigprocmask()或pthread_sigmask()。在线程环境下必须用pthread_sigmask因为sigprocmask在线程库中的行为未明确定义。这不算冷门知识但在生产环境的排查中我见过不少人因为这个踩坑。2.3 信号与系统调用为什么会出现 EINTR这是面试中几乎必问的一道经典题为什么慢速系统调用会返回EINTR原因在于如果一个进程在read()或write()这类慢速系统调用中被信号打断系统调用会返回-1而errno被设置为EINTR。换句话说信号不只是通知它还会打断正在进行的系统调用。为什么内核要这么设计因为信号优先级更高——既然进程已经收到一个需要处理的信号那就先把系统调用挂起让进程去跑handler回来之后再决定继续系统调用还是放弃。这是Unix为了保证信号响应及时性做出的取舍。解决EINTR问题有两条路。一条是在调用点手动循环重试// 重试被中断的read直到读到数据或真正出错 while ((n read(fd, buf, sizeof(buf))) -1 errno EINTR) ;另一条是注册信号处理时设置SA_RESTART标志。设置了SA_RESTART之后内核在执行完handler返回用户态时会自动重启被中断的系统调用用户代码根本感知不到中断发生过。但SA_RESTART也不是万能的比如select、poll、epoll_wait这类等待类系统调用在Linux上仍然可能返回EINTR。所以在高并发网络编程里检查EINTR几乎是必须的。这是我在处理几十万连接服务时最深的体会之一。3. 信号栈给信号处理函数准备的独立战场3.1 用户栈、内核栈与第三个栈理解了信号的整体流程现在进入正题信号栈。要理解信号栈得先区分两个概念用户栈和内核栈。每个用户态进程都有一块随进程而生、由用户态分配使用的栈区叫用户栈。我们在代码里声明的局部变量、函数调用的返回地址、参数传递全都存在这里。默认大小通常在8MB左右受ulimit -s控制。函数每调用一层就往栈上压一个帧返回时弹出。同时每个进程还有一块内核栈它是内核态执行代码时使用的独立栈。用户态切内核态时栈指针会从用户栈切到内核栈两个栈互不干扰这就保证了即使你用户态栈乱成一团内核代码依然可以稳定运行。那么信号栈在哪里信号栈有两种理解。第一层理解当内核决定递送一个信号并执行自定义handler时它会在进程的当前栈上压入一个signal frame——这个frame保存了被中断的上下文寄存器、指令指针、信号掩码等然后在同一个栈上把新的返回地址和参数布好再跳转到handler入口。所以任何一次信号处理都会在当前栈上留下痕迹这也是为什么你可以在栈上看到signal frame。第二层理解Linux提供了一种机制可以给信号处理分配一块独立的、替代性的栈通过sigaltstack()系统调用配置。配置之后只要handler注册时带了SA_ONSTACK标志内核就不在原有的用户栈上构造signal frame而是切换到一个全新的备用栈上执行handler。这个备用栈才是中文语境里常说的信号栈alternate signal stack。如果你从没显式调用过sigaltstack那么信号处理始终发生在正常的用户栈上。这也是大多数程序的默认行为。3.2 什么时候必须使用独立信号栈正常情况下在用户栈上处理信号完全没问题。但有两种极端场景会让信号处理也发生在用户栈上成为灾难。第一个场景是栈溢出本身。比如递归函数无限调用用户栈已经顶到了栈底附近再往前压一帧就触发页错误内核发SIGSEGV。此时如果handler继续在用户栈上执行它需要再压一个signal frame和handler自己的栈帧这个压入的动作又会触发页错误再发一次SIGSEGV于是进程直接死锁在异常循环里。你可以试试看一个爆栈程序连gdb的backtrace都可能打不出来——因为它没有一块干净的栈可用。如果有独立信号栈情况就完全不同栈溢出触发SIGSEGV后内核把handler放到备用栈上handler得以在干净的内存环境中运行打印错误信息、记录日志、甚至触发进程重启。这是故障自救的关键手段。第二个场景是协程与用户态线程。Go的runtime、各种协程库经常给协程分配很小的栈几KB到几十KB。如果某个协程正在执行时收到信号内核会在当前用户栈——也就是协程那一小块栈上构造frame。一个很小的栈可能连一个signal frame都放不下。而实际上Go runtime在早期版本确实因为这个问题吃过不少苦头。解决方案之一就是给信号处理预留sigaltstack确保无论线程当前跑在哪块小栈上都有一块固定的安全区。3.3 sigaltstack 与 SA_ONSTACK 如何配合sigaltstack()是配置备用信号栈的唯一入口。它的重点结构是stack_ttypedef struct { void *ss_sp; // 栈区起始地址低地址方向 int ss_flags; // 标志0、SS_DISABLE、SS_ONSTACK size_t ss_size; // 栈区大小字节 } stack_t;调用方式stack_t ss; ss.ss_sp malloc(SIGSTKSZ); ss.ss_size SIGSTKSZ; ss.ss_flags 0; if (sigaltstack(ss, NULL) -1) { perror(sigaltstack); exit(1); }这里SIGSTKSZ是系统建议的默认大小。注意在有些glibc版本中SIGSTKSZ是动态值而不是编译期常量这意味着你不能简单声明一个静态数组char stack[SIGSTKSZ]而应该用malloc或mmap动态分配。这个细节在交叉编译和设备移植时特别容易踩坑。仅仅配置了sigaltstack还不够注册信号处理时还必须带上SA_ONSTACK标志内核才会在递送这个信号时使用备用栈struct sigaction sa; memset(sa, 0, sizeof(sa)); sa.sa_sigaction my_handler; sa.sa_flags SA_SIGINFO | SA_ONSTACK; sigemptyset(sa.sa_mask); sigaction(SIGSEGV, sa, NULL);逻辑上可以这样记忆sigaltstack相当于划拨了一块操场SA_ONSTACK相当于宣布本次活动在这个操场举行。两者缺一不可。如果只配置sigaltstack但handler没有SA_ONSTACK信号照常在用户栈上处理如果注册了SA_ONSTACK但没有配置sigaltstack内核会默默忽略这个标志并退回用户栈处理——不会给你报错。3.4 内核切换信号栈的完整过程再往深一层内核在递送信号并决定使用备用栈时到底发生了什么我尽量讲清楚这个流程。首先进程的task_struct中维护了两类栈相关字段一类是内核栈一类是用户态备用栈sas_ss_sp、sas_ss_size、sas_ss_flags。sigaltstack()系统调用修改的就是后者。当某个信号满足递送条件内核逐项检查当前信号是否被屏蔽屏蔽则放入pending队列。进程是否注册了handler没有则执行默认动作。handler的sa_flags是否设置了SA_ONSTACK设置了且备用栈存在、当前不在使用中则使用备用栈。如果决定切换到备用栈内核会在备用栈上压入rt_sigframe结构。这个帧保存了被中断现场的所有信息通用寄存器、指令指针、栈指针、信号掩码以及siginfo数据。帧的末尾还会写入一个特殊的返回地址指向__restore_rt在VDSO中它的作用是执行rt_sigreturn系统调用。接下来内核恢复用户态寄存器但把用户态的栈指针SP切换到备用栈的合适位置把指令指针IP设置为handler入口。然后进程从用户态开始执行handler。handler执行结束后return语句实际不是普通的函数返回而是跳转到__restore_rt发起rt_sigreturn系统调用。内核根据刚才保存的frame把所有寄存器恢复成信号到达前的样子——包括栈指针从备用栈切回原来的用户栈。至此一个信号处理周期完成。理解这个流程后你会发现一个关键点信号handler并不是在一个平行世界运行而是借用栈构造了一个临时执行环境处理完之后再干净利落地回到原来的断点。备用信号栈的作用就是当临时环境的地基不可靠时提供一块稳固的地面。4. 实战演示用备用信号栈接住一次栈溢出4.1 设计一个必然崩溃的实验理论说再多不如动手跑一遍。我来演示一个最能体现备用信号栈价值的场景递归爆栈。程序逻辑非常简单main函数先分配一块备用栈再注册SIGSEGV处理函数带SA_ONSTACK然后调用一个无底线的递归函数。正常情况下递归会一直压栈直到用户栈触底触发SIGSEGV。我们预期看到的现象是进程没有直接崩溃消失而是在备用栈上打印出错误信息然后主动退出。这个实验的目的有三个一是亲眼确认SIGSEGV被handler接到了二是观察handler确实运行在备用栈上可以通过打印当前栈地址来对比三是验证即使主栈已经炸了handler还是能正常工作。这里要说明一点在handler里打印地址信息不能用printf。因为printf内部会加锁、可能会分配内存而这些操作都不是异步信号安全的。在信号处理函数里最稳妥的做法是只调用write、_exit这类async-signal-safe的系统调用。下面的代码展示了一个不依赖printf的地址打印方式也顺便体现了信号处理函数的安全边界。4.2 完整代码与逐步说明#define _GNU_SOURCE #include stdio.h #include stdlib.h #include string.h #include signal.h #include unistd.h // 十六进制转换表用于手写地址输出 static const char hex_digits[] 0123456789abcdef; static const char segv_msg[] Caught SIGSEGV, fault addr0x; // 只使用异步信号安全函数的地址打印 static void print_hex_addr(void *addr) { char buf[16]; unsigned long v (unsigned long)addr; for (int i 0; i 16; i) { buf[15 - i] hex_digits[v 0xf]; v 4; } write(STDERR_FILENO, buf, sizeof(buf)); } // 信号处理函数运行在备用栈上 static void segv_handler(int sig, siginfo_t *info, void *context) { write(STDERR_FILENO, segv_msg, sizeof(segv_msg) - 1); print_hex_addr(info-si_addr); write(STDERR_FILENO, \n, 1); // 注意这里不能用exit()它可能调用atexit钩子 // 这些钩子可能访问锁或堆不安全 _exit(1); } // 无限递归制造栈溢出 static void explode_stack(void) { volatile char pad[2048]; pad[0] 1; explode_stack(); } int main(void) { stack_t ss; struct sigaction sa; // 1. 配置备用信号栈 // 注意SIGSTKSZ 在较新 glibc 中可能是动态值不能用静态数组 ss.ss_sp malloc(SIGSTKSZ); if (ss.ss_sp NULL) { perror(malloc); return 1; } ss.ss_size SIGSTKSZ; ss.ss_flags 0; if (sigaltstack(ss, NULL) -1) { perror(sigaltstack); return 1; } // 2. 注册SIGSEGV处理器指定SA_ONSTACK memset(sa, 0, sizeof(sa)); sa.sa_sigaction segv_handler; sa.sa_flags SA_SIGINFO | SA_ONSTACK; sigemptyset(sa.sa_mask); if (sigaction(SIGSEGV, sa, NULL) -1) { perror(sigaction); return 1; } // 故意打印一下当前主栈地址便于和备用栈对比 char local_var; printf(Main stack top approx: %p\n, (void *)local_var); // 3. 触发爆栈 explode_stack(); // 到达不了这里 return 0; }编译与运行gcc -o sigstack_demo sigstack_demo.c ./sigstack_demo程序运行后会先打印主栈上某个局部变量的地址然后一路递归。当栈触底时触发SIGSEGVhandler接管在备用栈上打印错误信息和触发地址最后退出。运行输出大致长这样Main stack top approx: 0x7fff3f4c2e20 Caught SIGSEGV, fault addr0x7fff3f4c2fe0如果你把SA_ONSTACK注释掉再编译运行大概率会在输出几行之后直接结束可能连Caught SIGSEGV都看不到。原因正是前面说的handler还想在已经爆掉的用户栈上压帧直接诱发二次异常。一个更直观的验证方法是在segv_handler里再声明一个局部变量把它的地址打印出来和崩溃地址对比。如果备用栈生效你会发现handler栈帧的地址与主栈地址不在同一个地址区间内。4.3 运行结果与关键验证点实际执行后我发现两个值得注意的细节。第一个细节是打印出的fault addr往往不是精确的栈底地址而是略高栈向下增长。这是因为触发SIGSEGV时CPU要访问的地址是栈边界之外的下一个页面这个地址反映了触底失败的具体位置。通过它你可以直观感受到地址空间里栈的边界在哪。第二个细节是SIGSTKSZ的取值。在x86-64的现代glibc上SIGSTKSZ通常是8192字节以上而MINSIGSTKSZ大约是2048字节。如果你在嵌入式设备上把备用栈配得太小handler一进去就可能再次段错误。我建议在生产环境把备用栈至少设为SIGSTKSZ如果handler里要做日志落盘、错误信息格式化这类稍重的操作甚至可以给到64KB以上。毕竟备用栈只是应急跑道通常不会复用。5. 常见问题与避坑指南5.1 你可能踩过的几个高频坑第一个坑在信号处理函数里使用printf或malloc。这是最典型、也最容易中招的问题。printf内部有锁如果信号到达时主程序刚好在printf内部持锁handler里的printf就可能死锁。malloc同样不是异步信号安全的因为malloc内部维护堆状态可能在分配中途被信号打断再次进入malloc就破坏了堆结构。正确做法是只用write、read、open、_exit等async-signal-safe函数。如果你非要打印复杂信息可以先把内容写到一个预分配的缓冲区里用原子标志通知主程序稍后处理。第二个坑混淆signal()和sigaction()。signal()是C标准库提供的简单接口但不同系统的语义有差异更重要的是在某些平台上信号处理完后会自动重置为默认动作。sigaction()是POSIX推荐的接口支持SA_RESTART、SA_SIGINFO、SA_ONSTACK等精细控制。看任何Linux服务端代码规范写法一定是sigaction而不是signal()。我的建议是一律用sigaction。第三个坑以为信号处理函数可以随便修改errno。handler执行完返回后主程序会继续运行。如果handler里调用了某个函数修改了errno主程序在检查错误时就会得到错误结果。因此自定义handler开头应该保存errno退出前恢复void handler(int sig) { int saved_errno errno; // do something errno saved_errno; }这种细节在排查为什么我明明设了errno却没有被正确处理这种诡异问题时能帮你节省大量时间。第四个坑忘记处理EINTR。当你注册了handler且没有设置SA_RESTART很多慢速系统调用都会返回EINTR。尤其在网络编程里如果epoll_wait被信号打断返回EINTR服务很可能误判为连接错误直接断开连接。这是生产环境里一个隐蔽的稳定性杀手。第五个坑进程崩溃时没有core文件。默认系统往往限制core文件生成ulimit -c为0导致SIGSEGV后什么痕迹都没留下。排查生产问题前先确认ulimit -c unlimited并检查/proc/sys/kernel/core_pattern指向哪里。这不算是信号栈的直接问题但遇到段错误排查时没有core会让你寸步难行。5.2 排查信号问题这些命令和思路很好用如果你想快速确认一个进程的信号配置和状态我常用的命令和接口如下命令/接口作用kill -l查看完整信号编号和名称cat /proc/ /status查看SigCgt、SigBlk、SigIgn观察信号捕获/屏蔽配置strace -e signal跟踪进程收到或发送的信号gdb -p挂到进程上延迟信号处理查看现场ulimit -c unlimited开启core文件生成cat /proc/sys/kernel/core_pattern查看core文件的保存路径格式排查思路我个人的经验是先看信号是否被屏蔽再看是否已注册handler最后才考虑是不是handler本身有Bug。比如你在测试环境复现了SIGTERM不生效用/proc/PID/status看SigCgt是否包含SIGTERM一眼就能确认代码有没有注册成功。专门针对信号栈相关问题可以通过检查当前handler是否带SA_ONSTACK、sigaltstack是否成功、备用栈大小是否足够来定位。一个很小却很实用的经验是把sigaltstack配置的返回值检查写进所有守护进程的启动日志中——如果备用栈配置失败你在崩溃现场几乎没有第二个兜底方案。5.3 信号处理代码的几点经验总结最后聊几句实战体会。在实际项目里我很少让handler做重活。信号处理函数的设计原则可以用四个字概括短、快、净。短指代码路径短不做复杂逻辑快指必须快速返回或退出净指不碰任何带锁、带堆的状态。如果一个handler里出现了循环遍历链表、打印长日志、调用数据库操作那几乎可以断言这个程序迟早会出问题。关于优雅退出有一个值得借鉴的双信号设计模式收到SIGTERM时置一个全局标志位通知主循环退出收到SIGUSR1时重新加载配置文件收到SIGINT时立即退出并清理临时文件。把信号的通知和主程序的处理分离而不是依赖handler本身去处理业务逻辑能让整个程序的信号响应路径变得非常干净。我个人在处理崩溃类问题时还有一个心得永远不要期待单独的某一种机制能兜住所有异常。备用信号栈解决的是handler有一块安全落脚点的问题它不能让一个已经内存损坏的程序起死回生。真正的防线是让程序在正常情况下不产生这类异常信号栈只是最后一道勉强撑开的保护伞。但真正到了最后一道的时刻你会发现它比任何日志都管用。因为这个备用栈是你能在崩溃前抓到的最后一根稻草。