一、从不同角度理解信号
1、生活角度的信号
你在网上买了很多件商品,在等待不同商品快递的到来。但即便快递没有到来,你也知道快递来临时,你该怎么处理快递,也就是你能 “识别快递”。
当快递员到了你楼下,你也收到快递到来的通知,但是此时你正在打游戏,需 5min 之后才能去取快递。那么在在这 5min 之内,你并没有下去去取快递,但是你是知道有快递到来了。也就是取快递的行为并不是一定要立即执行,可以理解成 “在合适的时候去取”。
在收到通知,再到你拿到快递期间,是有一个时间窗口的,在这段时间内,你并没有拿到快递,但是你知道有一个快递已经来了。本质上是你 “记住了有一个快递要去取”。
当你时间合适,顺利拿到快递之后,就要开始处理快递了。而处理快递一般方式有三种:
- 1、执行默认动作(幸福的打开快递,使用商品);
- 2、 执行自定义动作(快递是零食,你要送给你你的女朋友);
- 3. 忽略快递(快递拿上来之后,扔掉床头,继续开一把游戏)。
快递到来的整个过程对你来讲是异步的,你不能准确断定快递员什么时候给你打电话。
在生活中也存在着很多信号,比如闹钟、电话铃响、红绿灯等等,这里就有下面两个问题:
为什么我们能认识红绿灯或者闹钟呢?
因为曾经有人教过我们红绿灯或着闹钟是什么,然后我们记住的。
身边没有闹钟时,我们是否知道闹钟响了之后,该怎么办?
当然知道,因为曾经有人教过我们,教我们的是:它是什么,为什么,怎么办。这两个问题对应是什么和怎么办。而为什么,是我们需要被提醒,所以要认识闹钟。
所以对于是什么和怎么办这个话题称为人能够识别信号。OS 类似社会,人就是进程,社会中会有很多信号围绕着人去展开,而 OS 中也会有很多信号围绕着信号去展开,所以进程要能够识别非常多的信号。这里只想说明进程能够认识信号,以及信号不管到没到来进程都知道该怎么做。
2,技术应用角度的信号
通过一段代码理解信号
#include <stdio.h>
#include <unistd.h>
int main()
{
while (1){
printf("hello signal!\n");
sleep(1);
}
return 0;
}
我们知道该程序的运行结果就是死循环地进行打印,而对于死循环来说,最好的方式就是使用Ctrl+C对其进行终止。
为什么使用Ctrl+C后,该进程就终止了?
实际上当用户按Ctrl+C时,这个键盘输入会产生一个硬中断,被操作系统获取并解释成信号(Ctrl+C被解释成2号信号),然后操作系统将2号信号发送给目标前台进程,当前台进程收到2号信号后就会退出。
我们可以使用signal函数对2号信号进行捕捉,证明当我们按Ctrl+C时进程确实是收到了2号信号。
使用signal函数时,我们需要传入两个参数,第一个是需要捕捉的信号编号,第二个是对捕捉信号的处理方法,该处理方法的参数是int,返回值是void。
例如,下面的代码中将2号信号进行了捕捉,当该进程运行起来后,若该进程收到了2号信号就会打印出收到信号的信号编号。
#include <stdio.h>
#include <signal.h>
#include <unistd.h>
void handler(int sig)
{
printf("get a signal:%d\n", sig);
}
int main()
{
signal(2, handler); //注册2号信号
while (1){
printf("hello signal!\n");
sleep(1);
}
return 0;
}
此时当该进程收到2号信号后,就会执行我们给出的handler方法,而不会像之前一样直接退出了,因为此时我们已经将2号信号的处理方式由默认改为了自定义了。
由此也证明了,当我们按Ctrl+C时进程确实是收到了2号信号。
注意:
- Ctrl+C产生的信号只能发送给前台进程。在一个命令后面加个&就可以将其放到后台运行,这样Shell就不必等待进程结束就可以接收新的命令,启动新的进程。
- Shell可以同时运行一个前台进程和任意多个后台进程,但是只有前台进程才能接到像Ctrl+C这种控制键产生的信号。
- 前台进程在运行过程中,用户随时可能按下Ctrl+C而产生一个信号,也就是说该进程的用户空间代码执行到任何地方都可能收到SIGINT信号而终止,所以信号相对于进程的控制流程来说是异步的。
3.什么是linux进程信号
进程信号是 Linux 中用于进程间通信和控制的一种机制。
当一个进程需要发送一个信号给另一个进程时,可以调用 kill
系统调用或向指定进程发送信号。
当一个进程接收到一个信号时,操作系统会做出相应的处理,并将信号交给进程的信号处理函数处理
信号是进程之间事件异步通知的一种方式,属于软中断。
4.进程处理信号的概览
1、进程收到信号就会立即处理吗?
进程收到某种信号的时候,并不是立即处理的。比如远处看到红绿灯变成红灯,我们会立即停下吗?并不会,我们会把看到红灯这件事记录在大脑中,等走到路口再停下
进程当前可能在执行优先级更高的东西,所以要选择合适的时候再处理这个信号。
2、没有被立即处理的信号放在哪?
我们看到红灯的时候,会把看到红灯这件事存在大脑中。
既然信号不能被立即处理,已经到来的信号会被暂时保存起来,以供在合适的时候处理,应该保存在哪里呢??——》进程控制块 task_struct
3、谁负责把信号存到指定位置?
信号的本质就是数据,发送信号 ——》向进程控制块 task_struct写入数据 ——》但是进程控制块属于内核,内核不相信任何人,所以由谁来写入数据 ——》 OS!!
5、查看系统定义的信号列表
我们前面也简单的接触过信号,kill -l 就可以查看信号
仔细观察可以发现这里不是 64 种信号,因为中间并不是连续的,一种有 62 种信号(其中,没有 32 和 33 信号)。 其中,1~31 叫做普通信号,而 34~64 叫做实时信号,每个实时信号中都包含了 RT 两个字母。 实时信号是一种响应特别强的信号,比如着火,而普通信号则对应我们每天早上的闹钟。
这么多信号,其对应功能是什么呢?
- 可以通过
man 7 signal
进行查询往下翻就能看到
- 每个信号都有一个编号和一个宏定义名称,这些宏定义可以在 signal.h 中找到,例如其中有定义 #define SIGINT 2
6.信号的处理过程
6.1.信号是如何记录的?
实际上,当一个进程接收到某种信号后,该信号是被记录在该进程的进程控制块 task_struct 当中的。
你买了一个快递,于我而言,我当然知道寄来的是什么,而快递员是男是女,多大年纪这并不重要,重要的是快递是否到了,里面的东西是否完整无损。所以对进程来说,最重要的无非就是 “是否有信号” + “是谁”。
操作系统提供了 31 个普通信号,所以我们采用位图来保存信号,也就是说在 task_struct 结构中只要写上一个 unsigned int signals; (00000000 … 00000000) 这样一个字段即可。比特位的位置代表是哪一个信号,比特位的内容用 0 1 来代表是否。
其中比特位的位置代表信号的编号,而比特位的内容就代表是否收到对应信号,比如第6个比特位是1就表明收到了6号信号。
6.2.信号是如何发送的?
发送信号的本质就是写对应进程 task_struct 信号位图。因为 OS 是系统资源的管理者,所以把数据写到 task_struct 中只有 OS 有资格、有义务。所以,信号是操作系统发送的,通过修改对应进程的信号位图(0 -> 1)完成信号的发送,再朴素点说就是信号不是 OS 发送的,而是写的。
6.3.信号是如何产生的?
- 接下来再看信号的产生(kill,键盘),不管信号是如何产生的,最后都一定要经过 OS,再到进程。
- kill 当然是命令,是在 bash 上的,也就是在系统调用之上,所以 kill 的底层一定使用了操作系统某种接口来完成像目标进程写信号的过程。
- 键盘是一种硬件,它所产生的各种组合键会产生各种不同的数据,OS 作为硬件的管理者,键盘上所获得的各种数据,一定是先被 OS 拿到。
- 所以,虽然信号的产生五花八门,但归根结底所有信号的产生后都是间接或直接由 OS 拿到后向目标进程发信号。
一个进程收到信号,本质就是该进程内的信号位图被修改了,也就是该进程的数据被修改了,而只有操作系统才有资格修改进程的数据,因为操作系统是进程的管理者。也就是说,信号的产生本质上就是操作系统直接去修改目标进程的task_struct中的信号位图。
注意: 信号只能由操作系统发送,但信号发送的方式有多种。
6.4.信号是如何被处理的
- 执行该信号的默认处理动作。
- 提供一个信号处理函数,要求内核在处理该信号时切换到用户态执行这个处理函数,这种方式称为捕捉(Catch)一个信号。
- 忽略该信号。
6.5.总结
我们可以类比上面的例子
把进程当作人
(1)(信号产生前)
进程虽然现在没有收到任何信号,但是进程知道之后,收到信号之后,该怎么做.
- 进程内部一定能够识别信号
- 识别是程序员设计进程的时候,已经内置了处理方案
- 信号属于进程内部特有的特征
(2)(信号到来) 当信号到来的时候,进程可能正在处理更重要的事情,信号可能不会被立即处理,等合适的时候在进行处理
- 信号来了,处理信号前,信号必须暂时被进程保管起来
(3)(信号处理)对信号进行处理
- 默认行为(终止进程,暂停,继续运行等)
- 自定义行为
- 忽略信号
二,进程信号的产生
2.1.通过终端按键产生信号
系统卡死遇到过吧?程序死循环遇到过吧?这些都是比较常见的问题,当发生这些问题时,我们可以通过 键盘键入 ctrl + c
发出 2
号信号终止前台进程的运行
当面对下面的死循环程序时,我们可以按Ctrl+C可以终止该进程。
但实际上除了按Ctrl+C之外,按Ctrl+\也可以终止该进程。
按Ctrl+C终止进程和按Ctrl+\终止进程,有什么区别?
- 按Ctrl+C实际上是向进程发送2号信号SIGINT
- 而按Ctrl+\实际上是向进程发送3号信号SIGQUIT。
查看这两个信号的默认处理动作,可以看到这两个信号的Action是不一样的,
- 2号信号是Term
- 3号信号是Core
Term和Core都代表着终止进程,但是Core在终止进程的时候会进行一个动作,那就是核心转储。
什么是核心转储?
在云服务器中,核心转储是默认被关掉的,我们可以通过使用ulimit -a
命令查看当前资源限制的设定。
②查看结果显示core文件的大小为0,即表示核心转储是被关闭的。
通过ulimit -c size命令来设置core文件的大小。
core文件的大小设置完毕后,就相当于将核心转储功能打开了。此时如果我们再使用Ctrl+\对进程进行终止,就会发现终止进程后会显示core dumped
。
并且会在当前路径下生成一个core文件,该文件以一串数字为后缀,而这一串数字实际上就是发生这一次核心转储的进程的PID。
说明一下: ulimit命令改变的是Shell进程的Resource Limit,但myproc进程的PCB是由Shell进程复制而来的,所以也具有和Shell进程相同的Resource Limit值。
核心转储功能有什么用?
当我们的代码出错了,我们最关心的是我们的代码是什么原因出错的。如果我们的代码运行结束了,那么我们可以通过退出码来判断代码出错的原因,而如果一个代码是在运行过程中出错的,那么我们也要有办法判断代码是什么原因出错的。
当我们的程序在运行过程中崩溃了,我们一般会通过调试来进行逐步查找程序崩溃的原因。而在某些特殊情况下,我们会用到核心转储。
核心转储指的是操作系统在进程收到某些信号而终止运行时,将该进程地址空间的内容以及有关进程状态的其他信息转而存储到一个磁盘文件当中,这个磁盘文件也叫做核心转储文件,一般命名为core.pid。
而核心转储的目的就是为了在调试时,方便问题的定位。
如何运用核心转储进行调试?
我们用下面这段代码进行演示:
很明显,该代码当中出现了除0错误,该程序运行3秒后便会崩溃。
此时我们便可以在当前目录下看到核心转储时生成的core文件。
使用gdb对当前可执行程序进行调试,然后直接使用core-file core文件
命令加载core文件,即可判断出该程序在终止时收到了8号信号,并且定位到了产生该错误的具体代码。
说明一下: 事后用调试器检查core文件以查清错误原因,这种调试方式叫做事后调试。
core dump标志
还记得进程等待函数waitpid函数的第二个参数吗:
pid_t waitpid(pid_t pid, int *status, int options);
waitpid函数的第二个参数status是一个输出型参数,用于获取子进程的退出状态。
status是一个整型变量,但status不能简单的当作整型来看待,status的不同比特位所代表的信息不同,具体细节如下(只关注status低16位比特位):
- 若进程是正常终止的,那么status的次低8位就表示进程的退出状态,即退出码。
- 若进程是被信号所杀,那么status的低7位表示终止信号,而第8位比特位是core dump标志,即进程终止时是否进行了核心转储。
打开Linux的核心转储功能,并编写下列代码。
代码中父进程使用fork函数创建了一个子进程,子进程所执行的代码当中存在野指针问题,当子进程执行到*p = 100时,必然会被操作系统所终止并在终止时进行核心转储。
此时父进程使用waitpid函数便可获取到子进程退出时的状态,根据status的第7个比特位便可得知子进程在被终止时是否进行了核心转储。
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/wait.h>
#include <sys/types.h>
int main()
{
if (fork() == 0){
//child
printf("I am running...\n");
int *p = NULL;
*p = 100;
exit(0);
}
//father
int status = 0;
waitpid(-1, &status, 0);
printf("exitCode:%d, coreDump:%d, signal:%d\n",
(status >> 8) & 0xff, (status >> 7) & 1, status & 0x7f);
return 0;
}
可以看到,所获取的status的第7个比特位为1,即可说明子进程在被终止时进行了核心转储。
因此,core dump标志实际上就是用于表示程序崩溃的时候是否进行了核心转储。
云服务器为什么默认关闭core dump ,本地虚拟机环境是打开的?
core dump是给编译器看的(二进制文件),只要程序core dump就要在磁盘中形成临时文件。一旦服务挂掉,搞运维的最重要的动作不是找到挂掉的原因,而是先让服务器跑起来,让服务正常运行,再找原因。服务挂掉了一定是大量的重启操作,大公司有自己的自动化重启程序,让它自动重启。
如果代码是自己写的,经常跑起来就挂,就会产生大量的临时文件,如果把部署目录塞满了。写不进去相关的日志信息,甚至是临时文件把系统盘打满了,系统无法正常运行。一般云服务器允许你异常,崩溃,但不允许core dump.
不是所有的信号都需要core dump
其他组合按键?
我们可以通过以下代码,将1~31号信号全部进行捕捉,将收到信号后的默认处理动作改为打印收到信号的编号。
#include <stdio.h>
#include <unistd.h>
#include <signal.h>
void handler(int signal)
{
printf("get a signal:%d\n", signal);
}
int main()
{
int signo;
for (signo = 1; signo <= 31; signo++){
signal(signo, handler);
}
while (1){
sleep(1);
}
return 0;
}
此时,当我们按下组合按键Ctrl+C、Ctrl+\、Ctrl+Z后,便可以得知这些组合按键分别是向前台进程发送几号信号了。
但如果我们此时向该进程发送9号信号,该进程并不会打印收到了9号信号,而是执行收到9号信号后的默认处理动作,即被终止。
说明: 有些信号是不能被捕捉的,比如9号信号。因为如果所有信号都能被捕捉的话,那么进程就可以将所有信号全部进行捕捉并将动作设置为忽略,此时该进程将无法被杀死,即便是操作系统。
2.2.通过系统函数向进程发信号
当我们要使用kill命令向一个进程发送信号时,我们可以以kill -信号名 进程ID的形式进行发送。
也可以以kill -信号编号 进程ID
的形式进行发送。
kill函数
实际上kill命令是通过调用kill函数实现的,kill函数可以给指定的进程发送指定的信号,kill函数的函数原型如下:
int kill(pid_t pid, int sig);
kill函数用于向进程ID为pid的进程发送sig号信号,如果信号发送成功,则返回0,否则返回-1。
我们可以用kill函数模拟实现一个kill命令,实现逻辑如下:
#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <signal.h>
void Usage(char* proc)
{
printf("Usage: %s pid signo\n", proc);
}
int main(int argc, char* argv[])
{
if (argc != 3){
Usage(argv[0]);
return 1;
}
pid_t pid = atoi(argv[1]);
int signo = atoi(argv[2]);
kill(pid, signo);
return 0;
}
为了让生成的可执行程序在执行时不用带上路径,我们可以将当前路径导入环境变量PATH当中。
此时我们便模拟实现了一个kill命令,该命令的使用方式为mykill 进程ID 信号编号
。
raise函数
raise函数可以给当前进程发送指定信号,即自己给自己发送信号,raise函数的函数原型如下:
int raise(int sig);
raise函数用于给当前进程发送sig号信号,如果信号发送成功,则返回0,否则返回一个非零值。
例如,下列代码当中用raise函数每隔一秒向自己发送一个2号信号。
#include <stdio.h>
#include <unistd.h>
#include <signal.h>
void handler(int signo)
{
printf("get a signal:%d\n", signo);
}
int main()
{
signal(2, handler);
while (1){
sleep(1);
raise(2);
}
return 0;
}
运行结果就是该进程每隔一秒收到一个2号信号。
abort函数
raise函数可以给当前进程发送SIGABRT信号,使得当前进程异常终止,abort函数的函数原型如下:
void abort(void);
abort函数是一个无参数无返回值的函数。
例如,下列代码当中每隔一秒向当前进程发送一个SIGABRT信号。
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <signal.h>
void handler(int signo)
{
printf("get a signal:%d\n", signo);
}
int main()
{
signal(6, handler);
while (1){
sleep(1);
abort();
}
return 0;
}
与之前不同的是,虽然我们对SIGABRT信号进行了捕捉,并且在收到SIGABRT信号后执行了我们给出的自定义方法,但是当前进程依然是异常终止了。
说明一下: abort函数的作用是异常终止进程,exit函数的作用是正常终止进程,而abort本质是通过向当前进程发送SIGABRT信号而终止进程的,因此使用exit函数终止进程可能会失败,但使用abort函数终止进程总是成功的。
2.3.由软件条件产生信号
SIGPIPE信号
SIGPIPE信号实际上就是一种由软件条件产生的信号,当进程在使用管道进行通信时,读端进程将读端关闭,而写端进程还在一直向管道写入数据,那么此时写端进程就会收到SIGPIPE信号进而被操作系统终止。
例如,下面代码当中,创建匿名管道进行父子进程之间的通信,其中父进程是读端进程,子进程是写端进程,但是一开始通信父进程就将读端关闭了,那么此时子进程在向管道写入数据时就会收到SIGPIPE信号,进而被终止。
#include <stdio.h>
#include <unistd.h>
#include <string.h>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/wait.h>
int main()
{
int fd[2] = { 0 };
if (pipe(fd) < 0){ //使用pipe创建匿名管道
perror("pipe");
return 1;
}
pid_t id = fork(); //使用fork创建子进程
if (id == 0){
//child
close(fd[0]); //子进程关闭读端
//子进程向管道写入数据
const char* msg = "hello father, I am child...";
int count = 10;
while (count--){
write(fd[1], msg, strlen(msg));
sleep(1);
}
close(fd[1]); //子进程写入完毕,关闭文件
exit(0);
}
//father
close(fd[1]); //父进程关闭写端
close(fd[0]); //父进程直接关闭读端(导致子进程被操作系统杀掉)
int status = 0;
waitpid(id, &status, 0);
printf("child get signal:%d\n", status & 0x7F); //打印子进程收到的信号
return 0;
}
运行代码后,即可发现子进程在退出时收到的是13号信号,即SIGPIPE信号。
SIGALRM信号
调用alarm函数可以设定一个闹钟,也就是告诉操作系统在若干时间后发送SIGALRM信号给当前进程,alarm函数的函数原型如下:
unsigned int alarm(unsigned int seconds);
alarm函数的作用就是,让操作系统在seconds秒之后给当前进程发送SIGALRM信号,SIGALRM信号的默认处理动作是终止进程。
alarm函数的返回值:
- 若调用alarm函数前,进程已经设置了闹钟,则返回上一个闹钟时间的剩余时间,并且本次闹钟的设置会覆盖上一次闹钟的设置。
- 如果调用alarm函数前,进程没有设置闹钟,则返回值为0。
例如,我们可以用下面的代码,测试自己的云服务器一秒时间内可以将一个变量累加到多大。
#include <stdio.h>
#include <signal.h>
#include <unistd.h>
int main()
{
int count = 0;
alarm(1);
while (1){
count++;
printf("count: %d\n", count);
}
return 0;
}
运行代码后,可以发现我当前的云服务器在一秒内可以将一个变量累加到两万左右。
但实际上我当前的云服务器在一秒内可以执行的累加次数远大于两万,那为什么上述代码运行结果比实际结果要小呢?
主要原因有两个,
- 首先,由于我们每进行一次累加就进行了一次打印操作,而与外设之间的IO操作所需的时间要比累加操作的时间更长
- 其次,由于我当前使用的是云服务器,因此在累加操作后还需要将累加结果通过网络传输将服务器上的数据发送过来,因此最终显示的结果要比实际一秒内可累加的次数小得多。
为了尽可能避免上述问题,我们可以先让count变量一直执行累加操作,直到一秒后进程收到SIGALRM信号后再打印累加后的数据。
#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
#include <unistd.h>
int count = 0;
void handler(int signo)
{
printf("get a signal: %d\n", signo);
printf("count: %d\n", count);
exit(1);
}
int main()
{
signal(SIGALRM, handler);
alarm(1);
while (1){
count++;
}
return 0;
}
此时可以看到,count变量在一秒内被累加的次数变成了五亿多,由此也证明了,与计算机单纯的计算相比较,计算机与外设进行IO时的速度是非常慢的。
2.4.由硬件异常产生信号
为什么C/C++程序会崩溃?
当我们程序当中出现类似于除0、野指针、越界之类的错误时,为什么程序会崩溃?
本质上是因为进程在运行过程中收到了操作系统发来的信号进而被终止,那操作系统是如何识别到一个进程触发了某种问题的呢?
我们知道,CPU当中有一堆的寄存器,当我们需要对两个数进行算术运算时,我们是先将这两个操作数分别放到两个寄存器当中,然后进行算术运算并把结果写回寄存器当中。
此外,CPU当中还有一组寄存器叫做状态寄存器,它可以用来标记当前指令执行结果的各种状态信息,如有无进位、有无溢出等等。
而操作系统是软硬件资源的管理者,在程序运行过程中,若操作系统发现CPU内的某个状态标志位被置位,而这次置位就是因为出现了某种除0错误而导致的,那么此时操作系统就会马上识别到当前是哪个进程导致的该错误,并将所识别到的硬件错误包装成信号发送给目标进程,本质就是操作系统去直接找到这个进程的task_struct,并向该进程的位图中写入8信号,写入8号信号后这个进程就会在合适的时候被终止。
那对于下面的野指针问题,或者越界访问的问题时,操作系统又是如何识别到的呢?
运行结果:
首先我们必须知道的是,当我们要访问一个变量时,一定要先经过页表的映射,将虚拟地址转换成物理地址,然后才能进行相应的访问操作。
其中页表属于一种软件映射关系,而实际上在从虚拟地址到物理地址映射的时候还有一个硬件叫做MMU,它是一种负责处理CPU的内存访问请求的计算机硬件,因此映射工作不是由CPU做的,而是由MMU做的,但现在MMU已经集成到CPU当中了。
当需要进行虚拟地址到物理地址的映射时,我们先将页表的左侧的虚拟地址导给MMU,然后MMU会计算出对应的物理地址,我们再通过这个物理地址进行相应的访问。
而MMU既然是硬件单元,那么它当然也有相应的状态信息,当我们要访问不属于我们的虚拟地址时,MMU在进行虚拟地址到物理地址的转换时就会出现错误,然后将对应的错误写入到自己的状态信息当中,这时硬件上面的信息也会立马被操作系统识别到,进而将对应进程发送SIGSEGV信号。
总结一下:
C/C++程序会崩溃,是因为程序当中出现的各种错误最终一定会在硬件层面上有所表现,进而会被操作系统识别到,然后操作系统就会发送相应的信号将当前的进程终止。