【Linux进程信号】信号的产生

作者：爱写代码的刚子

时间：2024.3.7

前言：本篇博客将会介绍Linux信号的基本概念，以及信号的产生

信号概念

生活中的信号

你在网上买了很多件商品，再等待不同商品快递的到来。但即便快递没有到来，你也知道快递来临时， 你该怎么处理快递。也就是你能“识别快递” 当快递员到了你楼下，你也收到快递到来的通知，但是你正在打游戏，需5min之后才能去取快递。那 么在在这5min之内，你并没有下去去取快递，但是你是知道有快递到来了。也就是取快递的行为并不是一定要立即执行，可以理解成“在合适的时候去取”。 在收到通知，再到你拿到快递期间，是有一个时间窗口的，在这段时间，你并没有拿到快递，但是你知道有一个快递已经来了。本质上是你“记住了有一个快递要去取” 当你时间合适，顺利拿到快递之后，就要开始处理快递了。而处理快递一般方式有三种:1. 执行默认动 作(幸福的打开快递，使用商品)2. 执行自定义动作(快递是零食，你要送给你你的女朋友)3. 忽略快 递(快递拿上来之后，扔掉床头，继续开一把游戏) 快递到来的整个过程，对你来讲是异步的，你不能准确断定快递员什么时候给你打电话

技术应用角度的信号

信号是给进程发送的，进程要具备识别+处理信号的能力（信号的处理能力属于进程内置功能的一部分）：

• 该能力一定是预先早就已经有了的（即便没有收到信号，也要知道哪些信号该怎么处理）

• 进程能够识别对应的信号

• 当进程真的收到了一个具体的信号的时候，进程可能并不会立即处理这个信号，合适的时候再处理

• 一个进程必须当信号产生，到

进程这种识别与处理信号的能力是程序员写的，OS提供的。对于进程来讲，即便是信号还没有产生，我们进程已经具有识别和处理这个信号的能力了。

举例：

用户输入命令,在Shell下启动一个前台进程。

• ./a.out

• . 用户按下Ctrl-C ,这个键盘输入产生一个硬件中断，被OS获取，解释成信号，发送给目标前台进程
• . 前台进程因为收到信号，进而引起进程退出

用户输入命令,在Shell下启动一个后台进程.

• ./a.out &
• 后台进程没办法使用Ctrl-C的方式来终止进程，但是可以使用kill -9 进程pid的方式来终止

注意

1. Ctrl-C 产生的信号只能发给前台进程。一个命令后面加个&可以放到后台运行,这样Shell不必等待进程 结束就可以接受新的命令,启动新的进程。
2. Shell可以同时运行一个前台进程和任意多个后台进程,只有前台进程才能接到像 Ctrl-C 这种控制键产生 的信号。
3. 前台进程在运行过程中用户随时可能按下 Ctrl-C 而产生一个信号,也就是说该进程的用户空间代码执行 到任何地方都有可能收到 SIGINT 信号而终止,所以信号相对于进程的控制流程来说是异步（Asynchronous）的。
4. linux一次登陆只允许一个前台进程，用户的进程变成前台进程了，bash进程就会变成后台进程，输入的命令也就无效了。
5. 前后台进程的区分就是谁能获取键盘的输入（只有前台能获取键盘输入）。
6. 为什么bash进程不受Ctrl-C指令的影响？因为bash进程本身对Ctrl-C信号进行了处理。
7. 后台进程可以存在多份。
8. 当后台进程在往显示器上输出内容时，为什么键盘也能运行指令？因为输出有输出缓冲区，输入有输入缓冲区。为什么我们输入命令时显示器会变乱？因为显示器可以看作一个共享资源，由于共享资源并没有做保护，多进程竞争资源会导致混乱。
9. Ctrl-C本质是被进程解释成收到了2号信号(2号信号的默认动作就是终止自己)。

信号概念

信号是进程之间事件异步通知的一种方式，属于软中断。

