Linux进程信号详解：从SIGTERM到sigaction的完整实战指南

1. 进程信号是什么：先抛开教科书，用一句话讲明白

搞Linux开发或者运维的朋友，一定都遇到过这类场景：跑着的程序卡死了，Ctrl+C没反应，你打开另一个终端敲下 kill -9 进程号，程序瞬间没了。这个“瞬间没了”的背后，就是一个进程信号在起作用。

信号（Signal）是Linux系统里最古老的进程间通信机制之一，也是系统与进程之间沟通的“标准语言”。它本质上是一个软件层面的中断通知：内核告诉某个进程“有事情发生了”，进程可以选择处理、忽略，或者直接默认退出。你不用写任何通信代码，不需要缓冲区，不需要握手协议，一条信号就能把指令送进目标进程的执行流程。

这个机制解决什么问题？简单说，系统需要一种轻量、快速、可靠的方式去控制进程状态。程序跑死了要能终止，进程要能暂停，资源紧张时要能通知进程收敛，用户按Ctrl+C时系统要能立刻响应。这些需求如果靠写文件、设标志位来做，既慢又不及时，而信号刚好能满足。它就像社区里的公共广播系统——不用挨家挨户敲门，一个大喇叭吼一声，房间里的人该关窗关窗、该灭火灭火，各干各的。

适合谁看这篇内容？如果你是刚接触Linux的萌新，我会从信号的产生、默认行为、自定义处理开始讲，保证你在终端里遇到 SIGSEGV、SIGTERM 这类报错时不再发懵；如果你做运维或嵌入式开发，那后半部分的实操细节、常见坑位、信号背后的内核行为，应该能帮你省下不少排查时间。我自己这些年调试服务进程、写守护进程、处理嵌入式设备异常复位，几乎每周都会和信号打交道，所以这篇内容里的每一条经验，基本都是踩过坑之后才总结出来的。

2. 从一张表看懂Linux常见信号

先背一个最基础的事实：Linux信号编号1到31属于标准信号（POSIX标准定义），32和33是实时信号，34往后还有更多实时信号。不同架构下个别编号大同小异，但核心行为是一致的。刚入门的同学不需要把64个信号全记下来，但下面这张表里的信号，我建议你反复看几遍，这是排障的基础。

注意看编号9和19，这两个是“硬汉”信号：SIGKILL和SIGSTOP既不支持自定义捕获，也不能被阻塞。意思是说，当内核发送这两个信号时，进程没有任何办法拒绝——SIGKILL直接杀掉进程，SIGSTOP直接把进程冻住。正因为如此，它们在系统层面被用来做兜底操作，比如内存耗尽时内核强制回收进程，或者调试器需要冻结线程。而像SIGTERM、SIGINT这类信号，进程是可以拦截下来做清理工作的，这就是我们常说的“优雅退出”的基础。

还有一个容易混淆的点：SIGPIPE。我早期写管道通信程序时，对面读端关掉了，我这头还在往管道里写数据，结果进程莫名其妙就退出。当时还纳闷为什么没有报错，后来才意识到是被SIGPIPE信号直接终止了。这种“安静到可怕”的默认行为，在服务端程序里经常遇到，处理办法要么显式忽略它，要么写一个捕获函数记录日志，而不是放任进程悄无声息地挂掉。

3. 信号的整个生命周期：产生、注册、递送、处理

要真正理解信号，不能只记命令，得知道一条信号从产生到被进程处理的完整链路。整个过程其实有点像快递：寄件人发货（产生信号），快递到了驿站（信号挂到进程的pending队列），驿站通知你取件（信号递送），你决定签收还是拒收（信号处理）。

3.1 信号的产生方式

信号的源头五花八门，但归纳下来无非几类：

硬件异常产生的信号：CPU执行指令时遇到除零、访问非法地址、非法指令等，CPU会触发异常，内核把异常翻译成信号发给当前进程。这类信号的编号很有特点——SIGFPE（8）、SIGSEGV（11）、SIGILL（4）。这也是为什么数组越界经常看到“segmentation fault”的原因，本质就是内核在替你兜底“这次访问我不允许”，然后一枪毙了进程。

终端按键产生的信号：你按下Ctrl+C，终端驱动程序检测到后，会向前台进程组发送SIGINT；按Ctrl+Z发送SIGTSTP；按Ctrl+\发送SIGQUIT。所以严格来说，发信号的不是键盘，而是终端驱动。

