💬 hello! 各位铁子们大家好哇。 今日更新了Linux信号的内容 🎉 欢迎大家关注🔍点赞👍收藏⭐️留言📝
二者之间没有任何关系。
通过 kill -l 可以查看所有信号 其中,1-31号信号是普通信号。34以上的信号为实时信号。 这些信号各自在什么条件下产生,默认的处理动作是什么,在signal(7)中都有详细说明: man 7 signal
基本结论: 信号:Linux系统提供的一种,向指定进程发送特定事件的方式。 信号的产生和进程是异步的。即进程不知道什么时候会收到信号。 信号可以随时产生。 如果进程做着别的事,可以暂不处理信号,等到合适的时候再处理。
信号处理有三种情况:
运行上面代码,在另一个终端上输入kill -2 指令,数字也可换成对应的宏名称。发现输出了hander函数的内容。
signal是用来进行信号捕捉的。参数1是信号的编号,参数2是函数指针。如果进程收到参数1对应的信号,就会执行参数2对应的方法。 可以对多个信号进行捕捉,
由上图,2号信号的默认动作是终止进程。上面没有对2号信号(SIGINT)进行捕捉,就会执行2号信号的默认动作。
我们对2号信号进行捕捉。然后按ctrl+c。发现执行了hander函数。所以实际上,在命令行上按ctrl+c就是给进程发送2号信号。 在命令行上按ctrl+\就是发送3号信号。他们都是用来终止进程的。
信号的保存和发送理解: 进程pcb中,是用位图来保存信号的。收到什么信号,就把对应比特位上的数字变为1。 发送信号:修改指定进程pcb中的信号的指定位图的比特位。
信号的产生方式:
参数1是指定进程,参数2是指定信号。作用是向指定进程发送指定信号。
如上图,一个循环打印,另一个用kill函数。运行结果如下图,使用kill函数终止了进程。
作用:谁调用这个函数,它就给调用者发送指定信号。 kill是给任意进程发送任意信号。如果想给自己发送信号,相当于kill(getpid(),sig)==raise(sig)
上面是用raise来给自己发送信号的例子。 raise不重要,kill重要。
运行上面代码,两秒后进程就终止了。
abort相当于6号信号。作用是给自己发送6号信号(SIGABRT),终止进程。
运行代码,发现打印了一次后就终止了,不会因为自定义捕捉而一直打印下去。所以它是一个例外。 如果我们把所有信号都捕捉了,是不是就无法关闭进程了? 其实不会,上面的例子就是证明,实际上,还有别的信号可以关闭进程,如9号信号。9号信号不允许自定义捕捉。
上面讲的都是信号产生的方式,都是通过用户完成的。但是真正发送信号的只有一个人:系统。 因为发送信号的本质是修改进程pcb中的信号位图,只有OS才有资格修改。
SIGPIPE是一种由软件条件产生的信号。下面介绍alarm函数和SIGALRM信号。
调用alarm函数可以设定一个闹钟,也就是告诉内核在seconds秒之后给当前进程发SIGALRM信号, 该信号的默认处理动 作是终止当前进程。
运行结果如下图:
我们修改代码成如下:
我们让循环单纯++,不再打印,直到闹钟响了再打印。结果发现cnt的值比前面大了很多。这是因为IO很慢。
alarm(0)表示0秒后超时,也就是时间是当前时间。所以alarm(0)表示取消闹钟。alarm返回值是上一个闹钟的剩余时间。
如上图,表示4秒后取消前一个10秒的闹钟,设置一个2秒的新闹钟。
由上图结果可得,闹钟设置一次,默认就触发一次。
我们在hander里面也设置闹钟,相当于每次闹钟响了,就再设置一个闹钟,这样就有了一个常设性的闹钟了。
运行上面代码都会崩溃,一个是除以0,一个是野指针。 一个报浮点数错误,另一个报段错误。崩溃了会退出,默认是终止进程。 之所以崩溃,是因为非法访问、操作,导致OS向进程发送信号了。 除以0,会发送8号信号(SIGFPE)。野指针会发送11号(SIGSEGV)。
如上图,我们将8号信号捕捉,运行代码后发现,会死循环一直打印 。
再将注释互换,如下图,结果也是死循环打印。
所以程序崩溃了可以不退出,通过捕获异常即可。但是推荐终止进程。 寄存器只有一套,但是寄存器里的数据是属于每一个进程的---硬件的上下文保存和恢复。 如果我们捕获异常,不让进程退出,进程就要调度,进程要调度就得切换。进程要切换,就会把cpu里的寄存器值作保存和恢复。这意味着每次保存进程,就会把异常保存起来,因为进程不退,又会把异常恢复。所以OS就会一直触发错误,就会一直循环打印了。 因此推荐终止进程,本质是为了释放进程的上下文数据。
Core、Term都是终止进程的意思,那他们有啥区别呢? Term:异常终止 Core:异常终止,但是它会帮我们形成一个类似debug文件。
运行上面代码,结果报错了。也并没有形成类似的debug文件。因为该功能默认是关闭的。 如何查看呢?指令 ulimit -a 可以查看系统中对于普通用户能使用资源对应的限制。下面可以看到core file size 大小是0,所以云服务器默认不允许我们形成core文件。
通过ulimit -c 数字 指令,这样core file选项就打开了。此时再运行程序,就有core文件了。
Core文件就是进程退出时候的镜像数据,这个功能叫核心转储。 核心转储其实是进程异常时,核心数据转而存储到磁盘上。
所以上面图中,core dump标志位为0时表示没有核心转储,为1表示有核心转储。 如果进程是Term就没有核心转储。如果是Core并且打开了核心转储功能,就有核心转储。
我们把Makefile文件里g++带上-g选项,允许被调试。
当程序里面有除0错误时,并且有了core文件。我们gdb进行调试。 输入 core-file core 给gdb加载core文件,我们就可以直接定位到程序出错的地方。
所以core是协助我们进行debug的文件,这种操作也叫事后调试。
运行代码,结果core dump是0。8号信号的终止动作是core,为什么这里结果是0?因为core功能默认是关闭的,我们没打开。打开功能后结果就是1了。
信号在内核中的表示示意图
每个进程pcb中会维护三张表。
pending表就是未决表,它是一张位图。有32个比特位,使用其中31位。 假设最左边一位不用,从右往左数,第几个比特位就代表第几个信号。为1就是处于未决状态,为0则不处于。
handler表就是函数指针数组。handler表里面写的就是该信号如何被处理,信号的编号就是数组的下标。 因此我们之前的signal函数调用,如signal(2,handler)就表示用2号编号在handler数组里索引,把自己写的handler函数地址传进handler表里,这样系统就知道你要怎么处理对应信号了。
block表也是一张位图,和pending表类型一样,也只使用其中31位。
这三张表要横着,对应着编号看。 因此,两张位图+一张函数指针数组就可以让进程识别信号。
每个信号只有一个bit的未决标志,非0即1,不记录该信号产生了多少次,阻塞标志也是这样表示的。 因此,未决和阻塞标志可以用相同的数据类型sigset_t来存储,sigset_t称为信号集,这个类型可以表示每个信号的“有效”或“无效”状态,在阻塞信号集中“有效”和“无效”的含义是该信号是否被阻塞,而在未决信号集中“有效”和“无效”的含义是该信号是否处于未决状态。 阻塞信号集也叫做当前进程的信号屏蔽字(Signal Mask),这里的“屏蔽”应该理解为阻塞而不是忽略。 sigset_t就是Linux给用户提供的一个用户级的数据类型,禁止用户直接修改位图。
sigset_t类型内部如何存储这些bit依赖于系统实现,从使用者的角度是不必关心的,使用者只能调用以下函数来操作sigset_ t变量
这四个函数都是成功返回0,出错返回-1。 sigismember是一个布尔函数,用于判断一个信号集的有效信号中是否包含某种信号,若包含则返回1,不包含则返回0,出错返回-1。 注意,在使用sigset_ t类型的变量之前,一定要调用sigemptyset或sigfillset做初始化,使信号集处于确定的状态。初始化sigset_t变量之后就可以在调用sigaddset和sigdelset在该信号集中添加或删除某种有效信号。
调用函数sigprocmask可以读取或更改进程的信号屏蔽字(阻塞信号集)。 返回值:若成功则为0,若出错则为-1 set是输入型参数,oldset是输出型参数。 如果oldset是非空指针,则读取进程的当前信号屏蔽字通过oldset参数传出。如果set是非空指针,则更改进程的信号屏蔽字,参数how指示如何更改。如果oldset和set都是非空指针,则先将原来的信号屏蔽字备份到oldset里,然后根据set和how参数更改信号屏蔽字。假设当前的信号屏蔽字为mask,下表说明了how参数的可选值。
sigpending的作用是获取当前进程的pending位图,它的参数是输出型参数。 调用成功则返回0,出错则返回-1。
运行上面代码,发送2号信号后,因为此时2号信号已经被屏蔽了,所以pending位图里2号信号对应位置就由0置1了。 解除信号屏蔽,一般会立即处理当前被解除的信号(如果被pending) pending位图对应的信号也要清0,在信号递达之前。
完整代码
#include <iostream>
#include <unistd.h>
#include <cstdio>
#include <sys/types.h>
#include <sys/wait.h>
void PrintPending(sigset_t &pending)
{
std::cout << "curr process[" << getpid() << "]pending: ";
for (int signo = 31; signo >= 1; signo--)
{
if (sigismember(&pending, signo))
{
std::cout << 1;
}
else
{
std::cout << 0;
}
}
std::cout << "\n";
}
void handler(int signo)
{
std::cout << signo << " 号信号被递达!!!" << std::endl;
std::cout << "-------------------------------" << std::endl;
sigset_t pending;
sigpending(&pending);
PrintPending(pending);
std::cout << "-------------------------------" << std::endl;
}
int main()
{
// 0. 捕捉2号信号
signal(2, handler); // 自定义捕捉
signal(2, SIG_IGN); // 忽略一个信号
signal(2, SIG_DFL); // 信号的默认处理动作
// 1. 屏蔽2号信号
sigset_t block_set, old_set;
sigemptyset(&block_set);
sigemptyset(&old_set);
sigaddset(&block_set, SIGINT);
// 1.1 设置进入进程的Block表中
sigprocmask(SIG_BLOCK, &block_set, &old_set); // 真正的修改当前进行的内核block表,完成了对2号信号的屏蔽!
int cnt = 15;
while (true)
{
// 2. 获取当前进程的pending信号集
sigset_t pending;
sigpending(&pending);
// 3. 打印pending信号集
PrintPending(pending);
cnt--;
// 4. 解除对2号信号的屏蔽
if (cnt == 0)
{
std::cout << "解除对2号信号的屏蔽!!!" << std::endl;
sigprocmask(SIG_SETMASK, &old_set, &block_set);
}
sleep(1);
}
}
如果一个信号不做任何处理,它默认就是SIG_DFL选项。 SIG_IGN选项就是忽略一个信号。
如果信号的处理动作是用户自定义函数,在信号递达时就调用这个函数,这称为捕捉信号。由于信号处理函数的代码是在用户空间的,处理过程比较复杂,举例如下: 用户程序注册了SIGQUIT信号的处理函数sighandler。 当前正在执行 main函数,这时发生中断或异常切换到内核态。 在中断处理完毕后要返回用户态的main函数之前检查到有信号 SIGQUIT递达。 内核决定返回用户态后不是恢复main函数的上下文继续执行,而是执行sighandler函 数,sighandler和main函数使用不同的堆栈空间,它们之间不存在调用和被调用的关系,是两个独立的控制流程。 sighandler函数返回后自动执行特殊的系统调用sigreturn再次进入内核态。 如果没有新的信号要递达,这次再返回用户态就是恢复main函数的上下文继续执行了。 信号捕捉的过程:要经历4次状态的切换。 在内核态切换回用户态的时候,进行信号的检测和处理。
再谈地址空间
开机时,操作系统是最先加载的软件,所以OS也要在内存中。内核级页表是将内核地址空间和OS之间进行映射的。因此OS本身就在我的进程地址空间中。 如果有多个进程,不会再创建一个新的内核级页表,而是共用一张。
sigaction函数可以读取和修改与指定信号相关联的处理动作。调用成功则返回0,出错则返回- 1。signum 是指定信号的编号。act是输入型参数,是结构体类型,结构如上图,这里只了解结构体里的第一行,即函数指针。所以act传的是函数指针。oldact是输出型参数,用来保存旧的结构体。 sigaction本质就是修改信号的handler表。 sigaction跟前面的signal本质作用是一样的,都是对特定信号进行捕捉。
运行后,ctrl+c发送2号信号,发现2号信号被捕捉了,执行了handler函数。
我们把上面的handler函数修改一下,添加sleep。
运行后一直按ctrl+c,发现只执行了一次handler函数。因为当某个信号的处理函数被调用时,内核自动将当前信号加入进程的信号屏蔽字,当信号处理函数返回时自动恢复原来 的信号屏蔽字。这样就保证了在处理某个信号时,如果这种信号再次产生,那么 它会被阻塞到当前处理结束为止。
#include<iostream>
#include<signal.h>
#include<unistd.h>
void Print(sigset_t &pending)
{
for(int sig = 31; sig > 0; sig--)
{
if(sigismember(&pending, sig))
{
std::cout << 1;
}
else
{
std::cout << 0;
}
}
std::cout << std::endl;
}
void handler(int signum)
{
std::cout << "get a sig: " << signum << std::endl;
while(true)
{
sigset_t pending;
sigpending(&pending);
Print(pending);
sleep(1);
// sleep(30);
// break;
}
// exit(1);
}
int main()
{
struct sigaction act, oact;
act.sa_handler = handler;
sigemptyset(&act.sa_mask); // 如果你想在处理2号时(OS对2号自动屏蔽),同时对其他信号也进行屏蔽
sigaddset(&act.sa_mask,3);
act.sa_flags = 0;
sigaction(2, &act, &oact);
while(true)
{
std::cout << "I am a process, pid: " << getpid() << std::endl;
sleep(1);
}
return 0;
}
除了当前信号被自动屏蔽之外,还希望自动屏蔽另外一些信号,则用sa_mask字段说明这些需 要额外屏蔽的信号,当信号处理函数返回时自动恢复原来的信号屏蔽字。代码如上,通过sa_mask字段屏蔽了3号信号。
如果一个函数符合以下条件之一则是不可重入的:
运行上面代码,按下ctrl+c后,信号被捕捉,gflag就被修改了,while循环条件为假,程序就结束了。
Linux系统中g++是有各种优化级别的。 默认优化级别是-O0,即没有优化。
优化后,发现按ctrl+c 程序不会结束。因为main执行流判定代码里没有对gflag进行修改,觉得不用每次都从内存拿数据,直接在第一次拿的时候,把gflag的值优化到寄存器里,从此之后,每次while检测只检测寄存器里的值。当收到信号后修改gflag的值,修改的是内存里的gflag,就导致寄存器隐藏了内存中的真实值。这是编译器过度优化导致的问题。
为了保持内存的可见性,就有了volatile关键字。
有了volatile修饰,就没有被优化的问题了。 volatile的作用:保持内存的可见性,告知编译器,被该关键字修饰的变量,不允许被优化,对该变量的任何操作,都必须在真实的内存中进行操作
子进程在终止时会给父进程发SIGCHLD信号,该信号的默认处理动作是忽略,父进程可以自定义SIGCHLD信号的处理函数,这样父进程只需专心处理自己的工作,不必关心子进程了,子进程终止时会通知父进程,父进程在信号处理函数中调用wait清理子进程即可。
如果有多个子进程同时退出,此时会同一时间向父进程发送多个SIGCHLD信号。普通信号是用pending位图接收信号的,收到了多个SIGCHLD信号,但pending位图只会记录一次,导致最后只会回收一个子进程。所以waitpid等待时,外面需要套一层while循环,不断回收。 如果有的子进程退出,有的永远不退出,此时就要用非阻塞等待。否则就会阻塞在信号捕捉里,父进程永远做不了别的事情。
wait和waitpid函数清理僵尸进程,父进程可以阻塞等待子进程结束,也可以非阻塞地查询是否有子进 程结束等待清理(也就是轮询的方式)。采用第一种方式,父进程阻塞了就不能处理自己的工作了;采用第二种方式,父进程在处理自己的工作的同时还要记得时不时地轮询一下,程序实现复杂。
要想不产生僵尸进程还有另外一种办法:父进程调用signal将SIGCHLD的处理动作置为SIG_IGN,这样fork出来的子进程在终止时会自动清理掉,不会产生僵尸进程,也不会通知父进程。
系统默认的忽略动作和用户用signal函数自定义的忽略通常是没有区别的,但这是一个特例。此方法对于Linux可用,但不保证 在其它UNIX系统上都可用。 如果不关心子进程的退出信息,不想产生僵尸进程,就可以用这样做。