信号的本质就是模拟中断的行为(仿造硬件中断实现的软件逻辑)

用kill -l命令可以察看系统定义的信号列表

• kill -l查看信号

注意没有0号信号，没有32和33号信号，总共有62个信号

其中1-32信号为普通信号(可以进行保存)

34-64为实时信号（实时进行处理）

信号就是数字，只是定义为宏

• 每个信号都有一个编号和一个宏定义名称,这些宏定义可以在signal.h中找到,例如其中有定义#define SIGINT 2

• 编号34以上的是实时信号,本章只讨论编号34以下的信号,不讨论实时信号。这些信号各自在什么条件下 产生,默认的处理动作是什么,在signal(7)中都有详细说明: man 7 signal

信号处理常见方式概览

(sigaction函数后面详细介绍),可选的处理动作有以下三种(只能3选一):

1. 忽略此信号。
2. 执行该信号的默认处理动作。
3. 提供一个信号处理函数,要求内核在处理该信号时切换到用户态执行这个处理函数,这种方式称为捕捉（Catch）一个信号。（自定义动作也叫信号的捕捉）

• signal函数设置信号的自定义处理方法

**typedef void (*sighandler_t)(int);**这个是函数指针类型signal函数的第二个参数为函数指针

• 再次修改代码：

signal只需要设置一次，往后进程的生命周期内都有效!只有产生了对应信号，signal方法才会被调用，否则不会进行调用

• 如果在程序的后面设置信号处理函数，那么在这之前发生的信号可能会被忽略或者采用默认的处理方式。因此，为了确保程序中的所有信号都被正确处理，最好在程序开始的地方设置信号处理函数:

此时signal函数并没有被调用。

同时我们要知道，有些信号可以自定义，有些信号不能

• handler方法是可以被多个进程捕捉的，所以signo参数是可以用来区分不同的信号的

信号的产生是随机的，所以信号的产生和我们自己的代码运行是异步的

产生信号

通过终端按键产生信号

SIGINT的默认处理动作是终止进程,SIGQUIT的默认处理动作是终止进程并且Core Dump,现在我们来验证一下。

Core Dump

首先解释什么是Core Dump。当一个进程要异常终止时,可以选择把进程的用户空间内存数据全部 保存到磁盘上,文件名通常是core,这叫做Core Dump。进程异常终止通常是因为有Bug,比如非法内存访问导致段错误, 事后可以用调试器检查core文件以查清错误原因,这叫做Post-mortem Debug(事后调试)。一个进程允许 产生多大的core文件取决于进程的Resource Limit(这个信息保存 在PCB中)。默认是不允许产生core文件的, 因为core文件中可能包含用户密码等敏感信息,不安全。在开发调试阶段可以用ulimit命令改变这个限制,允许 产生core文件。 首先用ulimit命令改变Shell进程的Resource Limit,允许core文件最大为1024K:$ ulimit -c 1024

进程控制篇的图：

core dump标志位0/1表示是Term这种方式还是Core方式

• 可是我们发现，即使发送8号信号，core dump信号标识位依旧是0

补充知识：虚拟机发生程序崩溃时，会产生一个临时文件：core.XXX,但是默认云服务器上面的core功能是被关闭的

• ulimit -a查看系统中标定的配置，进程使用相关资源时进行限制

• core被关闭了：

• ulimit -c 1024设置core file size大小

• 现在core dump标识位置为1了

• 同时我们发现当前目录下形成了一个core文件

打开系统的core dump功能，一旦进程出异常，OS会将进程在内存中的运行信息，给我dump（转储）到进程的当前目录（磁盘）形成core.pid文件：核心转储(core dump)

运行时出错，除了操作系统通过信号，退出码要告诉我们为什么要退出，还要告诉我们在哪一行出现错误（通过core dump）。

注意，要使用core dump功能，编译器必须编译时带上-g选项！！！

如何查看core-file所携带的调试信息？

• 第一步：编译时带**-g选项**