软件条件触发的信号：这类最复杂，常见的包括alarm()定时器到期触发SIGALRM、子进程退出触发SIGCHLD、写入已关闭的管道触发SIGPIPE、定时器到期触发SIGPROF等。

显式调用系统调用产生：kill()、raise()、pthread_kill()、sigqueue()这些接口，就是用户主动“寄快递”的姿势。

写代码时我经常用raise()在程序内部主动给自己发一个SIGABRT，配合断言快速暴露逻辑错误，这个后面实操部分再展开。

3.2 信号的注册与排队机制

信号从内核到目标进程，不是直接“打电话”，而是先在目标进程的信号挂起队列里记上一笔。当一个信号被生成后，内核会找到目标进程的 task_struct，在其中维护的 pending 链表上挂一个信号节点。

这里有一个关键知识：标准信号不排队。如果一个进程还没处理完当前的SIGUSR1，内核又给它发了5次SIGUSR1，这5个信号会被合并成1个，等进程处理完再检查时，只知道自己收到过SIGUSR1，至于原来有几条？抱歉，已经丢掉了。这背后是Linux对标准信号的一种去重优化——既然你还没来得及处理，那多次发送本质上表达的是同一个意图，合并掉可以省不少内核开销。

但实时信号（编号34以上）是排队的，每条实时信号都会带上一个整型数据（sigqueue发送时用siginfo结构承载），可以用来传递业务数据。所以在设计进程间通信的时候，如果你需要传递有语义的附加数据，就得考虑实时信号，而不是标准信号。

3.3 信号的递送时机与阻塞

信号并不会一到就立刻中断进程执行。内核会在两种情况下检查pending队列并递送信号：一是进程从内核态返回用户态时，二是进程被调度重新获得CPU后。这个设计很精妙——内核不会在任意指令处强行打断进程，而是选择“安全点”进行递送，既能保证及时性，又不至于让进程每执行一条指令都要检查信号。

如果进程选择阻塞某些信号，那这些信号就会一直躺在pending队列里，直到进程解除阻塞。注意这里有个概念必须区分清楚：“阻塞”和“忽略”是两回事。阻塞是信号根本没被递送到处理流程，忽略则是信号到达后处理函数直接不干活。前者影响的是递送时机，后者影响的是递送结果。

3.4 信号处理方式：默认、捕获、忽略

信号到达进程后的“归宿”只有三种：

• 默认行为：执行内核预设的处理逻辑，大多数信号是终止进程，少数是暂停、忽略或者生成core文件。
• 捕获处理：进程注册了一个自定义的函数（signal handler），内核会保存当前上下文，跳转到用户的处理函数执行，执行完再返回之前被打断的地方。
• 忽略：显式告诉内核“这个信号我不关心”。设置方式是调用 signal(SIGxxx, SIG_IGN)，这跟不写处理函数、不设置任何东西是两码事。

这三种方式对应到代码里就是 signal() 和 sigaction() 这两个接口。其实现在写正式代码，我更建议直接使用 sigaction()，因为它比 signal() 提供了更多控制选项，比如指定阻塞集合、设置系统调用中断自动重启等，行为也更符合POSIX标准。signal() 在不同系统上的语义差异较大，跨平台容易踩坑。

4. Linux信号相关的命令实操：kill、trap、nohup背后的信号逻辑

聊完理论，直接上终端实操。很多Linux命令看着是“命令”，本质其实就是信号的封装。把这些命令和信号一一对应起来，你的理解会有质的提升。

4.1 kill命令：信号发送的瑞士军刀

kill 并不是“杀死”的意思，准确说它是“发送信号”。kill -l 能列出系统支持的所有信号名称，这个命令我经常用来查信号编号，记忆力再好也偶尔会记混。

bash复制kill -l     # 列出所有信号，同时显示编号和名称

发送SIGTERM（默认信号，编号15）：

bash复制kill 12345

发送SIGKILL：

bash复制kill -9 12345

发送SIGSTOP暂停进程：

bash复制kill -STOP 12345

发送SIGCONT恢复进程：

bash复制kill -CONT 12345

这里必须强调一个实操教训：能用 -15 就不要用 -9。默认的 kill 进程号 发的是SIGTERM，它会通知进程“请尽快退出，给你时间做清理工作”，比如释放锁、同步日志、关闭数据库连接。而SIGKILL是直接从内核层面把进程摘掉，进程完全没机会清理。我之前就见过一些粗放的服务管理脚本，统一 kill -9，结果数据库连接池里堆积一堆失效连接，服务重启后还要等超时才能恢复。正确的做法是：先 kill 进程号 发SIGTERM，等几秒看进程是否退出，实在不行再升级到 kill -9。

