1. 从一次CtrlC开始信号其实就在你手边打开终端跑一个死循环的进程随手按一下CtrlC程序就没了。这个“随手”的动作背后藏着Linux信号机制最核心的交互逻辑——内核给进程发了一个SIGINT信号进程收到后默认执行终止操作。我最早学Linux进程管理的时候就是从这个动作开始一点点把信号、进程、系统调用串起来的。信号signal本质上是一个异步事件通知机制。它的角色有点像领导打来的内线电话系统里发生任何“紧急情况”时内核会直接拨给对应进程通知它去处理。处理方式有两种进程自己接了电话按指令办事安装信号处理器或者让系统默认处理不接电话直接走默认应答。对于刚接触Linux的运维同学和刚入门嵌入式开发的工程师来说信号是绕不过去的一课因为它直接关系到进程的启停、崩溃处理、守护进程保活、后台任务管理等各种高频场景。这篇文章我打算从“信号到底怎么产生、怎么传递”讲起把常用信号捋一遍再重点聊聊捕获处理、多线程下的信号屏蔽最后分享几个真实踩过的坑。内容尽量贴近实际命令行操作和C语言/Python的编程场景看完你至少能回答这几个问题为什么kill -9和kill不一样为什么nohup能挡住挂断信号写信号处理函数时为什么不能随便调用printf逐个拆解。2. 信号的产生与传递把内核的“电话铃”机制讲明白2.1 硬触发终端按键与异常事件信号来源分两大类。第一类是“硬触发”比如你按CtrlC终端驱动程序收到这个特殊按键组合会向前台进程组发送SIGINT按Ctrl\发送SIGQUIT按CtrlZ发送SIGTSTP挂起。这类信号带有明显的人机交互意图属于主动发起的。另一类硬触发是程序自己“闯祸”产生的异常信号。最常见的SIGSEGV段错误就是进程访问了非法内存地址比如对空指针解引用。还有SIGFPE浮点异常注意不只是浮点除法出错整数除以0也会触发。SIGBUS总线错误则通常和内存对齐、访问映射区域越界相关。这类信号是硬件异常被内核捕捉后转成信号发给进程的程序自己往往没有“悔棋”的机会默认动作直接就是终止。2.2 软触发系统调用与命令发送第二类是“软触发”通过系统调用或命令主动向指定进程发信号。比如kill命令其实它的默认信号是SIGTERM而不是很多人以为的SIGKILL、C语言里的kill()函数、raise()函数给当前进程自己发信号、alarm()定时闹钟到期后发SIGALRM还有abort()给当前进程发SIGABRT并产生core dump。这类信号是纯软件层面的发不发、什么时候发、发给谁完全由调用方决定。进程收到信号后并不会立即乖乖执行处理逻辑。绝大多数信号是“内核置个标记等进程从内核态返回用户态时再检查并派发”。所以信号处理存在一个不确定的交付延迟进程如果在内核里处理系统调用可能要先返回到用户态处理完信号再重新进入内核把之前的系统调用继续走完。理解这一点很重要很多新手以为信号一到就同步执行结果排查半天发现时序对不上其实是信号派发的时机和中断不一样它不是硬打断指令流更接近“记账式的挂起事件”。2.3 信号的默认行为五类处理的取舍逻辑每个信号都有默认动作不必死记硬背但要知道分五类默认行为举例说明终止进程SIGTERM、SIGINT正常终止进程没机会做清理终止进程并产生core dumpSIGSEGV、SIGABRT、SIGQUIT便于事后排查程序崩溃原因停止进程SIGSTOP、SIGTSTP进程挂起不会退出可用SIGCONT恢复忽略信号SIGCHLD默认就是忽略不做事继续运行SIGCONT让停止的进程继续执行这里有个容易混淆的点SIGSTOP和SIGKILL这两个信号是“特例中的特例”它们不允许被进程捕获或屏蔽也就是说你写代码无法拦截kill -9。光凭这一点kill -9就经常被当成“最后的杀手锏”但同时也被资深运维嫌弃因为它剥夺了进程善后的一切机会。3. 常用信号速查表用得最多的十来个信号先给一张我日常工作高频使用的信号表收藏级配合man 7 signal一起看效果更好信号编号默认动作常见触发场景SIGHUP1终止进程终端断开、挂断也可用于让进程重读配置SIGINT2终止进程CtrlCSIGQUIT3终止coreCtrl\SIGKILL9强制终止kill -9不可捕获SIGSEGV11终止core非法内存访问SIGPIPE13终止进程写一个无人读取的管道SIGTERM15终止进程kill 命令默认信号优雅终止SIGSTOP19停止进程CtrlZ 之外kill -STOPSIGCHLD17忽略子进程退出时发给父进程SIGCONT18继续kill -CONT 恢复停止进程SIGUSR110终止进程用户自定义常用于通知进程做某事SIGUSR212终止进程用户自定义SIGALRM14终止进程alarm() 定时器到期注意x86_64和ARM等不同架构下SIGSTOP、SIGCHLD这些的编号可能略有差异比如在ARM上是SIGSTOP19、SIGCHLD17但在x86上SIGCHLD是17、SIGSTOP是19SIGCONT是18这个不绝对别硬记编号用名称最稳妥。说几个实战中特别值得留意的SIGHUP终端断开时内核会给该终端下所有前台/后台进程组发SIGHUP默认动作是终止。这也是为什么用SSH跑定时长任务时只要网络一断进程就没了。解决办法之一就是nohup或者setsid它们的本质就是让进程脱离终端不接收这个信号。SIGPIPE经典网络编程杀手。你的程序往一个已关闭的socket或管道写数据时内核会发SIGPIPE默认直接终止进程。很多人第一次跑服务端程序莫名其妙挂掉查日志啥都没有十有八九是SIGPIPE处理方式一般是忽略它或者单独捕获处理。SIGCHLD子进程退出时内核会给父进程发送这个信号。父进程如果不管子进程就会变成僵尸进程。所以很多守护进程的代码里会在主循环里wait/waitpid收尸或者专门捕获SIGCHLD再异步处理。4. 发信号实操kill、killall、pkill以及藏在C代码里的kill()4.1 kill命令的细节与“优雅终止”的学问kill这个词有点吓人但它最初的意思是“发送信号”并不一定就是杀掉进程。不带参数调用kill 1234实际上是发送SIGTERM属于“请求对方优雅退出”。进程收到SIGTERM后如果有注册处理器就可以做清理工作关闭文件、释放锁、写日志、通知其他节点……然后自己退出。一个写得好点的服务进程SIGTERM是它“体面退场”的信号。而kill -9 1234是发送SIGKILL内核直接强制回收进程资源进程连最后一句“遗言”都来不及说。所以我的习惯是能先发SIGTERM尽量先发等个几秒钟看进程是否退出不退出再考虑SIGKILL。特别是有数据库、消息队列这类有持久化状态的进程时SIGKILL很可能造成数据不一致或文件损坏。# 查看所有信号的名字和编号 kill -l # 优雅终止进程 kill 1234 # 指定信号推荐用名字避免架构差异 kill -TERM 1234 kill -KILL 1234 # 类似命令还有 pkill 和 killall按名字匹配进程 pkill -TERM nginx killall -9 nginx使用pkill和killall时千万要小心它们按进程名字匹配pkill -9 python会一次性把所有名字里带python的进程全干掉包括你可能正在用的其他脚本。我曾经在生产环境上一句pkill -9 php把同事几个正在跑任务的进程全带走了从那之后批量结束进程前我都会先pgrep -a看一遍匹配列表再动手。4.2 kill()、raise()与C语言里的信号发送命令行之外程序内部发信号常用的是kill()系统调用它比命令更灵活可以控制发给单进程还是进程组#include signal.h #include sys/types.h #include stdio.h int main() { pid_t pid 12345; // 向指定进程发送 SIGTERM相当于命令行 kill kill(pid, SIGTERM); // 给当前进程发 SIGUSR1相当于调用 raise(SIGUSR1) raise(SIGUSR1); // 向整个进程组发信号pid 取负值即可 // kill(-pgid, SIGTERM); return 0; }raise()是“给自己发信号”在实现超时控制、内部状态切换时很好用。举一个我自己的例子在嵌入式环境里写一个看门狗模块主线程用alarm(5)设定5秒定时如果程序卡死在某个非受控区域没有及时重置定时器SIGALRM就会触发默认动作终止进程系统上层检测到进程挂了会自动重启整个设计就靠信号完成了“自愈”环路。4.3 SIGHUP与后台任务nohup、disown和setsid的本质前文提到SIGHUP会让进程随终端断开而退出。搞懂这个机制后几个常用命令的原理也就不神秘了nohup command nohup的作用是把SIGHUP置为忽略也就是“屏蔽挂断信号”让命令在终端关闭后继续跑。disownbash内建命令把作业从shell的作业表里移除相当于“我不要再管这个子进程了”Shell退出时也就不会向它补发SIGHUP。setsid让程序另起一个新会话彻底脱离当前控制终端这是写守护进程时常用的手段。这几个操作对应到系统层面就是“脱离控制终端”和“改变会话/进程组归属”理解了SIGHUP的触发条件你就能明白为什么有些服务偏爱用setsid而不是nohup——前者是创建独立的会话领导后者只是“硬扛着不收电话铃声”。5. 捕获信号从signal()到sigaction()的进化之路5.1 signal()的两宗罪语义漂移和非重入很多入门教材为了简单直接用signal()注册处理器#include stdio.h #include signal.h #include unistd.h void handler(int sig) { write(STDOUT_FILENO, caught signal\n, 15); } int main() { signal(SIGINT, handler); while (1) pause(); return 0; }这段代码能跑现代glibc里signal()底层已经等价于sigaction()的简化版本可以用在不太较真的场景。但它有两个历史遗留问题不同Unix版本里调用signal()后处理器是“一次性”还是“持续有效”并不统一另外signal()不能精细控制信号的屏蔽、标志位和替代动作。只要涉及真正的生产代码我的建议是直接上sigaction()它才是POSIX标准里可靠、可控制的选择。5.2 sigaction()完整用法与参数解释sigaction()的核心是struct sigaction结构体关键是三个字段#include stdio.h #include signal.h #include string.h #include unistd.h #include errno.h volatile sig_atomic_t g_flag 0; void handler(int sig) { // 信号处理器里只做“标记”这类安全操作 g_flag 1; } int main() { struct sigaction sa; memset(sa, 0, sizeof(sa)); sa.sa_handler handler; // 处理函数 // 处理期间屏蔽SIGUSR1避免重入 sigemptyset(sa.sa_mask); sigaddset(sa.sa_mask, SIGUSR1); // SA_RESTART 让被打断的系统调用自动重启 sa.sa_flags SA_RESTART; sigaction(SIGINT, sa, NULL); while (1) { pause(); if (g_flag) { write(STDOUT_FILENO, got SIGINT\n, 12); g_flag 0; } } return 0; }讲几个容易被忽略的点sa_mask它定义了信号处理器执行期间要额外屏蔽的信号集合。比如你在处理SIGINT时不想再被SIGUSR1打断就把SIGUSR1加进去。注意当前正在处理的信号本身在有些实现里会自动被屏蔽。SA_RESTART进程阻塞在read()、wait()这类慢系统调用时一旦信号到达系统调用可能提前返回EINTR错误。设置SA_RESTART可以让内核自动重启被信号打断的系统调用省去你在每个调用点手动判断errno EINTR的麻烦。sa_handler和sa_sigaction这两个是共用体二选一。需要获取信号的更多上下文比如siginfo_t里的发送者PID、触发原因时用sa_sigaction同时要把sa_flags置为SA_SIGINFO。我实际项目中偏好sigaction()而不是signal()的另一个原因是它可以方便地查询旧的处理器结构第三个参数传old_act在需要临时替换、之后恢复的插件式设计里非常好用。5.3 信号处理函数里的“安全区”为什么不能乱调printf新手最爱在信号处理器里写printf(caught...)这是个很危险的坑。printf内部会申请锁、维护缓冲区、可能调用malloc而malloc内部也有锁和堆状态。如果信号恰好在你主程序执行到malloc中间、持着锁的时候到达处理器里的printf再去抢同一把锁就是死锁更糟的是如果处理器在malloc内部再次触发malloc堆数据结构被破坏程序会以最诡异的方式崩溃。POSIX标准规定信号处理函数只能调用“异步信号安全”函数。常见的包括write()、read()、open()、close()、_exit()、sigaction()等。需要打印日志时正确姿势是把数据写入一个管道或者用sigwait交给专用线程处理后面讲而不是在处理器里直接调printf。我自己踩过最深的坑一个嵌入式采集程序信号处理器里用printf打调试信息平时毫无问题一旦把采集频率调高、内存分配变频繁程序就开始随机崩溃。排查了两天才怀疑到信号处理器里的printf改成write()打一个字节的标记后问题彻底消失。从那次起我给自己立了条规矩信号处理器里只赋值、只写PIPE写日志一律丢给外部线程。6. 屏蔽与等待多线程环境下的信号处理新姿势6.1 信号发给进程还是发给线程多线程程序里信号模型的细节非常多。POSIX标准下像kill()这样的动作是“向进程发送信号”但到底由哪个线程来实际执行处理函数并没有保证——可能是主线程也可能是某个幸运的线程。这带来两个问题你不知道处理器会跑在哪个线程的上下文里如果不同线程对全局状态的处理没有加锁信号处理器里的读写可能引发数据竞争。某些线程专用信号如SIGSEGV、SIGFPE这类同步异常只发给触发异常的线程和其他线程无关。可靠的做法是在启动其他线程之前用pthread_sigmask()把关心的信号全部屏蔽掉让它们“积压”在进程级等待队列中然后专门开一个线程调用sigwait()或sigtimedwait()来同步接收并处理。这样信号处理和业务代码天然隔离也不必担心在信号处理器里做复杂逻辑。6.2 sigwait用线程替代不可靠的处理器看一个典型写法#include stdio.h #include signal.h #include pthread.h void *signal_thread(void *arg) { sigset_t waitset; int sig; siginfo_t info; sigemptyset(waitset); sigaddset(waitset, SIGINT); sigaddset(waitset, SIGTERM); // 在信号线程内部也建议屏蔽防止别的线程意外捕获 pthread_sigmask(SIG_BLOCK, waitset, NULL); while (1) { // 同步等待信号到达 sigwaitinfo(waitset, info); sig info.si_signo; if (sig SIGINT) { printf(thread got SIGINT\n); break; } else if (sig SIGTERM) { printf(thread got SIGTERM, clean up...\n); // 这里可以做真正的清理因为是在普通线程上下文 break; } } return NULL; } int main() { sigset_t blockset; pthread_t tid; // 先屏蔽SIGINT和SIGTERM确保不会被其他线程抢走 sigemptyset(blockset); sigaddset(blockset, SIGINT); sigaddset(blockset, SIGTERM); pthread_sigmask(SIG_BLOCK, blockset, NULL); pthread_create(tid, NULL, signal_thread, NULL); pthread_join(tid, NULL); return 0; }这套“屏蔽 专用线程等待”模式在服务端和嵌入式程序里都非常流行因为它从根本上绕开了“信号处理器里不能干重活”的限制。sigwait()返回后你尽管在普通线程上下文里处理日志、释放资源、更新状态不用再纠结是不是异步信号安全。6.3 线程库带来的特殊信号SIGCANCEL和SIGSETXID使用glibc时还有两个“隐形信号”值得知道。SIGCANCEL内部编号通常33是NPTL线程库用于实现pthread_cancel()的内部信号SIGSETXID34用于同步各线程的UID/GID变更。它们不是标准信号千万不要在你的业务代码里捕获或屏蔽否则可能引起线程库内部机制失效。排查信号问题时如果kill -l看到33、34这些编号不要惊慌这是线程库的正常行为。7. 信号在守护进程与系统监控中的角色7.1 守护进程如何利用SIGHUP重读配置守护进程有两个经典特性脱离控制终端、常驻后台。它既然脱离了终端自然收不到终端按键产生的SIGINT但很多守护进程会把SIGHUP当成“外部管理员发来的指令”——重读配置文件。比如nginx reload实际上就是向master进程发送SIGHUP让master重新加载配置并平滑重启worker进程。这个概念和“终端挂断触发SIGHUP”是同一个信号名但处理逻辑完全不同这就解释了为什么kill -HUP $(pidof nginx)能实现热加载。我在自研的一个采集服务里也用了这个套路收到SIGHUP就重新读取配置文件、重新初始化日志句柄整个过程不中断采集线程。运维同学只需要一条命令就能让服务“自我更新”非常方便。7.2 僵尸进程和SIGCHLD的恩恩怨怨子进程退出时内核为了保留退出状态wait时要用不会立刻把一个进程彻底清除而是让它变成“僵尸”状态直到父进程调用wait()/waitpid()来收尸。如果父进程一直不收僵尸进程就会攒在进程表里。处理僵尸进程的常见姿势父进程阻塞在waitpid()上等子进程退出父进程注册SIGCHLD处理器在处理器里waitpid(-1, status, WNOHANG)批量收尸用sigaction加SA_NOCLDWAIT标志告诉内核子进程退出时直接不产生僵尸更极端的方式是fork两层子进程让孙子进程被PID 1init收养由init负责收尸。我写多进程模型时偏爱第2种SIGCHLD处理器里循环waitpid(-1, pid, WNOHANG)直到返回0或-1一次把所有退出的子进程都处理干净。注意处理器里不能用复杂逻辑但waitpid本身是异步信号安全函数可以直接调用。7.3 信号与系统性能监控的结合信号在监控场景里也有一席之地。比如top、ps这类工具查不到你的程序“当前卡在哪个信号处理器里”但你可以用strace -p PID查看进程是否卡在pause()、sigtimedwait()这些信号等待调用上。另外给进程发一个SIGUSR1让它在处理器里打一个当前调用栈快照前提是处理器里用backtrace()等安全性还行的函数这种动态栈采集手法在排查“死循环到底跑在哪”的时候非常有用比事后看日志直观得多。我自己常用的一个监控小技巧在服务里注册SIGUSR2处理器处理器直接把当前的连接数、内存占用、最近一次心跳时间写到固定文件里。想知道服务状态时一行kill -USR2 pid就能拿到“现场数据”不用侵入业务代码比写复杂的监控接口快得多。8. 排查实录我踩过的信号相关坑8.1 CtrlC 按了半天Python进程没反应背景一个多线程Python服务执行CtrlC后只有主线程收到SIGINT其他线程继续跑导致程序无法正常退出。原因分析Python的GIL加线程模型下信号处理逻辑跑在主线程的字节码指令之间如果某个工作线程永久占着GIL不释放比如纯计算、C扩展卡死主线程根本没机会执行信号处理。解决思路一是把繁重任务移到子进程而不是线程二是在工作线程里循环检查threading.Event主线程收到SIGINT后设置Event大家看到后协同退出三是纯计算型工作可以适当在循环里time.sleep(0.001)让出GIL。碰到这类问题的排查套路是先用strace -p PID看线程是否阻塞在某个系统调用上再看/proc/PID/status里的SigBlk和ShdPnd字段确认信号到底有没有被某个线程屏蔽掉。8.2 网络程序莫名退出最后抓到SIGPIPE一个长时间运行的服务端程序每天固定时段就会挂掉日志里什么都没有。排查思路先看系统日志和dmesg有没有core dump记录再用core dump文件配合gdb看信号。结果发现进程退出信号是SIGPIPE而触发场景是客户端网络断开后服务端继续往socket里写数据。修复方案很简单启动时忽略SIGPIPE然后对send/write的返回值和EPIPE错误做正常业务处理。在C语言里是signal(SIGPIPE, SIG_IGN)否则就捕获处理在Python里可以直接用signal.signal(signal.SIGPIPE, signal.SIG_IGN)消除默认终止行为改为在业务层优雅关闭连接。补充一个重要提示写服务端程序时忽略SIGPIPE几乎是个必经之路。因为TCP连接另一半断开后第一次写可能成功收到ACK之前第二次写才会触发错误并对进程发SIGPIPE。如果你不提前处理线上稳如老狗的程序也可能在某次“用户乱拔网线”后瞬间消失。8.3 为什么kill -9打不死的D状态进程有时候进程卡在不可中断睡眠D状态通常在做磁盘IO或等待内核资源kill -9也无法让它立即退出。信号处理只在进程回到用户态时才有机会执行D状态的进程根本不在用户态运行信号只能在队列里等着。排查时先确认是不是存储设备或NFS异常导致IO卡死等IO恢复后进程一般能自己苏醒。如果一直卡死只能重启机器或者等待内核清资源这也是为什么生产环境对存储稳定性要求极高的原因之一。这里补一句经验遇到D状态进程别急着反复kill -9先看cat /proc/PID/stack内核版本支持时和dmesg判断是等IO还是等锁再决定下一步。8.4 nohup命令后程序还在退出的锅该谁来背有人用了nohupSSH退出后程序还是没了。这种多半是程序自己收到SIGHUP之后的善后动作也可能是父进程退出时主动给子进程发信号。nohup只是把SIGHUP忽略但如果程序本身捕获了SIGHUP并且自己的处理逻辑是退出那它也拦不住。还有一个常见原因是你在bash里执行nohup cmd 后直接关终端虽然nohup把SIGHUP忽略了但终端断开后SSD会话的session关闭时其他信号比如SIGTERM也可能被发送过来。最稳妥的办法是setsid加重定向彻底脱离。我自己的经验用nohup时一定要把标准输出和错误输出重定向到文件否则nohup.out会在当前目录下疯狂累积几个月后磁盘被写满服务又莫名其妙挂了。至少加一行nohup ./start.sh /var/log/app/run.log 21 。8.5 信号问题排查速查表现象可能原因排查命令/手段程序无响应但进程还在信号被屏蔽或线程模型问题cat /proc/PID/status看SigBlkstrace -p PID程序退出无日志SIGKILL或SIGSEGV导致core dumpdmesg、coredumpctl infosystemd环境定时任务莫名中断终端断开触发SIGHUP检查任务是否使用nohup/setsid启动子进程全变僵尸父进程没调用wait/waitpidps -e -o pid,ppid,stat,commsocket写数据崩溃SIGPIPE未处理启动时忽略SIGPIPE或捕获处理信号处理函数里死锁调用了非异步安全的函数处理器里只写PIPE或只设标志位kill -9无效进程在D状态检查IO状态等内核释放说实话信号这套机制你看再多资料都不如自己写一段捕获SIGINT的小程序、然后用kill命令来回折腾几遍来得直观。信号设计的初衷是给进程一个“被通知”的机会但真正用好它得靠对“异步安全”“信号屏蔽”“线程协作”这几个概念的反复验证。我现在写任何一个常驻进程第一步就是画清楚它要处理哪几个信号、由谁处理、处理器里能做什么不能做什么想清楚了再动手线上出问题的概率能低好几个档次。
Linux信号机制详解：从Ctrl+C到kill命令的进程管理核心
1. 从一次CtrlC开始信号其实就在你手边打开终端跑一个死循环的进程随手按一下CtrlC程序就没了。这个“随手”的动作背后藏着Linux信号机制最核心的交互逻辑——内核给进程发了一个SIGINT信号进程收到后默认执行终止操作。我最早学Linux进程管理的时候就是从这个动作开始一点点把信号、进程、系统调用串起来的。信号signal本质上是一个异步事件通知机制。它的角色有点像领导打来的内线电话系统里发生任何“紧急情况”时内核会直接拨给对应进程通知它去处理。处理方式有两种进程自己接了电话按指令办事安装信号处理器或者让系统默认处理不接电话直接走默认应答。对于刚接触Linux的运维同学和刚入门嵌入式开发的工程师来说信号是绕不过去的一课因为它直接关系到进程的启停、崩溃处理、守护进程保活、后台任务管理等各种高频场景。这篇文章我打算从“信号到底怎么产生、怎么传递”讲起把常用信号捋一遍再重点聊聊捕获处理、多线程下的信号屏蔽最后分享几个真实踩过的坑。内容尽量贴近实际命令行操作和C语言/Python的编程场景看完你至少能回答这几个问题为什么kill -9和kill不一样为什么nohup能挡住挂断信号写信号处理函数时为什么不能随便调用printf逐个拆解。2. 信号的产生与传递把内核的“电话铃”机制讲明白2.1 硬触发终端按键与异常事件信号来源分两大类。第一类是“硬触发”比如你按CtrlC终端驱动程序收到这个特殊按键组合会向前台进程组发送SIGINT按Ctrl\发送SIGQUIT按CtrlZ发送SIGTSTP挂起。这类信号带有明显的人机交互意图属于主动发起的。另一类硬触发是程序自己“闯祸”产生的异常信号。最常见的SIGSEGV段错误就是进程访问了非法内存地址比如对空指针解引用。还有SIGFPE浮点异常注意不只是浮点除法出错整数除以0也会触发。SIGBUS总线错误则通常和内存对齐、访问映射区域越界相关。这类信号是硬件异常被内核捕捉后转成信号发给进程的程序自己往往没有“悔棋”的机会默认动作直接就是终止。2.2 软触发系统调用与命令发送第二类是“软触发”通过系统调用或命令主动向指定进程发信号。比如kill命令其实它的默认信号是SIGTERM而不是很多人以为的SIGKILL、C语言里的kill()函数、raise()函数给当前进程自己发信号、alarm()定时闹钟到期后发SIGALRM还有abort()给当前进程发SIGABRT并产生core dump。这类信号是纯软件层面的发不发、什么时候发、发给谁完全由调用方决定。进程收到信号后并不会立即乖乖执行处理逻辑。绝大多数信号是“内核置个标记等进程从内核态返回用户态时再检查并派发”。所以信号处理存在一个不确定的交付延迟进程如果在内核里处理系统调用可能要先返回到用户态处理完信号再重新进入内核把之前的系统调用继续走完。理解这一点很重要很多新手以为信号一到就同步执行结果排查半天发现时序对不上其实是信号派发的时机和中断不一样它不是硬打断指令流更接近“记账式的挂起事件”。2.3 信号的默认行为五类处理的取舍逻辑每个信号都有默认动作不必死记硬背但要知道分五类默认行为举例说明终止进程SIGTERM、SIGINT正常终止进程没机会做清理终止进程并产生core dumpSIGSEGV、SIGABRT、SIGQUIT便于事后排查程序崩溃原因停止进程SIGSTOP、SIGTSTP进程挂起不会退出可用SIGCONT恢复忽略信号SIGCHLD默认就是忽略不做事继续运行SIGCONT让停止的进程继续执行这里有个容易混淆的点SIGSTOP和SIGKILL这两个信号是“特例中的特例”它们不允许被进程捕获或屏蔽也就是说你写代码无法拦截kill -9。光凭这一点kill -9就经常被当成“最后的杀手锏”但同时也被资深运维嫌弃因为它剥夺了进程善后的一切机会。3. 常用信号速查表用得最多的十来个信号先给一张我日常工作高频使用的信号表收藏级配合man 7 signal一起看效果更好信号编号默认动作常见触发场景SIGHUP1终止进程终端断开、挂断也可用于让进程重读配置SIGINT2终止进程CtrlCSIGQUIT3终止coreCtrl\SIGKILL9强制终止kill -9不可捕获SIGSEGV11终止core非法内存访问SIGPIPE13终止进程写一个无人读取的管道SIGTERM15终止进程kill 命令默认信号优雅终止SIGSTOP19停止进程CtrlZ 之外kill -STOPSIGCHLD17忽略子进程退出时发给父进程SIGCONT18继续kill -CONT 恢复停止进程SIGUSR110终止进程用户自定义常用于通知进程做某事SIGUSR212终止进程用户自定义SIGALRM14终止进程alarm() 定时器到期注意x86_64和ARM等不同架构下SIGSTOP、SIGCHLD这些的编号可能略有差异比如在ARM上是SIGSTOP19、SIGCHLD17但在x86上SIGCHLD是17、SIGSTOP是19SIGCONT是18这个不绝对别硬记编号用名称最稳妥。说几个实战中特别值得留意的SIGHUP终端断开时内核会给该终端下所有前台/后台进程组发SIGHUP默认动作是终止。这也是为什么用SSH跑定时长任务时只要网络一断进程就没了。解决办法之一就是nohup或者setsid它们的本质就是让进程脱离终端不接收这个信号。SIGPIPE经典网络编程杀手。你的程序往一个已关闭的socket或管道写数据时内核会发SIGPIPE默认直接终止进程。很多人第一次跑服务端程序莫名其妙挂掉查日志啥都没有十有八九是SIGPIPE处理方式一般是忽略它或者单独捕获处理。SIGCHLD子进程退出时内核会给父进程发送这个信号。父进程如果不管子进程就会变成僵尸进程。所以很多守护进程的代码里会在主循环里wait/waitpid收尸或者专门捕获SIGCHLD再异步处理。4. 发信号实操kill、killall、pkill以及藏在C代码里的kill()4.1 kill命令的细节与“优雅终止”的学问kill这个词有点吓人但它最初的意思是“发送信号”并不一定就是杀掉进程。不带参数调用kill 1234实际上是发送SIGTERM属于“请求对方优雅退出”。进程收到SIGTERM后如果有注册处理器就可以做清理工作关闭文件、释放锁、写日志、通知其他节点……然后自己退出。一个写得好点的服务进程SIGTERM是它“体面退场”的信号。而kill -9 1234是发送SIGKILL内核直接强制回收进程资源进程连最后一句“遗言”都来不及说。所以我的习惯是能先发SIGTERM尽量先发等个几秒钟看进程是否退出不退出再考虑SIGKILL。特别是有数据库、消息队列这类有持久化状态的进程时SIGKILL很可能造成数据不一致或文件损坏。# 查看所有信号的名字和编号 kill -l # 优雅终止进程 kill 1234 # 指定信号推荐用名字避免架构差异 kill -TERM 1234 kill -KILL 1234 # 类似命令还有 pkill 和 killall按名字匹配进程 pkill -TERM nginx killall -9 nginx使用pkill和killall时千万要小心它们按进程名字匹配pkill -9 python会一次性把所有名字里带python的进程全干掉包括你可能正在用的其他脚本。我曾经在生产环境上一句pkill -9 php把同事几个正在跑任务的进程全带走了从那之后批量结束进程前我都会先pgrep -a看一遍匹配列表再动手。4.2 kill()、raise()与C语言里的信号发送命令行之外程序内部发信号常用的是kill()系统调用它比命令更灵活可以控制发给单进程还是进程组#include signal.h #include sys/types.h #include stdio.h int main() { pid_t pid 12345; // 向指定进程发送 SIGTERM相当于命令行 kill kill(pid, SIGTERM); // 给当前进程发 SIGUSR1相当于调用 raise(SIGUSR1) raise(SIGUSR1); // 向整个进程组发信号pid 取负值即可 // kill(-pgid, SIGTERM); return 0; }raise()是“给自己发信号”在实现超时控制、内部状态切换时很好用。举一个我自己的例子在嵌入式环境里写一个看门狗模块主线程用alarm(5)设定5秒定时如果程序卡死在某个非受控区域没有及时重置定时器SIGALRM就会触发默认动作终止进程系统上层检测到进程挂了会自动重启整个设计就靠信号完成了“自愈”环路。4.3 SIGHUP与后台任务nohup、disown和setsid的本质前文提到SIGHUP会让进程随终端断开而退出。搞懂这个机制后几个常用命令的原理也就不神秘了nohup command nohup的作用是把SIGHUP置为忽略也就是“屏蔽挂断信号”让命令在终端关闭后继续跑。disownbash内建命令把作业从shell的作业表里移除相当于“我不要再管这个子进程了”Shell退出时也就不会向它补发SIGHUP。setsid让程序另起一个新会话彻底脱离当前控制终端这是写守护进程时常用的手段。这几个操作对应到系统层面就是“脱离控制终端”和“改变会话/进程组归属”理解了SIGHUP的触发条件你就能明白为什么有些服务偏爱用setsid而不是nohup——前者是创建独立的会话领导后者只是“硬扛着不收电话铃声”。5. 捕获信号从signal()到sigaction()的进化之路5.1 signal()的两宗罪语义漂移和非重入很多入门教材为了简单直接用signal()注册处理器#include stdio.h #include signal.h #include unistd.h void handler(int sig) { write(STDOUT_FILENO, caught signal\n, 15); } int main() { signal(SIGINT, handler); while (1) pause(); return 0; }这段代码能跑现代glibc里signal()底层已经等价于sigaction()的简化版本可以用在不太较真的场景。但它有两个历史遗留问题不同Unix版本里调用signal()后处理器是“一次性”还是“持续有效”并不统一另外signal()不能精细控制信号的屏蔽、标志位和替代动作。只要涉及真正的生产代码我的建议是直接上sigaction()它才是POSIX标准里可靠、可控制的选择。5.2 sigaction()完整用法与参数解释sigaction()的核心是struct sigaction结构体关键是三个字段#include stdio.h #include signal.h #include string.h #include unistd.h #include errno.h volatile sig_atomic_t g_flag 0; void handler(int sig) { // 信号处理器里只做“标记”这类安全操作 g_flag 1; } int main() { struct sigaction sa; memset(sa, 0, sizeof(sa)); sa.sa_handler handler; // 处理函数 // 处理期间屏蔽SIGUSR1避免重入 sigemptyset(sa.sa_mask); sigaddset(sa.sa_mask, SIGUSR1); // SA_RESTART 让被打断的系统调用自动重启 sa.sa_flags SA_RESTART; sigaction(SIGINT, sa, NULL); while (1) { pause(); if (g_flag) { write(STDOUT_FILENO, got SIGINT\n, 12); g_flag 0; } } return 0; }讲几个容易被忽略的点sa_mask它定义了信号处理器执行期间要额外屏蔽的信号集合。比如你在处理SIGINT时不想再被SIGUSR1打断就把SIGUSR1加进去。注意当前正在处理的信号本身在有些实现里会自动被屏蔽。SA_RESTART进程阻塞在read()、wait()这类慢系统调用时一旦信号到达系统调用可能提前返回EINTR错误。设置SA_RESTART可以让内核自动重启被信号打断的系统调用省去你在每个调用点手动判断errno EINTR的麻烦。sa_handler和sa_sigaction这两个是共用体二选一。需要获取信号的更多上下文比如siginfo_t里的发送者PID、触发原因时用sa_sigaction同时要把sa_flags置为SA_SIGINFO。我实际项目中偏好sigaction()而不是signal()的另一个原因是它可以方便地查询旧的处理器结构第三个参数传old_act在需要临时替换、之后恢复的插件式设计里非常好用。5.3 信号处理函数里的“安全区”为什么不能乱调printf新手最爱在信号处理器里写printf(caught...)这是个很危险的坑。printf内部会申请锁、维护缓冲区、可能调用malloc而malloc内部也有锁和堆状态。如果信号恰好在你主程序执行到malloc中间、持着锁的时候到达处理器里的printf再去抢同一把锁就是死锁更糟的是如果处理器在malloc内部再次触发malloc堆数据结构被破坏程序会以最诡异的方式崩溃。POSIX标准规定信号处理函数只能调用“异步信号安全”函数。常见的包括write()、read()、open()、close()、_exit()、sigaction()等。需要打印日志时正确姿势是把数据写入一个管道或者用sigwait交给专用线程处理后面讲而不是在处理器里直接调printf。我自己踩过最深的坑一个嵌入式采集程序信号处理器里用printf打调试信息平时毫无问题一旦把采集频率调高、内存分配变频繁程序就开始随机崩溃。排查了两天才怀疑到信号处理器里的printf改成write()打一个字节的标记后问题彻底消失。从那次起我给自己立了条规矩信号处理器里只赋值、只写PIPE写日志一律丢给外部线程。6. 屏蔽与等待多线程环境下的信号处理新姿势6.1 信号发给进程还是发给线程多线程程序里信号模型的细节非常多。POSIX标准下像kill()这样的动作是“向进程发送信号”但到底由哪个线程来实际执行处理函数并没有保证——可能是主线程也可能是某个幸运的线程。这带来两个问题你不知道处理器会跑在哪个线程的上下文里如果不同线程对全局状态的处理没有加锁信号处理器里的读写可能引发数据竞争。某些线程专用信号如SIGSEGV、SIGFPE这类同步异常只发给触发异常的线程和其他线程无关。可靠的做法是在启动其他线程之前用pthread_sigmask()把关心的信号全部屏蔽掉让它们“积压”在进程级等待队列中然后专门开一个线程调用sigwait()或sigtimedwait()来同步接收并处理。这样信号处理和业务代码天然隔离也不必担心在信号处理器里做复杂逻辑。6.2 sigwait用线程替代不可靠的处理器看一个典型写法#include stdio.h #include signal.h #include pthread.h void *signal_thread(void *arg) { sigset_t waitset; int sig; siginfo_t info; sigemptyset(waitset); sigaddset(waitset, SIGINT); sigaddset(waitset, SIGTERM); // 在信号线程内部也建议屏蔽防止别的线程意外捕获 pthread_sigmask(SIG_BLOCK, waitset, NULL); while (1) { // 同步等待信号到达 sigwaitinfo(waitset, info); sig info.si_signo; if (sig SIGINT) { printf(thread got SIGINT\n); break; } else if (sig SIGTERM) { printf(thread got SIGTERM, clean up...\n); // 这里可以做真正的清理因为是在普通线程上下文 break; } } return NULL; } int main() { sigset_t blockset; pthread_t tid; // 先屏蔽SIGINT和SIGTERM确保不会被其他线程抢走 sigemptyset(blockset); sigaddset(blockset, SIGINT); sigaddset(blockset, SIGTERM); pthread_sigmask(SIG_BLOCK, blockset, NULL); pthread_create(tid, NULL, signal_thread, NULL); pthread_join(tid, NULL); return 0; }这套“屏蔽 专用线程等待”模式在服务端和嵌入式程序里都非常流行因为它从根本上绕开了“信号处理器里不能干重活”的限制。sigwait()返回后你尽管在普通线程上下文里处理日志、释放资源、更新状态不用再纠结是不是异步信号安全。6.3 线程库带来的特殊信号SIGCANCEL和SIGSETXID使用glibc时还有两个“隐形信号”值得知道。SIGCANCEL内部编号通常33是NPTL线程库用于实现pthread_cancel()的内部信号SIGSETXID34用于同步各线程的UID/GID变更。它们不是标准信号千万不要在你的业务代码里捕获或屏蔽否则可能引起线程库内部机制失效。排查信号问题时如果kill -l看到33、34这些编号不要惊慌这是线程库的正常行为。7. 信号在守护进程与系统监控中的角色7.1 守护进程如何利用SIGHUP重读配置守护进程有两个经典特性脱离控制终端、常驻后台。它既然脱离了终端自然收不到终端按键产生的SIGINT但很多守护进程会把SIGHUP当成“外部管理员发来的指令”——重读配置文件。比如nginx reload实际上就是向master进程发送SIGHUP让master重新加载配置并平滑重启worker进程。这个概念和“终端挂断触发SIGHUP”是同一个信号名但处理逻辑完全不同这就解释了为什么kill -HUP $(pidof nginx)能实现热加载。我在自研的一个采集服务里也用了这个套路收到SIGHUP就重新读取配置文件、重新初始化日志句柄整个过程不中断采集线程。运维同学只需要一条命令就能让服务“自我更新”非常方便。7.2 僵尸进程和SIGCHLD的恩恩怨怨子进程退出时内核为了保留退出状态wait时要用不会立刻把一个进程彻底清除而是让它变成“僵尸”状态直到父进程调用wait()/waitpid()来收尸。如果父进程一直不收僵尸进程就会攒在进程表里。处理僵尸进程的常见姿势父进程阻塞在waitpid()上等子进程退出父进程注册SIGCHLD处理器在处理器里waitpid(-1, status, WNOHANG)批量收尸用sigaction加SA_NOCLDWAIT标志告诉内核子进程退出时直接不产生僵尸更极端的方式是fork两层子进程让孙子进程被PID 1init收养由init负责收尸。我写多进程模型时偏爱第2种SIGCHLD处理器里循环waitpid(-1, pid, WNOHANG)直到返回0或-1一次把所有退出的子进程都处理干净。注意处理器里不能用复杂逻辑但waitpid本身是异步信号安全函数可以直接调用。7.3 信号与系统性能监控的结合信号在监控场景里也有一席之地。比如top、ps这类工具查不到你的程序“当前卡在哪个信号处理器里”但你可以用strace -p PID查看进程是否卡在pause()、sigtimedwait()这些信号等待调用上。另外给进程发一个SIGUSR1让它在处理器里打一个当前调用栈快照前提是处理器里用backtrace()等安全性还行的函数这种动态栈采集手法在排查“死循环到底跑在哪”的时候非常有用比事后看日志直观得多。我自己常用的一个监控小技巧在服务里注册SIGUSR2处理器处理器直接把当前的连接数、内存占用、最近一次心跳时间写到固定文件里。想知道服务状态时一行kill -USR2 pid就能拿到“现场数据”不用侵入业务代码比写复杂的监控接口快得多。8. 排查实录我踩过的信号相关坑8.1 CtrlC 按了半天Python进程没反应背景一个多线程Python服务执行CtrlC后只有主线程收到SIGINT其他线程继续跑导致程序无法正常退出。原因分析Python的GIL加线程模型下信号处理逻辑跑在主线程的字节码指令之间如果某个工作线程永久占着GIL不释放比如纯计算、C扩展卡死主线程根本没机会执行信号处理。解决思路一是把繁重任务移到子进程而不是线程二是在工作线程里循环检查threading.Event主线程收到SIGINT后设置Event大家看到后协同退出三是纯计算型工作可以适当在循环里time.sleep(0.001)让出GIL。碰到这类问题的排查套路是先用strace -p PID看线程是否阻塞在某个系统调用上再看/proc/PID/status里的SigBlk和ShdPnd字段确认信号到底有没有被某个线程屏蔽掉。8.2 网络程序莫名退出最后抓到SIGPIPE一个长时间运行的服务端程序每天固定时段就会挂掉日志里什么都没有。排查思路先看系统日志和dmesg有没有core dump记录再用core dump文件配合gdb看信号。结果发现进程退出信号是SIGPIPE而触发场景是客户端网络断开后服务端继续往socket里写数据。修复方案很简单启动时忽略SIGPIPE然后对send/write的返回值和EPIPE错误做正常业务处理。在C语言里是signal(SIGPIPE, SIG_IGN)否则就捕获处理在Python里可以直接用signal.signal(signal.SIGPIPE, signal.SIG_IGN)消除默认终止行为改为在业务层优雅关闭连接。补充一个重要提示写服务端程序时忽略SIGPIPE几乎是个必经之路。因为TCP连接另一半断开后第一次写可能成功收到ACK之前第二次写才会触发错误并对进程发SIGPIPE。如果你不提前处理线上稳如老狗的程序也可能在某次“用户乱拔网线”后瞬间消失。8.3 为什么kill -9打不死的D状态进程有时候进程卡在不可中断睡眠D状态通常在做磁盘IO或等待内核资源kill -9也无法让它立即退出。信号处理只在进程回到用户态时才有机会执行D状态的进程根本不在用户态运行信号只能在队列里等着。排查时先确认是不是存储设备或NFS异常导致IO卡死等IO恢复后进程一般能自己苏醒。如果一直卡死只能重启机器或者等待内核清资源这也是为什么生产环境对存储稳定性要求极高的原因之一。这里补一句经验遇到D状态进程别急着反复kill -9先看cat /proc/PID/stack内核版本支持时和dmesg判断是等IO还是等锁再决定下一步。8.4 nohup命令后程序还在退出的锅该谁来背有人用了nohupSSH退出后程序还是没了。这种多半是程序自己收到SIGHUP之后的善后动作也可能是父进程退出时主动给子进程发信号。nohup只是把SIGHUP忽略但如果程序本身捕获了SIGHUP并且自己的处理逻辑是退出那它也拦不住。还有一个常见原因是你在bash里执行nohup cmd 后直接关终端虽然nohup把SIGHUP忽略了但终端断开后SSD会话的session关闭时其他信号比如SIGTERM也可能被发送过来。最稳妥的办法是setsid加重定向彻底脱离。我自己的经验用nohup时一定要把标准输出和错误输出重定向到文件否则nohup.out会在当前目录下疯狂累积几个月后磁盘被写满服务又莫名其妙挂了。至少加一行nohup ./start.sh /var/log/app/run.log 21 。8.5 信号问题排查速查表现象可能原因排查命令/手段程序无响应但进程还在信号被屏蔽或线程模型问题cat /proc/PID/status看SigBlkstrace -p PID程序退出无日志SIGKILL或SIGSEGV导致core dumpdmesg、coredumpctl infosystemd环境定时任务莫名中断终端断开触发SIGHUP检查任务是否使用nohup/setsid启动子进程全变僵尸父进程没调用wait/waitpidps -e -o pid,ppid,stat,commsocket写数据崩溃SIGPIPE未处理启动时忽略SIGPIPE或捕获处理信号处理函数里死锁调用了非异步安全的函数处理器里只写PIPE或只设标志位kill -9无效进程在D状态检查IO状态等内核释放说实话信号这套机制你看再多资料都不如自己写一段捕获SIGINT的小程序、然后用kill命令来回折腾几遍来得直观。信号设计的初衷是给进程一个“被通知”的机会但真正用好它得靠对“异步安全”“信号屏蔽”“线程协作”这几个概念的反复验证。我现在写任何一个常驻进程第一步就是画清楚它要处理哪几个信号、由谁处理、处理器里能做什么不能做什么想清楚了再动手线上出问题的概率能低好几个档次。