• 第二步：gdb+可执行文件

• 第三步：core-file +core文件

直接复现问题之后，直接定位到出错行，先运行，再core-file（事后调试）

【问题】：这么”好“的功能为什么云服务器要关闭呢？

我们发现core-file文件比较大，在服务器中，服务一但挂掉，就会自动重启，可能会形成很多的core文件，可能导致本来是一个简单的云服务挂掉了，慢慢变成一个磁盘问题，操作系统可能会挂。这个功能要被禁掉，因为我们要保证服务重启的功能一直都要有效

调用系统函数向进程发信号

kill命令是调用kill函数实现的。kill函数可以给一个指定的进程发送指定的信号。raise函数可以给当前进程发送指定 的信号(自己给自己发信号)。

#include <signal.h>
int kill(pid_t pid, int signo); 
int raise(int signo); 
//这两个函数都是成功返回0，错误返回-1
//raise可以用kill函数来代替

• kill函数

• 用kill函数实现一个mykill程序:

• raise函数

abort函数使当前进程接收到信号而异常终止:

#include <stdlib.h>
void abort(void); //6号信号,abort使这个进程即使捕捉了6号信号也要终止程序，所以
//并不等于kill(getpid(),6);
就像exit函数一样，abort函数总是会成功的，所以没有返回值。

由软件条件产生信号

SIGPIPE是一种由软件条件产生的信号，在“管道”中已经介绍过了（读端关闭，写端一直写，操作系统会发送SIGPIPE信号）

软件资源不就绪，比如读端要读取没有打开的文件采用返回值的形式返回错误，这取决于操作系统的设计，异常可以由软件产生。

主要介绍alarm函数和SIGALRM信号。（软件条件）

#include <unistd.h>
unsigned int alarm(unsigned int seconds);
//调用alarm函数可以设定一个闹钟，也就是告诉内核在seconds秒之后给当前进程发SIGALRM信号，该信号的默认处理动作是终止当前进程。

对应信号:

这个函数的返回值是0或者是以前设定的闹钟时间还余下的秒数。打个比方，某人要小睡一觉，设定闹钟为30分钟之后响,20分钟后被人吵醒了,还想多睡一会儿,于是重新设定闹钟为15分钟之后响,“以前设定的闹钟时间还余下的时间”就 是10分钟。如果seconds值为0,表示取消以前设定的闹钟,函数的返回值仍然是以前设定的闹钟时间还余下的秒数

• 演示：

• 信号捕捉：

• 每隔5秒响一次

• 所以我们可以通过alarm函数设置定时任务。

返回值一定要注意，闹钟可能被重复设置的，新设置闹钟的返回值是上一次闹钟剩余的时间可以使用alarm()函数来设置一个定时器，但是这个函数通常只能设置一个全局的闹钟。为了实现多个闹钟，可能需要使用其他技术，比如使用多线程或者使用定时器库

• 中途发送kill -14 pid来验证返回值:

多次发送信号可能得到不同的返回值，但是目前用不到alarm函数的返回值。

操作系统中会存在大量的闹钟，所以OS需要管理闹钟（先描述再组织，增删查改），用最小堆管理，（堆顶数据没有超时，整个堆也就没有超时，不用遍历整个闹钟）

一个闹钟在未来什么时候触发：时间戳来衡量，存在于闹钟的结构体中。

由硬件异常产生信号

硬件异常被硬件以某种方式被硬件检测到并通知内核,然后内核向当前进程发送适当的信号。例如当前进程执行了除 以0的指令,CPU的运算单元会产生异常,内核将这个异常解释 为SIGFPE信号发送给进程。再比如当前进程访问了非法内存地址,MMU会产生异常,内核将这个异常解释为SIGSEGV信号发送给进程。

【问题】:键盘数据是如何输入给内核的，ctrl+c又是如何变成信号的？

键盘被摁下，操作系统是先知道，那OS怎么知道键盘上有数据？