再补充一个killall和pkill：

bash复制killall nginx            # 按进程名发送SIGTERM
killall -9 nginx         # 按进程名发送SIGKILL
pkill -f "java.*server"  # 按完整命令行匹配，发送SIGTERM

pkill -f 在处理启动脚本名和进程名不一致的场景下非常好用，但也要小心别误杀别的进程。我亲眼见过有人 pkill -f python 把整个系统里的所有python脚本全干掉了，包括正在跑定时任务的关键脚本。-f 是匹配完整命令行，匹配范围比单纯进程名大得多，用之前一定先 pgrep -f "python" 看清楚命中列表。

4.2 忽略挂断信号：nohup的原理

大家平时用 nohup command & 让程序在后台运行，看名字就知道——no hangup，不挂断。挂断信号就是SIGHUP。当终端关闭时，终端驱动会给该终端下的控制进程发送SIGHUP，于是进程就死了。nohup 做的事情非常简单：在启动前把SIGHUP设为忽略状态，这样终端关闭时信号递送过来，进程不理会，就能继续跑下去。

用 nohup 的本质其实是：

bash复制trap '' SIGHUP   # 忽略SIGHUP
command &

这种“通过屏蔽特定信号来掌握进程生命周期”的思路，在守护进程编写中特别常用。

4.3 shell脚本里的trap：让脚本能“听懂人话”

写shell脚本时，我会用trap命令让脚本对一些关键信号做自定义处理。最典型的场景是清理临时文件：

bash复制#!/bin/bash

cleanup() {
    echo "捕捉到退出信号，清理临时文件..."
    rm -f /tmp/myapp_*.log
    exit 0
}

trap cleanup EXIT SIGINT SIGTERM

echo "脚本开始运行，PID: $$"
while true; do
    sleep 1
done

这段脚本里，trap cleanup EXIT SIGINT SIGTERM 表示当脚本退出（无论正常结束还是收到SIGINT/SIGTERM）时，都会执行cleanup函数。这样即使有人中途按Ctrl+C，临时文件也不会残留。

trap还有一个妙用——让脚本在收到信号后重新加载配置。很多常驻脚本就这样实现“热更新”：

bash复制reload_config() {
    echo "重新加载配置..."
    source /etc/myapp.conf
}

trap reload_config HUP

这其实就是服务进程收到SIGHUP重新加载配置的经典做法。Nginx、Apache都支持 kill -HUP 主进程号 来重新读取配置而不中断服务，原理就是这个。

4.4 后台任务与setsid：想真正脱离终端控制？

“后台任务”这个概念很容易让人误解。command & 只是把任务放到当前shell的后台，但它的进程组、会话、控制终端仍然跟当前终端关联。如果终端退出，SIGHUP依然可能找上来。想彻底脱离终端控制，标准做法是用 setsid 启动：

bash复制setsid command

setsid 会让新进程创建新的会话，完全脱离现有终端的控制关系。这跟nohup的区别在于：nohup只是忽略SIGHUP，但进程还在原来的会话中；setsid则是“换户口”，彻底断了跟终端的父子联系。写服务守护时我优先用 setsid，它更干净。

5. 中断处理函数：从异步事件到安全临界区

前面聊的都是“信号的壳”，现在进入信号处理最核心的部分：信号处理函数内部到底能干什么，不能干什么。这是区分新手和老手的分水岭。

信号处理函数是在进程执行的任意时刻被内核异步插入的，这意味着当你的主程序正在操作一个链表、正在修改一个全局变量、甚至正在malloc分配内存时，处理函数可能突然跑起来。如果处理函数里又碰了这些共享状态，轻则数据错乱，重则死锁崩溃。

所以我写信号处理函数，永远遵守这几条铁律：

• 只做异步信号安全（async-signal-safe）的操作。POSIX明确列了一批在信号处理函数里可以安全调用的函数，包括 write()、read()、open()、close()、_exit()、sigaction() 等。而 printf()、malloc()、free()、pthread_mutex_lock() 这种一概不用，因为它们底层依赖的全局状态在信号打断的瞬间可能正处于中间状态。
• 信号处理函数尽量短。最好只在里面设置一个全局标志位，主循环自己定期检查这个标志位再做实质工作。这是一种典型的“信号只做通知，业务在主循环处理”模式，能有效避坑。
• 不要调用非异步安全的函数做日志。很多初学者喜欢在信号处理里 printf("got signal")，这在简单的demo里没问题，但放到高并发生产环境里，一旦 printf 内部锁冲突，直接死锁给你看。

