linux万字图文学习进程信号
1. 信号概念
信号是进程之间事件异步通知的一种方式，属于软中断。
1.1 linux中我们常用Ctrl+c来杀死一个前台进程
- 1. Ctrl-C 产生的信号只能发给前台进程。一个命令后面加个&可以放到后台运行,这样Shell不必等待进程结束就可以接受新的命令,启动新的进程。
- 2. Shell可以同时运行一个前台进程和任意多个后台进程,只有前台进程才能接到像 Ctrl-C 这种控制键产生的信号。
- 3. 前台进程在运行过程中用户随时可能按下 Ctrl-C 而产生一个信号,也就是说该进程的用户空间代码执行到任何地方都有可能收到 SIGINT 信号而终止,所以信号相对于进程的控制流程来说是异步(Asynchronous)的。
2.常见的信号
用kill -l命令可以察看系统定义的信号列表
- 每个信号都有一个编号和一个宏定义名称,这些宏定义可以在signal.h中找到
- 编号34以上的是实时信号
- 这些信号各自在什么条件下 产生,默认的处理动作是什么,在signal(7)中都有详细说明: man 7 signal
3. 信号本质
信号是软件中断，是在软件层次上对中断机制的一种模拟，在原理上，一个进程收到一个信号与处理器收到一个中断请求可以说是一样的。信号是异步的，一个进程不必通过任何操作来等待信号的到达，事实上，进程也不知道信号到底什么时候到达。
信号是进程间通信机制中唯一的异步通信机制，可以看作是异步通知，通知接收信号的进程有哪些事情发生了。信号机制经过POSIX实时扩展后，功能更加强大，除了基本通知功能外，还可以传递附加信息。
4. 信号来源
4.1 通过终端按键产生信号
SIGINT的默认处理动作是终止进程,SIGQUIT的默认处理动作是终止进程并且Core Dump
4.1.1 什么是Core Dump
当一个进程要异常终止时,可以选择把进程的用户空间内存数据全部 保存到磁 盘上,文件名通常是core,这叫做Core Dump。进程异常终止通常是因为有Bug,比如非法内存访问导致段错误, 事后可以用调试器检查core文件以查清错误原因,这叫做Post-mortem Debug（事后调试）。一个进程允许 产生多大的core文件取决于进程的Resource Limit(这个信息保存 在PCB中)。默认是不允许产生core文件的, 因为core文件中可能包含用户密码等敏感信息,不安全。
在开发调试阶段可以用ulimit命令改变这个限制,允许 产生core文件。 首先用ulimit命令改变Shell进程的Resource Limit $ ulimit -c 1024 允许core文件最大为1024K
4.1.2终端按键的信号捕捉
#include
#include
int count = 0;
void handler(int sig)
{
printf("the catched count is %d ",++count);
printf("catch a sig : %d\n", sig);
}
int main()
{
signal(2, handler); // 信号是可以被自定义捕捉的，siganl函数就是来进行信号捕捉的
while (1)
;
return 0;
} 4.2. 调用系统函数向进程发信号
常用的kill 还有pkill和killall等
kill命令是调用kill函数实现的。kill函数可以给一个指定的进程发送指定的信号。raise函数可以给当前进程发送指定 的信号(自己给自己发信号)。
#include
int kill(pid_t pid, int signo);
int raise(int signo);
这两个函数都是成功返回0,错误返回-1。
#include
void abort(void);
就像exit函数一样,abort函数总是会成功的,所以没有返回值。
abort函数使当前进程接收到信号而异常终止。 4.3 由软件条件产生信号
SIGPIPE是一种由软件条件产生的信号，在管道中读端被关闭了，写端一直写
Broken pipe: write to pipe with no readers.
管道破裂。这个信号通常在进程间通信产生，比如采用FIFO(管道)通信的两个进程，
读管道没打开或者意外终止就往管道写，
写进程会收到SIGPIPE信号。此外用Socket通信的两个进程，
写进程在写Socket的时候，读进程已经终止。
#include
unsigned int alarm(unsigned int seconds);
调用alarm函数可以设定一个闹钟,也就是告诉内核在seconds秒之后给当前进程发SIGALRM信号, 该信号的默认处理动作是终止当前进程。
可以重复设置，新的会覆盖旧的并返回上次闹钟剩余的时间，可以设置为0，意思就是取消闹钟，并返回上次闹钟剩余的时间 4.4 硬件异常产生信号
硬件异常被硬件以某种方式被硬件检测到并通知内核,然后内核向当前进程发送适当的信号。例如当前进程执行了除以0的指令,CPU的运算单元会产生异常,内核将这个异常解释 为SIGFPE信号发送给进程。再比如当前进程访问了非法内存地址（野指针）,MMU会产生异常,内核将这个异常解释为SIGSEGV信号发送给进程。
4.4.1 硬件异常产生信号的捕获
并且硬件异常后程序将并不会继续向下执行
#include
#include
#include
#include
int count = 0;
int count2=0;
void handler(int sig)
{
printf("the catched count is %d count2:%d ",++count,count2);
printf("catch a sig : %d\n", sig);
}
int main()
{
signal(11, handler); // 信号是可以被自定义捕捉的，siganl函数就是来进行信号捕捉的
while (1){
sleep(1);
count2++;
int *p=NULL;
*p=100;
}
return 0;
} 
5. 信号的分类
1、可靠信号与不可靠信号
不可靠信号：
Linux信号机制基本上是从Unix系统中继承过来的。早期Unix系统中的信号机制比较简单和原始，后来在实践中暴露出一些问题，因此，把那些建立在早期机制上的信号叫做"不可靠信号"，信号值小于SIGRTMIN(Red hat 7.2中，SIGRTMIN=32，SIGRTMAX=63)的信号都是不可靠信号。
不可靠信号主要的问题是：
- 进程每次处理信号后，就将对信号的响应设置为默认动作。在某些情况下，将导致对信号的错误处理；因此，用户如果不希望这样的操作，那么就要在信号处理函数结尾再一次调用signal()，重新安装该信号。
- 信号可能丢失，后面将对此详细阐述。 如果在进程对某个信号进行处理时，这个信号发生多次，对后到来的这类信号不排队，那么仅传送该信号一次，即发生了信号丢失。
因此，早期unix下的不可靠信号主要指的是进程可能对信号做出错误的反应以及信号可能丢失。
Linux支持不可靠信号，但是对不可靠信号机制做了改进：在调用完信号处理函数后，不必重新调用该信号的安装函数（信号安装函数是在可靠机制上的实现）。因此，Linux下的不可靠信号问题主要指的是信号可能丢失。
可靠信号
信号值位于SIGRTMIN和SIGRTMAX之间的信号都是可靠信号，可靠信号克服了信号可能丢失的问题。Linux在支持新版本的信号安装函数sigation（）以及信号发送函数sigqueue()的同时，仍然支持早期的signal（）信号安装函数，支持信号发送函数kill()。
注：不要有这样的误解：由sigqueue()发送、sigaction安装的信号就是可靠的。事实上，可靠信号是指后来添加的新信号（信号值位于SIGRTMIN及SIGRTMAX之间）；不可靠信号是信号值小于SIGRTMIN的信号。信号的可靠与不可靠只与信号值有关，与信号的发送及安装函数无关。目前linux中的signal()是通过sigation()函数实现的，因此，即使通过signal（）安装的信号，在信号处理函数的结尾也不必再调用一次信号安装函数。同时，由signal()安装的实时信号支持排队，同样不会丢失。
对于目前linux的两个信号安装函数:signal()及sigaction()来说，它们都不能把SIGRTMIN以前的信号变成可靠信号（都不支持排队，仍有可能丢失，仍然是不可靠信号），而且对SIGRTMIN以后的信号都支持排队。这两个函数的最大区别在于，经过sigaction安装的信号都能传递信息给信号处理函数（对所有信号这一点都成立），而经过signal安装的信号却不能向信号处理函数传递信息。对于信号发送函数来说也是一样的。
6. 信号处理常见方式
- 1. 忽略此信号。
- 2. 执行该信号的默认处理动作。
- 3. 提供一个信号处理函数,要求内核在处理该信号时切换到用户态执行这个处理函数,这种方式称为捕捉 (Catch)一个信号。
7. 信号集操作函数
7.1 信号一些相关概念
- 实际执行信号的处理动作称为信号递达(Delivery)
- 信号从产生到递达之间的状态,称为信号未决(Pending)。
- 进程可以选择阻塞 (Block )某个信号。
- 被阻塞的信号产生时将保持在未决状态,直到进程解除对此信号的阻塞,才执行递达的动作.
- 注意,阻塞和忽略是不同的,只要信号被阻塞就不会递达,而忽略是在递达之后可选的一种处理动作。
7.2 信号在内核中的表示
- 每个信号都有两个标志位分别表示阻塞(block)和未决(pending),还有一个函数指针表示处理动作。信号产生时,内核在进程控制块中设置该信号的未决标志,直到信号递达才清除该标志。在上图的例子中,SIGHUP信号未阻塞也未产生过,当它递达时执行默认处理动作。
- SIGINT信号产生过,但正在被阻塞,所以暂时不能递达。虽然它的处理动作是忽略,但在没有解除阻塞之前不能忽略这个信号,因为进程仍有机会改变处理动作之后再解除阻塞。
- SIGQUIT信号未产生过,一旦产生SIGQUIT信号将被阻塞,它的处理动作是用户自定义函数sighandler。 如果在进程解除对某信号的阻塞之前这种信号产生过多次,将如何处理?POSIX.1允许系统递送该信号一次或多次。Linux是这样实现的:常规信号在递达之前产生多次只计一次,而实时信号在递达之前产生多次可以依次放在一个队列里。注意此处不讨论实时信号。
7.3 sigset_t
从上图来看,每个信号只有一个bit的未决标志,非0即1,不记录该信号产生了多少次,阻塞标志也是这样表示的。 因此,未决和阻塞标志可以用相同的数据类型sigset_t来存储,sigset_t称为信号集,这个类型可以表示每个信号 的“有效”或“无效”状态,在阻塞信号集中“有效”和“无效”的含义是该信号是否被阻塞,而在未决信号集中“有效”和“无效”的含义是该信号是否处于未决状态。
阻塞信号集也叫做当 前进程的信号屏蔽字(Signal Mask),这里的“屏蔽”应该理解为阻塞而不是忽略。
7.4 信号集操作函数
sigset_t类型对于每种信号用一个bit表示“有效”或“无效”状态,至于这个类型内部如何存储这些bit则依赖于系统 实现,从使用者的角度是不必关心的,使用者应该调用以下函数来操作sigset_ t变量,而不应该对它的内部数据做 任何解释,比如用printf直接打印sigset_t变量是没有意义的
#include
int sigemptyset(sigset_t *set);//置空
int sigfillset(sigset_t *set);//置满
int sigaddset (sigset_t *set, int signo);//添加信号到信号集
int sigdelset(sigset_t *set, int signo);//在信号集中删除指定信号
int sigismember（const sigset_t *set, int signo); //在信号集查找是否有该信号 这四个函数都是成功返回0,出错返回-1。sigismember是一个布尔函数,用于判断一个信号集的有效信号中是否包含 某种 信号,若包含则返回1,不包含则返回0,出错返回-1。
7.5 调用函数sigprocmask可以读取或更改进程的信号屏蔽字(阻塞信号集)。
7.6 sigpending
#include
sigpending
读取当前进程的未决信号集,通过set参数传出。调用成功则返回0,出错则返回-1。 7.7 信号阻塞时未决信号的打印
#include
#include
#include
using namespace std;
void my_printf_sig(sigset_t* a){
for(int i=0;i<65;i++){
if(sigismember(a,i)){
cout<<"1";
//cout<<" "< 
7.8 内核如何实现信号的捕捉
如果信号的处理动作是用户自定义函数,在信号递达时就调用这个函数,这称为捕捉信号。由于信号处理函数的代码 是在用户空间的,处理过程比较复杂,举例如下: 用户程序注册了SIGQUIT信号的处理函数sighandler。 当前正在执行 main函数,这时发生中断或异常切换到内核态。 在中断处理完毕后要返回用户态的main函数之前检查到有信号 SIGQUIT递达。 内核决定返回用户态后不是恢复main函数的上下文继续执行,而是执行sighandler函 数,sighandler 和main函数使用不同的堆栈空间,它们之间不存在调用和被调用的关系,是 两个独立的控制流程。 sighandler函数返 回后自动执行特殊的系统调用sigreturn再次进入内核态。 如果没有新的信号要递达,这次再返回用户态就是恢复 main函数的上下文继续执行了。
7.9 sigaction
7.9.1 siaction的定义
- sa_handler 是一个函数指针，指定信号处理函数，这里除可以是咱们自定义的处理函数外，还可以为SIG_DFL(采用默认的处理方式)或SIG_IGN(忽略信号)。它的处理函数只有一个参数，即信号值。
- sa_mask 是一个信号集，它可以指定在信号处理程序执行过程中哪些信号应当被屏蔽，在调用信号捕获函数前，该信号集要加入到信号的信号屏蔽字中。
- sa_flags 中包含了很多标志位，是对信号进行处理的各个选择项。它的常见可选值如下表所示
8. volatile:
volatile 作用：保持内存的可见性，告知编译器，被该关键字修饰的变量，不允许被优化，对该变量 的任何操作，都必须在真实的内存中进行操作
9. SIGCHLD信号
父进程调 用sigaction将SIGCHLD的处理动作 置为SIG_IGN,这样fork出来的子进程在终止时会自动清理掉,不 会产生僵尸进程,也不会通知父进程。系统默认的忽 略动作和用户用sigaction函数自定义的忽略 通常是没有区别的,但这是一个特例。此方法对于Linux可用,但不保证 在其它UNIX系统上都可用。
#include
#include
#include
#include
#include
#include
#include
using namespace std;
void sigchld_handler(int signum)
{
// 处理SIGCHLD信号，可以不需要具体的逻辑
// 在这个示例中，我们可以仅仅打印一条消息
printf("Received SIGCHLD signal\n");
}
int main()
{
// 设置SIGCHLD的处理动作为SIG_IGN
// struct sigaction sa;
// sa.sa_handler = SIG_IGN;
// sigemptyset(&sa.sa_mask);
// sa.sa_flags = 0;
// sigaction(SIGCHLD, &sa, NULL);
pid_t pid = fork();
if (pid == 0)
{
// 子进程
// printf("Child process\n");
cout << "child process pid is : " << getpid() << endl;
// do something...
sleep(30);
cout << "child exit" << endl;
exit(0);
}
else if (pid > 0)
{
// 父进程
// printf("Parent process\n");
cout << "parent process pid is : " << getpid() << endl;
// 等待子进程结束
sleep(100); // 等待足够长的时间，以确保子进程已经结束
printf("Parent process exiting\n");
}
else
{
// fork失败
printf("Fork failed\n");
return 1;
}
return 0;
}
// while :; do ps axj|head -1&& ps axj |grep sig_ignore|grep -v grep;sleep 1; done; 思考总结：
所有信号产生，最终都要有OS来进行执行，为什么？OS是进程的管理者
信号的处理是否是立即处理的？在合适的时候
信号如果不是被立即处理，那么信号是否需要暂时被进程记录下来？记录在哪里最合适呢？
在Linux中，如果信号在接收时不能立即处理，进程通常需要将信号记录下来以便稍后处理。Linux使用信号队列来存储接收到但尚未处理的信号。
每个Linux进程都有一个信号处理器表，用于存储信号处理程序的地址。当进程收到一个信号时，操作系统会根据进程的信号处理器表确定应该执行哪个信号处理程序。
在信号处理期间，Linux使用信号屏蔽字和挂起信号队列来处理挂起的信号。挂起信号队列是内核中的数据结构，用于存储挂起的信号。当进程正在处理信号时，其他同类信号可能会被挂起，并在当前信号处理程序完成后按照一定的优先级顺序逐个处理。
挂起信号队列位于内核中，因此信号被记录在内核的上下文中。这种设计可以保证在进程切换时仍然可以正确处理挂起信号。
最合适记录信号的位置是在Linux内核的信号挂起队列中。这样，在进程重新调度执行时，操作系统可以检查信号挂起队列并将挂起的信号传递给进程进行处理。
需要注意的是，Linux对于不同类型的信号有不同的处理机制。一些信号（如SIGSTOP和SIGKILL）不能被挂起，它们会立即中断进程的执行。但大多数其他信号可以挂起并在适当的时候处理。
总之，Linux使用信号挂起队列来记录未立即处理的信号。这种机制确保了信号的顺序和正确处理，同时保证了信号的可靠交付。
一个进程在没有收到信号的时候，能否能知道，自己应该对合法信号作何处理呢？
能够，信号的默认处理动作在linux的内核中
如何理解OS向进程发送信号？
理解操作系统（OS）向进程发送信号可以从两个方面来考虑：
1.异步事件通知：操作系统可以在特定事件发生时向进程发送信号，以通知进程发生了某些异步事件。这些事件可能包括：
用户按下特定的键盘组合，例如Ctrl+C，触发SIGINT信号。
定时器到期，触发SIGALRM信号。
子进程终止，触发SIGCHLD信号。
硬件故障，例如除零错误，触发SIGFPE信号。
当这些事件发生时，操作系统会向目标进程发送相应的信号，以便进程可以作出相应的反应。这可以通过操作系统的信号传递机制实现，如Linux中的信号队列。
2.进程间通信：除了异步事件通知外，操作系统还可以通过信号在进程之间进行通信。进程可以向其他进程发送信号以触发特定的行为或进行协调。这可以用于以下情况：
进程间的同步和通知：一个进程可以向另一个进程发送信号来通知某个事件的发生，以便目标进程进行相应的处理。例如，父进程向子进程发送信号以指示某个任务已完成。
进程控制和管理：某些信号可以用于控制和管理进程。例如，通过SIGKILL信号可以强制终止一个进程，通过SIGSTOP信号可以暂停一个进程的执行。
信号处理程序的使用：进程可以注册自定义的信号处理程序，当接收到特定信号时，操作系统会调用该处理程序来执行特定的操作。这样进程就可以利用信号处理程序来处理特定事件或执行自定义逻辑。
总体而言，操作系统通过向进程发送信号，实现了事件通知、进程间通信和进程控制等功能。这为进程提供了一种有效的方式来与操作系统进行交互，并实现合适的响应和协作。
能否描述一下完整的发送处理过程？
当进程发送信号时，它调用kill()、raise()或发送信号的相关系统调用。内核接收到信号后，会检查接收进程的权限和状态。如果接收进程具有对该信号的处理程序，并且信号未被阻塞，则内核会将信号递交给接收进程的信号处理程序。如果接收进程没有对信号进行处理或信号被阻塞，则内核采取默认的行为，如终止进程(SIGKILL)或忽略该信号(SIGIGN)。整个过程涉及信号发送、接收进程状态检查以及信号的处理或默认行为的执行。
详细版：
发送信号：
信号源：信号可以来自多个源头，例如操作系统触发的异步事件、其他进程的信号发送、硬件中断等。
信号发送：信号源通过系统调用（如kill()）或其他适当的机制向目标进程发送信号。发送信号时，需要指定目标进程的标识符，如进程ID（PID）或进程组ID（PGID）。
接收信号：
目标进程：操作系统在目标进程上选择一个合适的执行点来接收信号。这通常是在进程的用户态代码执行时进行检查。
信号递交检查：目标进程在执行期间会定期进行对信号的检查，以确定是否有新的信号需要处理。这个过程通常是由操作系统提供的信号传递机制完成的。
信号处理：
默认行为：如果进程未注册特定信号的处理程序，或者没有明确指定默认操作的信号，操作系统将使用默认的信号处理行为来处理信号。这可能包括终止进程、忽略信号或者进行其他特定的操作。
自定义处理程序：进程可以使用系统调用（如signal()或sigaction()）注册自定义的信号处理程序。当信号到达时，操作系统会调用相应的信号处理程序来执行特定的操作或指令。
信号处理程序执行：
信号处理程序执行在进程的上下文中，可以执行特定的代码逻辑来响应信号。信号处理程序可以进行一系列操作，如记录日志、修改进程状态、发送其他信号等。
注意，由于信号处理程序在进程的执行上下文中执行，它必须是轻量级且可靠的。一些操作（如堆内存分配和长时间的计算）可能不适合在信号处理程序中执行。
信号处理完成：
处理结果：信号处理程序完成后，进程可以根据需要执行后续操作，并继续执行原始代码逻辑。
信号状态更新：处理完信号后，操作系统将清除信号的挂起状态，并允许其他信号继续递交给进程。
这是一个基本的信号发送和处理过程的概述。具体的实现细节和行为取决于操作系统和编程语言的规范。不同的操作系统和编程语言可能有自己的信号处理机制和可调整的参数。因此，在具体的应用环境中，还需要参考相关的文档和规范来了解操作系统的具体行为和限制
挂起的信号是指在信号处理程序执行期间接收到的但还没有被处理的信号。当一个进程正在执行信号处理程序时，如果这个进程收到了其他信号（除了一些特定的硬件相关信号），这些新的信号将会被挂起，即暂时不会被递交给进程。相反，这些挂起的信号会等待当前正在执行的信号处理程序完成后再进行递交。这种机制保证了信号处理程序的一致性和可靠性。