手把手解析：Linux fork与exec中的信号继承（所有程序员都需要知道的信号科学）

本文链接：https://blog.youkuaiyun.com/shuaige_shiwoa/article/details/145904706

手把手解析：Linux fork与exec中的信号继承（所有程序员都需要知道的信号科学）

一、程序员的"分身术"——理解进程诞生

在Linux的世界里，创建新进程就像施展分身术。当一个程序需要同时处理多个任务时，fork()函数是每个掌控者的必备技能。想象一下你正在运行一个计算器程序，当你点击"新建窗口"时，就是这个原理在起作用。

1.1 fork魔法的基础原理

使用fork()时，系统会创建当前进程的精确复制体（clone），出现父子进程的特写场景：

pid_t pid = fork();
if (pid == 0) {
    // 这是子进程的舞台
    printf("我是子进程，我的ID是%d\n", getpid());
} else {
    // 这里属于父进程专区
    printf("我创造了子进程%d\n", pid);
}

此时的信号配置会像基因一样被完整克隆：

信号处理函数表（struct sigaction）
信号屏蔽掩码（signal mask）
未决信号（pending signals）
信号栈设置（sigaltstack）

这意味着，如果你在父进程中使用signal(SIGINT, handler)设置了信号处理函数，子进程在诞生时就已经携带了这个设定。

二、exec变形记：进程的重生仪式

当遇到exec系列函数（execv/execl等），原进程会经历凤凰涅槃式的重生——原执行映像被完全替换，但有些属性却如同基因般保留。

2.1 exec前后的信号对比

通过对比表理解继承规则：

信号属性	fork继承	exec保留
信号处理函数	✔	✘*
信号屏蔽掩码	✔	✔
未决信号	✔	✘
信号忽略设置	✔	✔
信号栈设置	✔	✔

（注：带*表示例外：SIG_IGN和SIG_DFL会保留）

示例验证：使用signal()与sigaction()的区别

// 父进程设置：
signal(SIGTERM, custom_handler);  // 会被exec丢弃
sigaction(SIGINT, &sa_ignore, NULL); // SA_SIGINFO会被保留吗？

打开终端测试：

strace -e signal,execve ./test_program
# 观察exec前后的信号设置变化

三、信号世界的遗传法则深度解析

3.1 fork后的基因密码

子进程会继承父进程的完整信号上下文：

信号handler副本（包括内存地址中的函数指针）
各信号的阻塞状态（sigprocmask设置）
待处理的信号队列拷贝

这时一个隐藏的陷阱：使用pthread创建的线程中调用fork，会导致只复制调用线程（POSIX规定）。比如在多线程环境操作文件描述符时，可能导致状态不一致。

3.2 exec后的属性残留

执行exec时，内核会执行signal reinstantiation：

遍历所有信号（1~31）
检测当前的处置方式：
- 如果是SIG_IGN（忽略）：保持忽略
- 其他情况：重置为SIG_DFL

但以下设置具有抗性：

使用sigaction设置的SA_NOCLDWAIT标志
SIGCHLD的处理为SIG_IGN时的特殊行为
通过fnctl设置的O_ASYNC信号驱动I/O

四、生产环境的"信号地雷"拆解指南

案例1：僵尸进程的诞生之谜

// 不当代码示例
signal(SIGCHLD, SIG_IGN); // 自动回收子进程
if (fork() == 0) {
    execl("/bin/sleep", "sleep", "60", NULL);
}

此时父进程的SIG_IGN会通过exec保留吗？答案是：会！因为POSIX规定，设置SIGCHLD为SIG_IGN时，子进程会自动被回收，无需wait。

案例2：信号丢失的悬案

// 父进程中有：
sigset_t mask;
sigaddset(&mask, SIGUSR1);
sigprocmask(SIG_BLOCK, &mask, NULL);

// fork后子进程调用exec
// 父进程发送SIGUSR1给子进程...

此时信号会被递送吗？由于信号被继承的mask阻塞，需要子进程在exec后解除阻塞才能接收。

五、掌握信号的终极实战技巧

5.1 信号继承最佳实践

// 在exec前清理信号环境
sigset_t empty_set;
sigemptyset(&empty_set);
sigprocmask(SIG_SETMASK, &empty_set, NULL);

// 显式设置需要忽略的信号
struct sigaction sa;
sa.sa_handler = SIG_IGN;
sigaction(SIGPIPE, &sa, NULL);

5.2 调试信号问题的核武器

使用gdb检查信号状态：

(gdb) handle SIGINT print nostop
(gdb) info signals
(gdb) p * (struct sigaction *)0x7fff5678  # 查看某个信号处理结构体

查看内核状态的命令：

cat /proc/[pid]/status | grep Sig
# 输出示例：
SigBlk: 0000000000000000
SigIgn: 0000000000001000
SigCgt: 0000000180000000

六、信号机制的底层揭秘

（系统调用流程图：从用户态到内核态的信号处理过程）

当执行execve()系统调用时，内核会执行fs/exec.c中的do_execveat_common()函数。其中的关键操作：

调用flush_old_exec()清理原进程资源
在setup_new_exec()中重置信号处理：flush_signal_handlers(current, 0);

在linux/kernel/signal.c中的关键代码片段：

void flush_signal_handlers(struct task_struct *t, int force_default)
{
    for (i = 0; i < _NSIG; i++) {
        if (force_default || t->sighand->action[i].sa.sa_handler != SIG_IGN)
            t->sighand->action[i].sa.sa_handler = SIG_DFL;
    }
}

七、开放思考题：拥抱现代Linux

随着Linux内核的演进，新的信号特性也在不断出现。例如：

signalfd()：把信号转换为文件描述符事件
pidfd_send_signal()：通过pidfd发送信号
实时信号（SIGRTMIN+）的特殊处理

handler = SIG_DFL;
}
}


## 七、开放思考题：拥抱现代Linux

随着Linux内核的演进，新的信号特性也在不断出现。例如：

1. signalfd()：把信号转换为文件描述符事件
2. pidfd_send_signal()：通过pidfd发送信号
3. 实时信号（SIGRTMIN+）的特殊处理

当这些新机制遇到fork/exec时，会产生怎样的连锁反应？这个问题留待聪明的读者去实践探索。不妨试着重现文中案例，在最新的Linux 6.x内核上观察行为差异。