一个稳妥的写法是这样的：

c复制volatile sig_atomic_t g_flag = 0;

void handler(int sig) {
    g_flag = 1;         // sig_atomic_t保证读写原子性
}

int main() {
    struct sigaction sa;
    sa.sa_handler = handler;
    sigemptyset(&sa.sa_mask);
    sa.sa_flags = 0;
    sigaction(SIGUSR1, &sa, NULL);

    while (1) {
        if (g_flag) {
            // 实际处理逻辑
            g_flag = 0;
        }
        // 正常业务
    }
}

注意我把标志位定义成了 volatile sig_atomic_t，这是C语言标准里明确说“信号处理函数与主程序共享变量时应该用这个类型”的。volatile 防止编译器把变量优化进寄存器导致主循环读不到更新，sig_atomic_t 保证读写是原子的，不会被信号处理函数打断造成半更新。

如果确实需要在信号处理函数里输出日志，最低限度是用 write() 直接写文件描述符，不走标准库缓冲：

c复制void handler(int sig) {
    const char msg[] = "signal caught\n";
    write(STDERR_FILENO, msg, sizeof(msg) - 1);
}

这种写法虽然原始，但异步安全，绝不会因为锁问题卡死。

6. 用sigaction正确捕获信号：参数、标志位、阻塞集合一次讲清

signal() 接口太简单，简单到掩盖了复杂度。到了生产环境，我几乎只用 sigaction()，因为它能精确控制每一个细节。

sigaction() 的原型长这样：

c复制#include <signal.h>

int sigaction(int signum, const struct sigaction *act, struct sigaction *oldact);

struct sigaction 有三个核心成员：

• sa_handler：信号处理函数指针，也可设为 SIG_IGN（忽略）或 SIG_DFL（恢复默认）。
• sa_mask：一个信号集合，表示“当这个处理函数正在执行时，额外阻塞哪些信号”。经常误写成“只允许处理哪些信号”，其实是“在执行期间屏蔽哪些”，避免重入。
• sa_flags：一堆行为控制标志，常用几个我列在下面。

实战中我常踩的一个坑是没有设置SA_RESTART导致read被信号打断返回EINTR。很多网络服务的主循环都在阻塞式read上等待客户端数据，如果没设SA_RESTART，一个定时信号过来，read被中断返回-1，errno被置成EINTR。新手写代码时没判断EINTR，直接当成网络错误处理，连接就被误关了。这种问题排查起来非常隐蔽，因为不是每次都触发。

正确做法是：

c复制sa.sa_flags = SA_RESTART;

或者更稳妥地，在业务代码里显式处理EINTR：

c复制while ((n = read(fd, buf, sizeof(buf))) < 0 && errno == EINTR)
    ;

这里我给一个比较完整的信号监听代码，可以当模板直接改：

c复制#include <stdio.h>
#include <signal.h>
#include <string.h>
#include <unistd.h>

static volatile sig_atomic_t got_sigterm = 0;

static void term_handler(int sig) {
    got_sigterm = 1;
}

static void setup_signals(void) {
    struct sigaction sa;

    memset(&sa, 0, sizeof(sa));
    sa.sa_handler = term_handler;
    sigemptyset(&sa.sa_mask);
    sa.sa_flags = SA_RESTART;

    if (sigaction(SIGTERM, &sa, NULL) < 0) {
        perror("sigaction(SIGTERM)");
    }
    if (sigaction(SIGINT, &sa, NULL) < 0) {
        perror("sigaction(SIGINT)");
    }
}

int main(void) {
    setup_signals();

    while (1) {
        if (got_sigterm) {
            printf("收到退出信号，开始清理并退出\n");
            // 这里做清理工作
            break;
        }
        printf("服务运行中...\n");
        sleep(2);
    }
    return 0;
}

注意我同时捕获了SIGINT和SIGTERM，因为终端Ctrl+C和kill命令默认发的信号不一样，服务往往两种都要面对。

7. 如何优雅地终止进程：SIGTERM的正确使用姿势

“优雅地终止进程”这个话题，我在服务端开发和容器环境里被问到过很多次。优雅的核心是：收到终止请求后，先停止接收新任务，再等待当前任务处理完，最后退出。如果一收到信号就直接退出，正在处理的请求可能只处理了一半，数据就处于不一致状态。

我自己总结的优雅退出模型分四步：

