linux信号 | 学习信号四步走 | 全解析信号的产生方式
前言：本节内容是信号， 主要讲解的是信号的产生。信号的产生是我们学习信号的第二个阶段。 我们已经学习过第一个阶段——信号的概念与预备知识（没有学过的友友可以查看我的前一篇文章）。 以及我们还没有学习信号的第三个阶段——信号的保存与处理。
ps：本节内容主要为信号的产生， 需要友友们了解信号的概念以及信号的预备知识后再进行学习。
信号的产生有很多种， 但是无论信号如何产生， 最终一定是由 OS 发出的。 ——为什么？ 因为OS是进程的管理者。 就比如弟弟惹到了姐姐， 然后姐姐向爸爸告状， 爸爸收到姐姐的告状后就会去找弟弟， 然后教育一顿。 这里面爸爸就是执行者OS， 然后弟弟就是被管理者， 姐姐就是发送的那个信号。
目录
键盘组合键
kill命令
系统调用
kill 系统调用
接口
应用
raise——发送一个信号给调用者
接口
应用
abort
接口
应用
异常
异常：为什么除零， 或者野指针会给进程发送信号呢？
除零
野指针
软件条件
alarm
dump
键盘组合键
产生信号的第一种方法是键盘组合键， 信号组合健种最常见ctrl + C， 我们在运行一个程序，如果程序陷入死循环， 我们这个时候无论输入任何指令都是没有用的。 所以就要使用ctrl + C将程序退出。 这里我们点击ctrl + C， 本质其实就是给进程发送了一个信号。 这个信号是2号信号。
同样的， 键盘组合键还有另外一种比较常见的组合键就是ctrl + 。 同样也是给进程发送信号， 不过信号序号是3号信号。 当进程识别到这些信号， 就会终止， 退出自己。
这里有一个函数， 用来捕捉我们的信号， 叫做signal
这里面有两个参数， 第一个参数是signum，意思是要捕捉的信号编号。 第二个参数是handler， 意思是捕捉到信号后，重新定义的信号的处理方式。
如下是一个2号信号的捕捉操作：
kill命令
kill 命令可以用来终止正在运行的进程。kill命令通过发送不同的信号给目标进程， 如我们经常使用的kill -9。 kill命令的使用方法是kill 命令序号 PID。
这里博主利用信号的捕捉来验证我们的kill命令。（注意， 接下来实验过程中我们可以发现signal并不能捕捉9号和19号命令）， 下面是代码:
#include
using namespace std;
#include
#include
#include
#include
void myhander(int x)
{
cout << "signal is " << x << endl;
}
int main()
{
for (int i = 1; i <= 31; i++)
{
signal(i, myhander);
}
while (true)
{
cout << "hello signal ， PID : " << getpid() << endl;
sleep(1);
}
return 0;
} 接下来我们就完成编译。 并且打开两个终端， 一个终端用来发送信号即可：
博主上面对于1 ~ 31个信号没有全部进行测试， 但是友友们可以全部测试一下。 然后就能发现， 除了9号和19号， 其他的信号都可以被捕捉。 并且也验证了我们的kill命令可以给进程发送信号。——那么， 为什么9号和19号信号要暴露出来， 不能被捕捉。 是因为这两个信号， 一个是杀掉进程， 一个是暂停进程。 如果我们今天想写一个恶意病毒， 恶意软件。那么我们把9号、19号信号一捕捉， 操作系统就杀不掉这个病毒了， 那怎么办？ 所以， 必须要将9号和19号暴露出来。
系统调用
kill 系统调用
接口
kill系统调用是发送一个信号给进程。这里的第一个参数进程pid， 意思是发给哪一个进程。第二个参数是sig， 表示发送哪一个信号。
kill调用的返回值是如果成功， 零被返回。 如果失败， -1被返回。
应用
这里我们定义一个proc程序， 用来循环打印一条语句：
#includeusing namespace std; #include #include #include void myhander(int signum) { cout << "signal is : " << signum << endl; } int main() { for (int i = 1; i <= 31; i++) { signal(i, myhander); } while (true) { cout << "i am a process, pid : " << getpid() << endl; sleep(1); } return 0; } 这里之所以要signal捕捉信号是因为要检测当前进程是否收到了信号， 正确的信号。 并且这个语句执行后， 会循环打印进程自己当前的pid。
然后， 我们创建另一个程序， mykill, 用来封装kill系统调用。
#includeusing namespace std; #include #include #include #include int main(int argc, char* argv[]) { if (argc == 3) { kill(stoi(argv[0]), stoi(argv[1])); } else { cout << "please set mykill.exe + pid + sig" << endl; exit(1); } return 0; }
运行结果：
raise——发送一个信号给调用者
接口
这里面的参数只有一个sig， 意思是要给当前进程发送哪一个信号。 返回值int， 当成功时返回零， 失败时返回非零。
应用
#include
using namespace std;
#include
#include
#include
#include
void myhander(int x)
{
cout << "signal is " << x << endl;
}
int main()
{
signal(2, myhander);
int cnt = 5;
while (true)
{
cout << "hello signal ， PID : " << getpid() << endl;
sleep(1);
cnt--;
if (cnt == 0) raise(2);
}
return 0;
} 运行结果（然后我们运行起来可以发现， 5秒之后， 确实给我们发送了一个2号信号。
abort
接口
这一个调用是引起一个正常的进程进行终止。
应用
运行结果：
我们运行这个程序， 就会发现， 这个进程5秒之后， abort了。 这个abort其实就是6号信号， 所以我们这里可以直接捕捉他。
但是问题是， 我们捕捉了， 但是也退出了！！注意， 这个退出不是信号的问题， 这个是abort的问题。 abort不仅仅捕捉了我们的6号信号， 而且还做了一个工作——必须让我们这个进程终止。 这个abort在底层其实也相当于是有一个kill（getpid(), 6)。 但是还多做了一些工作， 比如exit之类的。
异常
异常博主认为是最重要的信号的产生方式。 因为我们在运行程序的时候， 遇到的信号， 基本都是由异常引起的。 我们的野指针发送信号， 我们的除零错误要发送信号。
我们平时运行程序，退出的方式无非就是三种——代码跑完， 结果正确； 代码跑完，结果不正确； 代码没跑完， 出现异常。
这里我们先写一段代码， 看一下异常：
上面的运行结果就能看出发生了异常， 直接报错。 但是问题是， 上面的报错是31个信号的哪一种呢？ ——这里其实是八号信号， 如下图：
我们可以使用自定义捕捉这个异常：
然后运行， 就能看到下图的情况：
这里我们会发现， 虽然我们知道了这个错误是八号信号。 但是问题是他怎么一直在死循环打印呢？ 我们知道， 我们的捕捉函数里面， 没有退出进程， 只有一条语句， 那么也就是说， 我们的程序发生除零错误不会退出， 进程一直再跑， 所以OS一直发送信号， 进程也就一直都在打印信号。
我们换成下面的代码：
void myhander(int signum)
{
cout << "get a signum : " << signum << endl;
}
int mian()
{
signal(SIGFPE, myhander);
cout << "pointer error before " << endl;
sleep(1);
int* p = nullptr;
*p = 100;
sleep(1);
cout << "pointer error after " << endl;
return 0;
}
这个进程我们会发现， 两秒之后也退出了！并且发生了段错误。 段错误在信号中是11信号，SIGSEGV, 如何验证和上面的八号信号的验证方式是一样的。这里直接贴运行结果。 同样会死循环打印语句， 不发生退出。 ——因为11号信号被捕捉。
上面捕捉信号也是在处理异常信号。 那么问题来了， 处理异常信号， 一定会退出吗？ 答案是不一定， 一般情况下， 如果是默认动作， 异常会推出。 但是如果是自定义动作， 也就是信号被捕捉， 这个时候异常不一定会推出。 但是一旦异常推出， 一定是执行了某个信号的处理方法。
但是我们虽然可以捕捉信号， 不让它退出，只不过这个意义不大， 因为我们的进程已经发生了错误了。那么我们大概率还是要让这个异常终止。
异常：为什么除零， 或者野指针会给进程发送信号呢？
除零
我们上面说过， 进程接收到信号， 一定是OS发出的， 一旦我们的计算机里面出现了除零错误或者野指针问题， 操作系统又识别到了这些问题， 那么操作系统就会给我们的进程发送信号。 收到信号后我们的进程对于信号的默认处理动作就是终止自己， 所以它就直接崩溃了。 但是这里的问题不是操作系统会检测到除零或者野指针，而是如何检测到除零或者野指针：
首先， 我们知道cpu中有着许许多多的寄存器。 其中， EIP、PC指针指向我们的进程的上下文。
其中， 状态寄存器有标记位， 是把寄存器按照比特位级别设计的。 状态寄存器里面的位数各自代表什么含义是由芯片制造商定好的。
状态寄存器里面有一个标记位， 叫做一处标记位。 当我们除零的时候， 结果就会非常大。 那么就溢出了。 这个标记为就从0变成1了。
而且，要知道， 我们cpu中的数据， 其实都是进程的上下文。 虽然我们修改的是cpu中的状态寄存器。 但是进程只影响他自己。 ——什么意思？ 就是说，我们的进程是不断切换的， 所以寄存器里面的数据也是不断切换的。 当我们的进程切换的时候， 会把我们自己的上下文带走， 下一个进程将自己的上下文放上去。 所以进程之间是不会有影响的。 所以， 不要认为cpu发生了异常， 就说明操作系统出问题了。 因为我们的用户的各种行为， 都是被进程包裹的， 硬件异常是代表这个进程出现了异常， 并不会波及我们的操作系统。 也就是说， 引起出错的永远是进程， cpu出错， 我们的系统照跑不误。
那么问题来了， 我们的cpu这个时候发生溢出了， 我们的操作系统要不要知道呢？ 为什么呢？ ——必须要知道！操作系统必须得知道！因为操作系统是硬件的管理者！！！cpu也是硬件！！操作系统在运行我们的进程的时候， 会有类似检查或者中断的方法， 得知我们的cpu出现溢出了， 然后操作系统向进程发送信号， 进程收到信号后， 就崩溃了。 ——简而言之就是我们这个除零问题被转化为了硬件问题， 表现在硬件上面， 进而被操作系统识别到。 被操作系统识别， 操作系统就能对信息做处理。 操作系统的处理并不影响整个系统的稳定性， 影响的是当前进程， 因为cpu内的问题， 是属于进程的问题。
野指针
上面的进程我们的进程在通过页表进行查表的时候， 这个查表不是操作系统直接来查的， 因为查表是很费时间的。 ——这个查表是由一个MMU， 内存的管理单元来完成的。
在上面的图中， 我们的cpu读到的都是虚拟地址。 从虚拟地址到物理地址， 需要经过MMU的转化， 而野指针就是这个转化失败了——要么没有映射关系， 要么越界了， 越权了。 转化失败， MMU报错， 代表里面的硬件发生了报错， 转化失败后的地址会放到另一个寄存器里面， 这个报错， 也能被cpu识别到。
那么， 操作系统是怎么知道， 我们的cpu是溢出了， 还是野指针了呢？ ——因为对应的是cpu内不同类型的寄存器的报错！！！
那么既然报错后， 操作系统会发送信号让进程崩溃， 但是如果我们将信号捕捉， 不让进程崩溃呢？ ——那么就意味着我们的进程在异常的时候也要一直被调度运行！！！所以为什么我们上面会看到死循环呢？ 就是因为我们的进程发生了问题， 但是我们没有修正这个问题， 硬件问题一直存在， 随着我们的调度， 那么我们的上下文的错误就一直存在。 所以操作系统就一直检测到这个错误， 它就会一直发信号， 我们就能一直捕捉这个信号。 ！！！
对于异常的进程来讲， 即便向后运行， 结果可能也是错误的， 所以进程发生异常， 就应该是终止掉， 所以大部分信号的默认动作都是终止掉进程。 ——但是为什么会有捕捉信号呢？ 因为捕捉信号， 并不是用来解决问题， 而是用来告诉用户， 你是为什么挂掉的！！
那么， 为什么操作系统这么温和？ 当硬件报错的时候， 不直接将进程的pcb， 页表， 地址空间全部干掉呢？ ——这是因为进程里面有可能保存着许多的重要的数据， 如果直接将这些东西干掉，这些数据会丢失， 所以要设置信号， 告诉上层哪里出错了， 为什么出错了， 然后让上层自己想办法解决。
软件条件
alarm
上面我们讲述的异常也可以成为软件异常。现在有另外一种， 叫做软件条件。 ——这个软件条件叫做闹钟。
alarm是在我们的系统里面设置一个闹钟， 一旦闹钟响了， 那么就会给我们的进程传送一个信号。 这个参数就是多少秒之后会给我们发送这个信号。下面是这个接口的返回值：
这个返回值是提前醒来， 距离闹钟响之间剩余的时间。
下面我们写这么一串代码：
然后运行它
我们会发现， 虽然闹钟到达事件后会发送信号， 但是仅仅只是发送一次！这是因为这个闹钟不是异常， 它只响一次。 那么问题来了， 当我们重复设置闹钟的时候， 加入设定了一个5秒的闹钟， 但是过了三秒又设置了一个闹钟， 这个时候会发生什么情况呢？ ——答案是第一个闹钟剩余的时间会返回。
为了验证， 我们可以使用下面这串代码进行测试。
按照上面的结论， 我们猜测最终打印出来的是6：
我们的闹钟是如何确定时间的呢？ ——使用时间戳和参数， 我们的进程， 我们知道进程可以直接获取时间， 我们的闹钟里面一定有一个时间戳的成员变量的。 未来我们进程获取时间戳变量， 填到闹钟里， 闹钟再根据参数， 两者一加， 就是未来时间了！！！
那么知道了未来时间， 我们操作系统里面又维护着当前时间， 当这个时间 >= 未来时间的时候， 就能知道闹钟到没到时间了。
那么我们未来系统中一定存在着大量的闹钟， 我们如果想要确定哪个闹钟响过了， 就把他去掉。 可以使用什么数据结构呢？ ——堆
dump
我们在进程控制的时候， 曾经说过wait的返回值status， 这个返回值当中的前八个比特位是代表的退出码， 第0 ~ 7是代表的终止信号， 第8个比特位我们说过叫做core dump标志。
这个core dump是什么当时我们并没有说过， 这里可以说了。 我们看下面的图：里面有term， 有core。 还有其他的动作， 但是其他的动作我们不考虑， 我们只看core和term。 这个dump比特位， 就是代表的是core或者term。为零是term， 为1是core。
现在我们来重新写一下代码， 看一下我们的dump比特位：
现在我们来看一下：
对于2号信号：
对于8号信号：
两次都是dump0， 但是我们的8是core， 2是term。 这是为什么呢？ 是什么呢 ？ 怎么办？ ——这是因为云服务器上面的core默认是关闭的。
我们可以看一下ulimit -a, 这个是查看系统当中的标准的配置。
这里面有一个core file size的选项， -c就是用来查看。 当前它是设为0的。 我们可以使用 -c选项后边加一个数字， 可以用来设置core。
这一次， 我们再来使用8号信号。 就能看到结果变了。
更重要的是， 这里生成了一个core.4017, 也就是刚刚进程的PID——打开系统的core dump功能， 一旦进程出现异常， 我们的OS会将进程在内存中的运行信息， 给我们dump（转储）到进程的当前目录（磁盘）形成core.pid文件——这个就叫做核心转储（core dump）
上面的core.pid有什么用？ ——我们的程序在运行时发生错误， 我们最想要知道的是什么呢？ ——是不是定位错误的位置， 也就是在哪一行出错了。 我们可以使用core dump数据， 来定位原始代码当中， 在运行过程中哪方面出错了。
我们使用gdb调试左边的代码， 然后进入core.pid文件里面， 就能看到错误信息了。
core文件能够让我们复现问题之后， 直接定位到出错行。 就是先运行， 再core-file。 ——这个叫做事后调试。 而我们边跑边调叫做事中调试。
现在的问题是， 为什么云服务器是要把它进行关闭的。 我们知道core文件比较大。 在当代服务器上面， 如果一个服务器挂掉了， 是要让运维重新起来的。 可是大公司的后端服务器集群非常多。 如果运维手动去起， 那么太慢了。 所以大公司要做很多很多自动化运维的手段， 比如说我们的服务器挂掉了， 那么我们要自动的检测服务器出问题了， 第二点就是先将服务器启动起来， 最后才是根据日志排查问题。
所以， 一旦服务器挂掉了， 在很多系统当中会自动重启。 可是， 问题是一般人一年才挂一次， 半年挂一次， 结果呢你写的服务只要跑起来就挂。 虽然在大部分公司， 这样的程序员根本不会有， 但是可能会出现这样的问题。 要知道， 我们的计算机的速度是很快的， 我们的计算器一晚上的重启， 如果每一次重启都会生成一个core-pid文件， 那么就会导致本来是云服务器上面的一个服务挂掉了， 结果后来变成了磁盘空间被core-pid文件打满了。 那么就可能连操作系统都挂掉了。 所以， core dump的功能在线上一般都要禁掉， 保证我们的系统重启功能一直都要有效。 不要让core dump冲击磁盘， 影响服务。
——————以上就是本节全部内容哦， 如果对友友们有帮助的话可以关注博主， 方便学习更多知识哦！！！
