🐱作者:一只大喵咪1201
🐱专栏:《Linux学习》
🔥格言:你只管努力,剩下的交给时间!
🔔信号
从生活中入手,例如发令枪,闹钟,红绿灯等等,这些都是信号。信号必须都是动态的,像路标就不能称之为信号。
以红绿灯为例,一看到红绿灯我们就知道红灯行,绿灯停,我们不仅能认识它是一个红绿灯,而且还知道应该产生什么样的行为,这样才算是能够识别红绿灯。
- 识别 = 认识 + 行为产生
对于红绿等这个信号,我们需要有如下几个共识:
- 我们之所以能识别红绿灯,是因为我们受到过教育(手段),让我们在大脑中记住了不同颜色对应的行为(属性)。
- 当绿灯亮了以后,不一定要立刻过马路,比如有其他的车闯红灯,需要进行避让,所以说我们不一定要立刻产生相应的行为。
- 红灯亮了以后,正好来了一个电话,在接电话这个期间我们会记住此时是红灯,不会将这个状态忘记。
- 红绿灯默认的行为是红灯行,绿灯停,但是也可以产生其他行为,还可以忽略。
现在将生活中红绿灯的例子迁移到进程中:
- 共识:信号是发给进程的。
- 进程之所以能够识别信号,是因为程序员将对应的信号种类和逻辑已经写好了的。
- 当信号发给进程后,进程不一定要立刻去处理,可能有更加紧急的任务,会在合适的时候去处理。
- 进程收到信号到处理信号之前会有一个窗口期,这个期间要将收到的信号进行保存。
- 处理信号的方式有三种:默认动作,自定义动作,忽略。
我们学习信号是学习它的整个生命周期,按照时间轴,分为信号产生,信号保存,信号处理。但是在这之前先需要学习一些预备知识。
🎵预备知识
进程能够识别的信号是已经写好的,它有62个:
- 红色框中的是普通信号,编号从1-31。
- 绿色框中的是实时信号,编号从34-64。
这其中没有32号和33号信号,所以一共有62个信号。而且这里我们只学习普通信号,对实时信号暂不做研究。
- 在使用这些信号时,可以用信号名,也可以用信号编号,它是一样的,都是宏定义后的结果。
根据我们对Linux的了解,信号存放在哪里呢?既然信号是给进程的,而进程是通过内核数据结构来管理的,所以我们可以推断出,信号放在进程的task_struct结构体中。
既然它是在PCB中,而且数量是31个,task_struct中必定不会设置31个变量来存放信号,数组还有可能,但是信号的状态只分为有和没有两种,所以再次推断,31个信号放在一个32位的整形变量中,每个比特位代表一个信号。
本喵写一段伪代码来示意一下:
struct task_struct
{
//进程属性
unsigned int signal;
//.......
}
就像在学习基础IO和进程间通信的时候,那些flags标志中的不同的比特位代表着不同的意义,这31个信号量也是这种方式:
具体的保存细节后面本喵再详细讲解。
问题来了,内核数据结构的修改,这个工作是由谁来完成的?毫无疑问是操作系统,因为task_struct就是它维护的,而且是存在于内存中的,只有操作系统才有权力去修改它,用户是无法直接操作的,因为操作系统不相信任何人。
所以说,无论哪个信号,最后的本质都是由操作系统发生给进程的,这里的发送本质就是在修改task_struct中存放信号那个变量的比特位。
- 信号发送的本质就是在修改PCB中的信号位图。
无论未来我们学习了多少中发送信号的方式,本质都是通过操作系统向目标进程发送信号。
所以操作系统一定会提供相关的系统调用,比如我们之前使用过的各自信号:
kill -9 pid值 //停止某个进程
kill -19 pid值 //暂停某个进程
kill -18 pid值 //继续某个进程
它们的底层一定是在调用相关的系统调用,来让操作系统修改PCB中的信号位图。
🎵信号处理方法的注册
- 所谓的注册,就是告诉操作系统,当某个进程接收到某个信号后的处理方式。
既然是告诉操作系统,那么肯定会用到系统调用,该系统调用的名字是signal():
- int signal:要注册的信号编号
- sighandler_t handler:自定义的函数指针
可以将信号的处理方式写成一个函数,然后将函数名传递个signal,此时当进程接收到signum指定的信号编号时,就会执行我们定义的函数。
void handler(int signo)
{
cout<<"进程接收到的一个信号,编号:"<<signo<<endl;
}
函数的返回类型必须是void类型,形参必须是signo类型,名字可以随意。
补充:
我们之前,在shell的命令行中,会按crtl + c 来结束正在运行的进程。这种键我们称为热键。
ctrl + c本质是上一个组合键,操作系统识别到这种组合键后,会将它解释为2号信号SIGINT。
现在将我们自己写的函数注册为2号信号的处理方式。
运行起来后发现,按上ctrl+c后,进程不会结束了。
- 2号信号SIGINT的默认处理方式就是结束进程。
- 我们自定义的处理方式中并没有结束进程,所以进程在收到2号进程后打印了一句话。
- 所有信号的默认处理方式都是结束进程,只是不同的信号代表的意义不一样。
小实验:
我们将31个信号都自定义处理方式,并且不退出进程,那么这个进程是不是就无法退出了?
此时31个信号的自定义处理方式中都没有进程退出。
可以看到,给这个进程这么多信号,都没有结束,而且自定义处理方式也执行了,打印出了接收到的信号编号,但是进程还是在执行。
那这样是不是意味着这个进程无法结束了?不是的,操作系统就防着你呢,不会让这种恶意的东西存在的。
- 9号信号SIGKILL是不能够自定义处理方式的,所以该信号能够将这个进程结束掉。
kill -9 pid值//杀死指定进程
该指令可以结束任何进程,这就是操作系统留的后手。
🔔信号的产生
有了上面的预备知识以后,就可以正式来研究信号了。
🎵通过终端按键产生信号
也就是在键盘上按一些热键,来给进程发送相应的信号,ctrl+c在上面本喵就讲解过了,它产生的是2号信号SIGINT。
还有常用按键ctrl+\,它产生的是3号信号SIGQUIT。
可以看到通过键盘产生了2号和3号信号。
🎵调用系统调用向进程发信号
系统调用kill():
- pid_t pid:要给发信号的pid
- int sig:要发送的信号编号
- 返回值:发送成功返回0,失败返回-1
该系统调用是一个进程给另一个进程发送指定信号,可以向任意进程发送任意信号。
信号接收端:
这是一个一直在运行的程序,用来接收从其他进程发送过来的信号。
信号发送端:
这是一个带有命令行参数的程序,输入的选项中的pid值和信号编号,在程序中在调用kill系统调用向指定pid的进程发送指定信号。
效果:
左边在执行mysginal的时候,输入对应的信号编号和pid,右边正在运行的进程就会接收到指定的信号而停止运行。
系统调用raise():
- int sig:要发送的信号
- 返回值:发送成功返回0,失败返回-1
该系统调用是由进程自己调用,也就是进程自己可以给自己发送任意信号。
通过命令行参数指定信号,在程序执行5秒钟后给自己发送该信号。
无论命令行输入哪个信号的编号,在5秒钟后,该进程都会给自己发送输入的信号,让进程结束。
系统调用abort():
- 没有参数,没有返回值
该系统调用只能给自己发送指定的信号,该信号是SIGABRT,信号编号是6。
5秒钟后给自己发送SIGABRT信号。
在运行5秒钟后,该进程接收到了6号信号SIGABRT。
虽然有3个系统调用来产生信号,但是归根到底都是在使用kill系统调用。
- kill()可以给任意进程发送任意信号。
- raise()可以给自己发送任意信号。
//raise本质
kill(getpid(),signo);
- abort()可以给自己发送SIGABRT信号。
//abort本质
kill(getpid(),SIGABRT);
🎵硬件异常产生信号
除0操作导致的硬件异常:
在这段代码中,有除0操作,我们知道,除0得到的是无穷大的数,所以在编程的时候是不允许出现的。
- 在运行的时候,直接出错,没有再执行下去,是因为接收到了信号。
- 接收到的信号是SIGFPE信号,编号为8号。
这其实就是一种硬件异常产生的信号。
- CPU中有很多的寄存器,例如eax,ebx,eip等等。
CPU会从内存中将代码中的变量拿到寄存器中进行运算,如果有必要,还会将运算的结果放回到内存中。
- 还有一个状态寄存器,如果CPU在运算的时候发现了除0操作,就会将状态寄存器的溢出标志位置一。
此时就意味着硬件产生了异常。而操作系统是一个进行软硬件资源管理的软件,CPU的中状态寄存器的溢出标志位置一后,操作系统可以第一时间拿到。
- 除0导致硬件异常以后,操作系统会给对应的进程发送SIGFPE信号。
当进程接收到SIGFPE信号以后,默认的处理方式就是结束进程。
现在我们对这个SIGFPE信号注册一个自定义处理方式:
只打印接收到的信号编号,进程不退出。
在进程运行起来后,怎么就开始鞭尸了呢?也就是这个信号被操作系统不停的发送给这个进程。
- 进程收到信号后进程不退出,随着CPU时间片的轮转就会再次被调到。
- CPU中只有一份寄存器,但是寄存器中的内容属于当前进程的上下文。
- 当进程被切换的时候,就有无数次的状态寄存器被保存和恢复的过程。
- 而除0操作导致的溢出标志位置一的数据还会被恢复到CPU中。
- 所以每一次恢复的时候,操作系统就会识别到,并且给对应进程发送SIGFPE信号。
所以就会导致上面不停调用自定义处理函数,不停打印接收到的信号编号。
解引用空指针导致的硬件异常:
上面代码中存在对空指针的解引用操作,空指针的本质是(void*)0,而0地址处是不允许我们用户进行访问的,这部分属于内核空间。
- 运行的时候直接出错,没有再运行下去,也是因为接收到了信号。
- 接收到的信号是SIGSEGV,编号是11。
这同样是一种硬件异常产生的信号。
- 我们之前一直谈论的页表时间上是页表+MMU,而MMU是在CPU中的,未来简便,我们就只说页表。
- 进程地址空间和物理内存之间的映射关系实际上是有MMU去完成映射的。
- 当对空指针解引用的时候,MMU会拒绝这种操作,从而产生异常标志。
- 操作系统拿到MMU产生的异常以后就会给对应的进程发送SIGSEGV信号。
当进程接收到编号为11的SIGSEGV信号以后,默认的处理动作就是结束进程。
将这个信号注册自定义处理方式,同样打印接收到的信号编号,但是不结束进程,可以看到,和除0操作一样,也是在鞭尸,不停的打印。
- 硬件异常所产生的信号,如果不结束这个进程,我们是没有能力去处理这个进程的。
- 随着时间片的轮转,这个导致硬件异常的进程还会不停的调到,所以操作系统会不停的向进程发送信号。
- 硬件异常产生的信号并不会显示发送,而是由操作系统自动发送的。
🎵由软件条件产生信号
读端关闭触发的信号:
比如在学习匿名管道的时候,当读端关闭的时候,写端所在进程就会收到编号为13的SIGPIPE信号结束进程。
读端5秒钟之后关闭,写端进程注册自定义处理方式,打印写端接收到的信号编号,但是不结束进程。
在读端关闭以后,写端的自定义处理方式中就接收到了系统发给的SIGPIPE信号,编号为13。
- 读端是否关闭是软件中的条件。
- 当条件达成以后,产生信号。
闹钟触发的信号:
闹钟就是系统中的定时器,使用的时候同样需要通过系统调用实现:
- 参数:要定的时长。
- 返回值:距离定的时间还差多少。
定时1秒钟,在循环中进行疯狂加1,设置自定义处理方式,打印定时到后收到的信号编号,并且统计这一秒中内进行了多少次加1操作。
当定时1秒钟时间到了以后,自定义处理方式中打印出接收到的信号编号是14号的SIGALRM信号,并且统计出了1秒钟进行加1操作的次数。
- 自定义处理方式中没有退出进程,所以在执行完处理方式以后,进程继续运行。
- 也就是继续进行加1操作,但是不会再收到信号了,因为定时到的条件只达成一次,所以信号也只产生一次。
如果想每隔一秒条件达成一次,产生一次SIGALRM信号,可以在这样处理:
- 在自定义处理方式中定时1s。
- 当1秒定时条件达成以后,产生信号,执行处理方法后会开始新一轮的定时。
- 软件中某个条件达成以后,操作系统就会产生相应的信号,比如上面的SIGPIPE信号和SIGALRM信号。
闹钟的管理:
操作系统中会有很多个进程,我们可以创建一个闹钟,那么其他进程也可以创建闹钟,这样就会存在很多个闹钟,那么这些闹钟是怎么管理的呢?先描述再组织。
首先需要创建一个闹钟的结构体,伪代码:
struct alarm
{
unit64_t when;//定时时长
int type;//闹钟类型,一次性还是周期性
task_struct* p;//所属进程的地址
struct_alarm* next;//下一个闹钟的地址
//其他属性
}
大概就是这样的一个结构体来描述闹钟,必须由的肯定是定时时长,所属进程。
接下来就是组织了,用某一种数据结构来管理这些闹钟对象,为了方便管理,可以选择优先级队列prority_queuq来管理。
- 将定时时间最小的闹钟放在前面,时间长的放在后面。
- 操作系统每次只需要检测队首的定时时间是否达到就可以。
- 达到了就向对应进程发送SIGALRM信号,并且从队列中取出,以待再次检测。
操作系统会周期性的检测链表中的这些闹钟,伪代码:
curr_timestamp > alarm.when;//超时了
//OS发送SIGALRM信号到alarm.p;
具体的实现细节有兴趣的小伙伴可以看看源码是怎么管理的,这里本喵只是介绍一种思想。
🔔核心转储
是否有一个疑问,31个信号的默认处理方式都是结束进程,并且还可以自定义处理方式,那么为什么要这么多信号呢?一个信号不就行了吗?
- 重要的不是产生信号的结果,而是产生信号的原因。
- 所有出现异常的进程,必然是收到了某一个信号。
在man的7号手册中介绍了信号的名称,对应的编号,默认处理方式,以及产生该信号的原因。
- 我们可以根据这个表找到不同信号产生所对应的不同原因。
以信号2和3为例,他两的默认处理方式一个是Term,一个是Core。
- Term和Core的结果都是结束进程。
那么这两个方式的区别在哪里呢?
- Term方式仅仅是结束进程,结束了以后就什么都不干了。
- 但是Core不仅结束进程,而且还会保存一些信息。
在数据越界非常严重的时候,该进程会接收到SIGSEGV信号,来结束进程。
- 11号信号的默认处理方式是Core。
在云服务器上,默认情况下是看不到Core退出的现象的,这是因为云服务器关闭了core file选项:
- core file size(红色框)的大小是0,意味着这个选项是关闭的。
- 从这里还可以看到别的关于这个云服务器的信息,比如能够打开的最多文件个数,管道个数,以及栈的大小等等信息。
为了能够看到Core方式的明显现象,我们需要将core file选项打开:
此时该选项就打开了,表示的意思就是核心转储文件的大小是1024个数据块。
- 再运行数据越界的程序时,同样会收到SIGSEGV信号停止。
- 但是在当前目录下会多出一个文件,如上图中的绿色框。
- core.1739:被叫做核心转储文件,其中后缀1739是接收到该信号进程的pid值。
对于一个奔溃的程序,我们最关心的是它为什么崩溃,在哪里崩溃?
- 当进程出现异常的时候,将进程在对应的时刻,在内存中的有效数据转储到磁盘中-------核心转储。
- 核心转储的文件我们可以拿着它进行调试,快速定位到出现异常而崩溃的位置。
- 使用gdb调试我们的可执行程序。
- 调试开始后,输入core-file core.pid值,表明调试核心转储文件。
- 此时gdb就会直接定位到产生异常的位置。
这就是核心转储的重要意义,它相比Term方式,能够让我们快速定位出现异常的位置。文章来源:https://www.toymoban.com/news/detail-410854.html
篇幅有限,下篇文章再接着介绍。文章来源地址https://www.toymoban.com/news/detail-410854.html
到了这里,关于【Linux学习】信号——预备知识 | 信号产生 | 核心转储的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!