1. 收到SIGTERM，设置全局的 shutdown_flag = true。
2. 主循环或工作线程检查shutdown_flag，停止从队列取新任务。
3. 等待正在执行的任务自然结束，给它们一段合理的时间（比如30秒）。
4. 执行最终清理：关闭监听socket、刷新日志缓冲、释放锁资源，然后 exit(0)。

关键问题在于“等待当前任务结束”这一步。如果工作线程在阻塞中，比如正在读数据库，你需要在设计时给读操作加超时，或者在收到信号后主动唤醒线程。常见的做法是使用 poll/select/epoll_wait 配合定时器超时，定期检查shutdown_flag，而不是无限期阻塞。

另外，SIGKILL永远无法优雅处理，这是它的设计初衷。真正的优雅终止需要应用自己配合，所以运维侧要形成一种习惯：先发SIGTERM，观察进程是否在预定时间内结束，再考虑升级手段。像我管理的一些服务脚本，会这样写：

bash复制kill_process() {
    local pid=$1
    local timeout=${2:-30}

    kill "$pid"               # 先发SIGTERM
    for i in $(seq 1 "$timeout"); do
        kill -0 "$pid" 2>/dev/null || return 0
        sleep 1
    done
    kill -9 "$pid"            # 超时后升级
}

kill -0 是个非常实用的“探活”技巧——它不发送任何实际信号，只检查进程是否存在。权限满足时返回0表示进程还活着，返回非0表示进程不存在或没权限。利用它做等待循环，简洁又安全。

8. 信号在内核态与用户态的流转：深入一点也没关系

如果你做嵌入式或者想真正吃透Linux，这一节值得耐心读。信号处理的完整流程，牵涉到CPU从用户态陷入内核态再返回的过程。

当进程正在用户态执行代码时，来了一个信号，内核并不会立刻递送。真正重要的是每次系统调用返回、每次中断处理结束、每次调度器把CPU交还给这个进程时，内核都会检查当前进程的pending信号队列。如果有未阻塞的信号，就会在处理完系统调用或者中断上下文之后，转入信号递送流程。

具体到内核实现，信号递送的大致路径是：

1. 内核检查 signal_pending()，发现有待处理信号。
2. 内核选择一个信号，从pending队列里摘下信号节点。
3. 如果信号有自定义处理函数，内核会在用户态栈上构造一个特殊的返回帧，把处理函数地址、参数、返回地址设置好。
4. 恢复进程执行时，CPU会先跳转到信号处理函数。处理函数跑完后，会执行一条特殊的 rt_sigreturn 系统调用，通知内核“我处理完了”。
5. 内核恢复之前保存的上下文，进程回到被信号打断的位置继续执行。

这个过程有个微妙之处：信号处理函数的执行，本质上是在原来的用户栈上“借”了一段空间来跑，内核会先保存完整的处理器上下文（包括寄存器、状态字、指令指针），然后切换过去。所以信号处理函数的运行场所其实还是用户态，只是处于一种“被中断暂停后嵌入”的状态。

理解了这个，就能解释很多奇怪现象。比如为什么在信号处理函数里修改了某个全局变量，主程序的流控会出问题——因为两者的执行是交替的，任何非原子的跨函数共享数据都可能撕裂。再比如为什么处理函数里调用malloc有风险——malloc内部有锁，如果主程序正在malloc的过程中信号打断，处理函数再次进入malloc，同一个线程重复获取同一把锁，就是典型的重入死锁。

从性能角度看，信号并不算便宜。每次信号递送，内核要多做上下文保存、恢复和一次额外的rt_sigreturn系统调用。所以高吞吐场景下，如果能在业务代码里用事件轮询解决，就不要频繁用信号做数据面通信。信号更适合做“控制面”的通知，而不是“数据面”的搬砖。

9. 子进程退出、僵尸进程与SIGCHLD：后台服务必踩的坑

这是后台服务开发里最容易忽略、又最容易翻车的一环。

父进程fork出来的子进程退出时，并不会立刻从系统里消失。它会暂时变成僵尸进程（Zombie），保留一个最小化的进程表条目，等父进程调用 wait() 或 waitpid() 来收尸。如果父进程一直不调用wait，僵尸进程就一直占着进程表项，积累多了系统就没法创建新进程。

而 SIGCHLD 信号，就是内核在子进程退出时发给父进程的“死亡通知单”。默认行为是忽略，但父进程可以通过捕获SIGCHLD，在信号处理函数里调用waitpid为所有退出的子进程收尸。

