前面已经介绍过信号的产生,本文将继续介绍信号的保存与处理。
1、上篇文章的遗留问题
从上篇文章(Linux学习之路 -- 信号概念 && 信号的产生-CSDN博客)中,其实还遗留了一些问题。OS在接受到信号后,大部分的进程的处理方式都是终止进程。但是终止进程的方式有Term和Code两种方式。那么两种进程退出的方式有何区别呢?
Term就表示正常的退出,而code退出会产生核心转储文件。在云服务器中,使用code退出时,默认是将code产生核心转储文件的功能关闭的。而我们如果想要查看该功能是否被打开。我们就可以使用"ulimit -a"选项,对该功能进行查看。
其中的第一项"core file size" 就表示code功能是否被打开。core file size其实也就是表示核心转储文件的大小,如果为零,也就表示没有。我们要恢复该功能,只要将其设置一定大小的正整数即可(单位为KB)。我们可以使用"ulimit -c + 指定大小的整数",如果不想该文件的大小收到限制,就把前面这条命令中的整数改为unlimited即可。
核心转储文件的作用:如果进程运行出现异常时,系统就会将进程在内存中的数据(主要与调试有关)转到磁盘中,形成core、core.pid文件。
该文件主要用于帮助我们进行调试,当我们使用gdb时,能够直接定位到对应出错的行号与文件。我们在打开gdb时,直接输入core-file + core(这里是核心转储的文件名,如果有后缀pid,记得加上)即可。
core dumped 表示形成核心转储文件,这个和前面我们讲述的进程退出时的知识有些许关联。
进程退出时,会返回一个整型。OS以后16个字节对进程的退出状态进行标识。中间其实缺少了一个比特没有介绍,这个比特位就是core dumped标志,用于标识是否形成核心转储文件。
但是核心转储文件虽然能帮我们定位程序出错的位置,但在实际的云服务器上,我们的服务是需要不断运行的。有时候恢复正常服务,需要很长的时间。在此期间,有可能OS会一直输出core文件,导致服务器磁盘被打满,这就会导致服务器也直接挂掉。所以,正常情况下,这个core dump功能是会被默认关闭的。
2、信号的保存
在正式介绍信号保存之前,我们需要把前面的概念修正一下。
<1>实际执行信号的处理动作称为信号递达。(默认、忽略、自定义)
<2>信号从产生到递达之间的状态称为信号未决。(存储信号)
<3>进程是可以阻塞信号的。
1、基本流程
前面我们提到,当OS向进程发送信号,实际上是在向进程写入信号。而进程可能在处理其他事务,所以会使用一个位图来对信号进行保存。在struct task_struct 中就是以一个无符号整型变量对信号进行保存。同理,信号可以被进程阻塞,这个阻塞也是需要先存储信号,而OS也是使用了位图的方式,对其进行保存。当进程接受到信号时,会先保存信号。然后,在需要执行信号的默认处理方式前,判断信号是否被阻塞,如果是,就不处理该信号;不是就执行默认方法。(如果该信号被一直阻塞,那就一直不执行)
除了上述的两张位图,还有一个数组与进程处理信号相关。
这个数组是一个函数指针数组,里面存储了一些对应信号的默认处理方法。当OS接收到信号时,先将信号写进pending位图中,然后判断是否被阻塞。如果没有被阻塞,就找到对应的handler方法,处理信号,该数组的下标就代表了对应的信号。这里可以联想到signal接口处理信号的方式,当我们设定位自定义处理信号时,将该信号在handler_t中对应的默认处理方法替换成自定义函数地址。
2、三张表对应的系统接口和相关操作
1、五个常用的信号集函数
在OS中,我们查看pending位图和block位图,是不会直接传整型的,而是将存储的结构封装成了一个结构体,所以我们在上述的五个接口中均可以看见sigset_t类型的参数。下面一一解释一下对应接口的作用。
<1>sigemptyset
该接口用于将位图初始化为零,一般我们需要自己定义一个sigset_t变量,把这个变量用于存储系统中对应位图信息。而这个变量定义时不初始化,所以可能会出现随机数现象,该接口就是用于将变量中的数据全部清零。
<2>sigfillset
该接口用于将所有定义的信号,设进set这个参数信号集中。
<3>sigaddset
该接口用于将signum信号添加进set这个信号集。
<4>sigdelset
该接口用于将signum信号从set信号集中删除。
<5>sigismember
该接口用于判断信号signum是否在set这个信号集中。
前四个接口调用成功返回零,失败返回-1。最后一个接口成功返回true,失败返回false。
2、sigprocmask
该接口可以读取或更改系统中对应的信号屏蔽集(block位图).
第一个参数表示所要对信号屏蔽集做的动作,第二个参数表示新的信号屏蔽字,第三个参数表示原来的信号屏蔽集。
第一个参数一般常用的有三个选择:SIG_BLOCK 、SIG_UNBLOCK、SIG_SETMASK。第一个选项表示将set这个信号集中的屏蔽的信号添加进现有的信号屏蔽集中;第二个选项表示将set这个信号集中屏蔽的信号从原有的信号删除;第三个选项表示将set这个信号集直接替换当前的信号屏蔽集。
调用成功返回0,失败返回-1。
3、sigpending
该接口用于读取系统中的pending信号集(pending位图)。成功返回0,失败返回-1。
4、示例:
我们以下面的场景为例,演示一下上述的相关的接口的使用方式。
场景:我们当前将2号信号阻塞,然后不断向当前进程发送2号信号,观察pending表是否一直都保存着2号信号。(pending表中一般就一个信号,当收到新的不同的信号时,原有的信号会被消除)
#include <iostream>
#include <unistd.h>
#include <signal.h>
void Print(sigset_t &pe)
{
std::cout << "pending map: ";
for (int i = 31; i >= 1; i--)
{
if (sigismember(&pe, i))
{
std::cout << "1";
}
else
{
std::cout << "0";
}
}
std::cout << std::endl;
}
int main()
{
sigset_t block, oblock;
sigemptyset(&block);
sigemptyset(&oblock);
sigaddset(&block, 2);
int n = sigprocmask(SIG_BLOCK, &block, &oblock);
if (n == 0)
{
while (true)
{
sigset_t pending;
sigemptyset(&pending);
sigpending(&pending);
sleep(1);
Print(pending);
}
}
return 0;
}
运行结果:
我们可以看见,当我们将2号信号阻塞时,pending中的2号信号一直没有被处理。需要说明的是,我们不能直接打印pending表,OS是以sigset_t的类型对信号进行存储,里面可能包含有别的数据,所以直接打印是错误的。在代码中,需要使用sigismember来判断信号是否存储。
上面的示例,我们屏蔽了2号信号,那我们能不能屏蔽1到31号信号呢?如果不能,那么哪些信号不会被屏蔽呢?下面通过代码对该问题进行验证。
#include <iostream>
#include <unistd.h>
#include <signal.h>
void Print(sigset_t &pe)
{
std::cout << "pending map: ";
for (int i = 31; i >= 1; i--)
{
if (sigismember(&pe, i))
{
std::cout << "1";
}
else
{
std::cout << "0";
}
}
std::cout << std::endl;
}
int main()
{
sigset_t block, oblock;
sigemptyset(&block);
sigemptyset(&oblock);
for(int i = 1; i < 32; i++)
{
sigaddset(&block, i);
}
sigaddset(&block, 2);
int n = sigprocmask(SIG_BLOCK, &block, &oblock);
if (n == 0)
{
while (true)
{
sigset_t pending;
sigemptyset(&pending);
sigpending(&pending);
sleep(1);
Print(pending);
}
}
return 0;
}
运行结果
运行至九号信号时,进程结束。说明九号进程不可被屏蔽。后面的信号就不做实验了,在这31个信号中,还有19号信号也不可被屏蔽,其中我们将18号信号屏蔽时,附近的几个信号会在信号屏蔽集中被剔除。这两个信号被禁止屏蔽其实也就是为了防止异常进程不断运行,影响OS的正常运转或阻止异常进程读取核心数据。
通过上述的接口,我们可以实现信号的屏蔽,也可以实现信号屏蔽的解除。这里就不做演示了,但需要注意的是,一旦信号的屏蔽被解除后,pending中的信号是先被清零,再被递达。