那CPU中的寄存器凭什么能保存数据呢?

给针脚发送高低电瓶的过程，0代表小的存储单元里没有电信号，1代表了存储了电信号（存储释放数据也就是充放电的过程）

我们学习的信号，就是用软件方式，对进程模拟的硬件中断

【问题】：如果键盘中的数据是ctrl+c组合键呢？

操作系统在进行拷贝之前，会对键盘中的数据进行判断（是数据还是控制）如果是控制（ctrl+c）会转换成为2号信号发送给进程

所以键盘是基于中断来进行工作的。但是数据拷贝的过程CPU不参与,由负责I/O的芯片（DMA芯片）

【问题】:在之前学习文件系统的时候，进程读数据（磁盘上的数据往内存里读），磁盘要进行寻址，进程要读，于是进程就要阻塞等待磁盘找到数据，那么操作系统如何知道磁盘找到数据了？

磁盘找到了数据，磁盘也会向CPU发送中断,所以操作系统知道了，所以再将进程的状态从等待状态变成运行状态，之后再执行read。

操作系统怎么知道数据已经读完了？磁盘拷贝完成也会向CPU发生中断,于是操作系统知道了。

所以在后台进程打印时，即使输入指令打印的数据是乱的，但是命令依旧能够执行，因为该命令的数据存放在键盘单独的缓冲区。

信号捕捉初识

键盘组合键：

ctrl + c :2

ctrl + \ :3 中断信号

不是所有的信号都是可以被signal捕捉的，比如：

19号信号(ctrl + z :将当前正在前台运行的程序挂起(暂停)并放入后台。)

9号信号

模拟野指针异常

由此可以确认，我们在C/C++当中除0，内存越界等异常，在系统层面上，是被当成信号处理的。

举个信号捕捉的例子:

证明收到了8号信号：

收到了8号信号，由于我们自定义了信号的处理方法，所以进程并没有立即退出。

但是，我们看到handler方法在一直被调用。

同理：

• man 7 siganl查看信号的具体内容

捕捉完SIGSEGV信号后进程并没有退出而是一直打印。

所以进程收到异常信号，不一定退出（捕捉了信号），但是程序出现异常，一定收到了信号

【问题】：为什么除0，野指针会让进程崩溃呢？（换个问法，为什么会给进程发信号呢？操作系统怎么检测到的？）

除0问题：

CPU内有状态寄存器和pc指针，CPU内有溢出标识位，CPU内还有许多的寄存器数据，也叫做进程的上下文。（进程出异常与进程切换无关）虽然我们修改的是CPU内部的状态寄存器，但是只影响当前进程。（程序出异常只会影响进程本身，并不会波及操作系统），操作系统必须要知道标识位是否溢出，因为操作系统是硬件的管理者。

• 异常问题转化成硬件问题，表现在硬件上，进而被操作系统识别，对异常信息做处理，只会影响当前进程（寄存器的上下文）

野指针问题：

野指针问题通常是未初始化或已释放的指针出现了虚拟地址转物理地址失败，MMU（内存管理单元）会出现报错，转化失败的地址就会放在CPU的一个寄存器上。

操作系统怎么知道当前异常是溢出还是越界？（不同种类的硬件报错）

那我进程出现异常就是不崩溃呢？（那该进程就会一直被调度，但是一调度就会崩溃（硬件问题一直存在，存在进程的上下文中））

所以异常的捕捉并不是要用户解决问题，而是提供出错的原因。信号处理是异常处理的子集

总结

• 上面所说的所有信号产生，最终都要有OS来进行执行，为什么?OS是进程的管理者

• 信号的处理是否是立即处理的?在合适的时候

• 信号如果不是被立即处理，那么信号是否需要暂时被进程记录下来?记录在哪里最合适呢?

• 一个进程在没有收到信号的时候，能否能知道，自己应该对合法信号作何处理呢?

• 如何理解OS向进程发送信号？能否描述一下完整的发送处理过程？