处理SIGCHLD的标准姿势是这样的：

c复制static void child_handler(int sig) {
    int status;
    pid_t pid;
    while ((pid = waitpid(-1, &status, WNOHANG)) > 0) {
        // 记录哪个子进程退出了
    }
}

有几个细节要特别注意：

• waitpid(-1, &status, WNOHANG) 的 WNOHANG 不能少。信号处理函数可能同时收到多个子进程退出的通知（因为标准信号不排队，多个SIGCHLD会合并），所以要在处理函数里用循环把所有僵尸子进程全部收掉，直到返回0或-1。
• 如果在信号处理函数里waitpid，没设置WNOHANG，万一没有子进程可收，waitpid会一直阻塞，处理函数就卡死了，主程序也跟着遭殃。
• 另一种方案是不写SIGCHLD处理函数，而在主循环里定期 waitpid(-1, &status, WNOHANG) 轮询。两种方案都行，看你的架构更偏好事件驱动还是轮询驱动。

还有一些场景，父进程自己明确“子进程退出不用管”，可以设置SA_NOCLDWAIT标志，内核会在子进程退出时自动回收，不产生僵尸。但对大多数需要统计子进程状态的服务来说，手动waitpid更可控。

我踩过一个相关的坑：在一个多线程服务里，某一线程创建了子进程，而SIGCHLD处理函数是全局注册的。由于Linux信号是发给整个进程的，任意线程都可能接收到信号，而处理函数里的waitpid是对所有子进程生效，导致另一个线程自己管理的子进程状态被“抢走”了。解决方式是要么严格约定子进程统一归某个线程管理，要么用 sigwait 配合专用信号线程。类似的场景在嵌入式多进程架构里尤其常见。

10. 实时信号：当标准信号不够用时

前文提到标准信号有个劣根性：不排队、不携带数据。如果你的进程间通信需要“事件本身具有优先级、事件能排队、事件能附带整型数据”，那就得启用实时信号。

实时信号编号从34开始（Linux上 SIGRTMIN），一般到64（SIGRTMAX）。特性如下：

• 每个实时信号都排队，发送多少次就递送多少次，不会被合并。
• 多个实时信号递送时，编号小的优先。
• 可以通过 sigqueue() 发送实时信号，并携带一个联合体数据 sigval，接收方通过 siginfo_t 拿到这个数据。
• 对SIGRTMIN到SIGRTMAX，行为是类似的，但内核会为它们都准备独立的pending队列。

用实时信号做消息通知的一个常见场景是嵌入式设备里的多进程协作：主控进程给工作进程发SIGRTMIN+1，附带一个命令ID，工作进程收到后根据命令ID执行对应任务。相比用socket或共享内存，实时信号更轻量，适合“小通知+小数据”的场景；如果数据量大，还是乖乖用共享内存或消息队列。

发实时信号的代码长这样：

c复制#include <signal.h>

union sigval val;
val.sival_int = 42;  // 要传递的数据

if (sigqueue(target_pid, SIGRTMIN + 1, val) == -1) {
    perror("sigqueue");
}

接收端的处理函数要声明成带三个参数的形式：

c复制void rt_handler(int sig, siginfo_t *info, void *context) {
    int data = info->si_value.sival_int;
    printf("received signal %d, data=%d\n", sig, data);
}

注册时务必带上 SA_SIGINFO 标志：

c复制struct sigaction sa;
sa.sa_sigaction = rt_handler;
sigemptyset(&sa.sa_mask);
sa.sa_flags = SA_SIGINFO | SA_RESTART;
sigaction(SIGRTMIN + 1, &sa, NULL);

这里我再提醒一句：不同平台对SIGRTMIN的定义可能有偏移，而且glibc在内部可能占用少量实时信号，所以商用代码里尽量不要用SIGRTMIN本身，而是从 SIGRTMIN + 1 开始用，避开内部保留位。这个细节不留意，某些版本上会出现信号行为异常。

11. 信号与线程的纠葛：信号发给了进程还是线程？

这个话题适合有一定并发经验的朋友。Linux线程是轻量级进程（LWP），线程组内的线程共享同一个进程ID，但各自有独立的线程ID和独立的信号pending队列。信号究竟发给谁，取决于发送方式：

• kill(pid, sig) 发送信号给整个进程。进程里任意一个没有阻塞该信号的线程都可能接收并处理它，具体是哪个线程由内核调度决定。如果想确保某个线程处理，需要在信号处理函数里检查 pthread_self()，或者在特定线程里用 sigwait() 集中处理。
• pthread_kill(tid, sig) 发送信号给指定线程。这在多线程调试和精准控制时非常有用。

常见的多线程信号处理架构有两种：

方案一：全局信号处理函数 + 主循环检查标志位。 适合信号频率低、业务逻辑简单的场景。信号来了设置全局标志，主线程或工作线程轮询处理。

方案二：专用信号线程 + sigwait。 我更推荐这种，尤其当信号种类多、需要区分处理时。思路是阻塞所有信号，然后开一个专用线程调用 sigwait() 等待信号，信号到达后由这个专用线程逐条处理。这样信号处理不再打断任意线程，也就完全避开了异步重入的问题。

方案二的代码骨架：

c复制#include <signal.h>
#include <pthread.h>

static void *signal_thread(void *arg) {
    sigset_t set;
    int sig;
    sigemptyset(&set);
    sigaddset(&set, SIGTERM);
    sigaddset(&set, SIGINT);
    // 其它需要处理的信号...

    while (1) {
        if (sigwait(&set, &sig) == 0) {
            // 根据sig执行处理
        }
    }
    return NULL;
}

int main() {
    sigset_t block_set;
    sigemptyset(&block_set);
    sigaddset(&block_set, SIGTERM);
    sigaddset(&block_set, SIGINT);
    pthread_sigmask(SIG_BLOCK, &block_set, NULL);

    pthread_t tid;
    pthread_create(&tid, NULL, signal_thread, NULL);

    // 主线程正常跑业务
    while (1) { /* work */ }
}

核心逻辑是：先在主线程里阻塞所有关心的信号，避免它们被随机递送到任意线程，然后让专用线程集中等待和处理。这样主程序里的任何代码都不会被信号“半路打断”，数据一致性维护起来容易很多。

12. 常见问题与排查技巧实录

信号相关的故障排查，在网络和论坛上被反复提问的其实就那几类。我把工作中实际遇到、以及帮别人定位过的典型问题整理成一张速查表，后面再展开讲几个最经典的案例。

12.1 进程突然消失：怎么看是不是被信号杀的

排查进程消失问题，第一件事是看 dmesg。如果进程死于SIGKILL且没有人为kill，多数情况是内核OOM killer干的，这时dmesg会留下明确记录。OOM killer会优先选择占用内存大、存活时间短的进程下手，而且往往是系统内存陷入极端紧张时的“最后手段”。定位后要分清是物理内存不够，还是进程内存泄漏，是代码问题还是容量规划问题。

如果是在容器环境，还要查cgroup的日志。有些时候容器内进程被杀，不是宿主机OOM，而是cgroup内存上限触发。查的时候要注意“谁发的信号”这个方向。

12.2 Core文件到底在哪：配置和使用

SIGSEGV、SIGABRT这些信号默认会生成core文件，但很多系统上你发现根本找不到core文件。原因是core文件生成常被资源限制关掉了。检查方式：

bash复制ulimit -c

如果输出是 0，就表示core被禁用。临时开启：

bash复制ulimit -c unlimited

永久开启要写配置，不同发行版路径不同，通常是改 /etc/security/limits.conf：

bash复制* soft core unlimited

core文件默认生成在进程当前工作目录，命名通常是 core 或 core.PID。如果想统一管理，可以配置 /proc/sys/kernel/core_pattern，这个文件里写生成路径和格式。想清楚每个core文件是怎么来的，排障效率能翻好几倍。

12.3 等待子进程时被信号打断：waitpid的EINTR处理

在父进程调用 waitpid 等待子进程时，如果一个未屏蔽的信号到达，waitpid可能被中断并返回-1，errno设为EINTR。如果你不处理EINTR，就会误判成“等待出错”，可能直接把服务关了。正确处理是：

c复制while (waitpid(pid, &status, 0) < 0) {
    if (errno == EINTR)
        continue;
    // 真正的错误，处理退出逻辑
}

同样的逻辑也适用于阻塞式 read、write、accept、poll 等系统调用。EINTR是信号处理中最常见的“隐性故障源”，我甚至一度觉得每个网络服务开发者都应该在代码里搜索一遍所有阻塞调用是否处理了EINTR。

12.4 signal函数在不同平台上的差异

signal() 函数因为历史原因，在不同Unix/Linux系统上行为有微妙差异。有些系统上处理函数执行完，信号就会被重置为默认行为，导致第二次发送同样信号时直接终止进程；Linux上则通常保留了“不重置、不阻塞”的BSD语义，但这并不算标准。

这就是为什么现代C/C++工程项目里统一使用 sigaction()，而不是散落着一堆 signal() 调用。写跨平台代码时尤其要注意，宁可多写几行 sigaction，也不要在 signal 的语义坑里翻车。

12.5 kill -9杀不掉的进程：“D状态”与不可中断睡眠

偶尔你会遇到一种“特殊生物”：kill -9 都杀不掉的进程。杀不掉不是因为它免疫SIGKILL，而是因为它正处于不可中断睡眠状态（D状态）。这种状态下进程在内核态等待某个资源（通常是磁盘IO、NFS挂载、设备驱动操作），并且暂时不会处理任何信号。等内核IO操作完成，进程回到可中断状态后，SIGKILL才会生效。

遇到D状态进程，排查顺序是：查它阻塞在什么IO上，看 /proc/进程号/stack（如果权限允许），看dmesg有没有设备异常，检查是不是NFS挂了导致进程卡死在IO上。解决D状态进程的根子是解决IO问题，而不是一味地发送信号。

这个案例特别能说明一个道理：信号并不是万能的，它只是内核提供的一种控制机制，有些状态下进程根本“听不见”。

13. 实战脚本：一分钟给服务加上优雅重启能力

最后用一个完整的实战脚本来收尾。这个脚本做的事情是：根据服务名找到PID，发送SIGTERM，等待进程退出，超时则升级SIGKILL，然后再启动新进程。整个过程兼顾了安全和效率。

bash复制#!/bin/bash

SERVICE_NAME=$1
START_CMD=$2
TIMEOUT=${3:-30}

# 通过 pgrep 查找进程PID
pids=$(pgrep -f "$SERVICE_NAME")

if [ -z "$pids" ]; then
    echo "服务未在运行，直接启动"
    eval "$START_CMD"
    exit 0
fi

echo "找到进程: $pids"

# 先发SIGTERM，优雅停止
for pid in $pids; do
    kill "$pid" 2>/dev/null
done

# 等待退出，带超时
for i in $(seq 1 "$TIMEOUT"); do
    alive=""
    for pid in $pids; do
        if kill -0 "$pid" 2>/dev/null; then
            alive="$alive $pid"
        fi
    done
    if [ -z "$alive" ]; then
        echo "所有进程均已退出"
        break
    fi
    sleep 1
done

# 检查是否还有存活，有则升级为SIGKILL
final_pids=$(pgrep -f "$SERVICE_NAME")
if [ -n "$final_pids" ]; then
    echo "超时未退出，升级为SIGKILL"
    for pid in $final_pids; do
        kill -9 "$pid"
    done
fi

# 重新启动服务
echo "重新启动服务..."
eval "$START_CMD"

这个脚本在设计上有几个值得注意的决策：kill -0 用来探活避免 grep 解析PID列表的不稳定；升级SIGKILL前再次 pgrep，防止刚才SIGTERM后进程已经被替换出现误杀；启动命令用 eval 而不是直接执行，方便传入带参数的命令，但也意味着调用方要对命令字符串严格负责，否则有命令注入风险。

我实际跑这类脚本时会再包一层，让启动命令通过setsid或nohup方式运行，让新进程彻底脱离当前终端，避免脚本结束导致服务跟着退出。

14. 经验体会：把信号当成系统给你的“对话频道”

写完这些内容，我还是想多说几句。很多人学Linux停留在“多背命令”的层面，但信号这个机制最有价值的地方，在于它把“系统控制权”和“进程自主权”做了很优雅的折中。内核不能随便停掉用户进程，用户进程也不能无视内核的调度，信号就是两边沟通的唯一官方渠道。理解了这层关系，很多操作就不再是“背下来的命令”，而是“顺理成章的选择”。

我个人在实际操作中的体会是，能把 kill、nohup、trap、sigaction、sigwait 这类工具用熟，只是第一阶段。真正的进阶是，在设计服务架构时就把“信号如何处理”纳入考量——进程退出前要清理什么，子进程退出后谁来收尸，KILL信号的兜底策略是什么，哪些信号应该由专门的线程集中处理。把这些想清楚了，服务在异常场景下的表现会有质的提升。

最后再分享一个我一直保留的习惯：给服务写启动脚本时，永远加上SIGTERM和SIGINT处理的日志埋点。这样一旦线上出现“进程被神秘终止”的事件，翻日志的第一行就能看到信号来源和退出码，省下无数排查时间。信号是“轻量”的，但留下的痕迹，往往是最重的排障线索。