linux进程中断

1. 4-5 linux 中断进程 --- kill （kill -2 实验）

1、信号：传递给 Liunx 的事件发生通知机制。

2、kill -l：显示所有信号。一共有62个信号（没有32、33）。

3、常用的信号有：

kill -2 PID —— 正常中断进程（Ctrl + C 一样）。程序在结束之前,能够保存相关数据,然后再退出。

kill -9 PID —— 强制杀死一个进程。

kill -15 PID —— 正常方式终止一个程序。中断进程时应首先用 -15，以便于其能够预先清理临时文件和释放资源。-9 作为最后手段，应对那些失控的进程。

--------------------------------------------------------------------------------

1）、kill -2 中断后台运行的进程。

红色下划线：sleep 10000 & —— 后台运行延时 10000 秒的命令，进程 ID 为1516。

ps -j —— 以作业格式列出进程信息，可以看到 1516 sleep 命令的进程。

（PID：进程 ID、PGID：线程组 ID、SID：会话 ID、TTY：进程运行的终端，标识那个终端控制。（pts远程终端、tty系统终端）、TIME：进程运行的时间 和 CMD：命令的名称和参数）。

jobs -l —— 列出后台运行的命令，可以看到 1516 sleep 命令正在后台运行。

黄色下划线：kill -2 1516 —— 中断1516 进程。执行成功后，按 Enter 回车系统会给出提示Interrupt 提示（中断进程）。

蓝色方框：ps -j 已查询不到 1516 sleep 的进程。jobs -l 也没有后台运行的命令。

2）、kill -2 配合 fg 查看中断挂起的进程。

红色下划线：前台执行 sleep 10000 （延时10000秒）后 ctrl + z 挂起。

黄色下划线：ps -j 查看进程，可以看到 1344 sleep 进程。jobs -l 查看后台进程 1344 的状态是stopped 暂停状态。

蓝色下划线：kill -2 1344 中断 1344 进程。

绿色下划线：ps -j 查看进程，仍有 1344 sleep 进程。jobs -l 查看后台进程 1344 的状态是stopped 暂停状态。

暂时这样看，好像 kill -2 并没有起到中断进程的作用。

然而，用 fg 把后台的命令调至前台运行时可以发现 1344 sleep 已经被中断。

红色下划线：fg 把已经执行了 kill -2， 状态为 stopped 的1344 sleep命令调至前台执行。系统也反馈已经调至前台执行。（此时，实际上已经执行了 kill -2 中断了进程）

黄色方框：ps -j 已经没有了 1344 sleep 的进程。

蓝色方框：jobs -l 后台也没有指令。

3）、kill -2 配合 bg 查看中断挂起的进程。

通过上面的思路，kill -2 配合 bg 实验看看效果。同样的首先挂起一个命令，状态为 stopped 暂停。然后用 bg 命令恢复执行。

前面的步骤都是一样，挂起一个命令。通过 ps 和 jobs 查看进程和后台确认有 1379 的进程，状态为 stopped 暂停。然后执行 kill-2 中断进程，再次通过ps 和 jobs 查看进程和后台命令。确认状态为 stopped  1379 的进程仍然存在。

此时，用 bg 恢复运行挂起的命令，系统提示 sleep 命令已恢复在后台运行。然而通过 ps -j 查看进程会发现 sleep 已经被中断。jobs -l 查看后台也没有了运行的 sleep 命令了。

从实验上看：

1、后台命令运行时（Running），执行 kill -2 可以中断进程。

2、挂起命令，处于暂停状态时（Stopped），执行 kill -2 后通过 ps 还可以查询到进程， jobs还可以查询到后台命令，状态仍然是 Stopped 暂停状态。实际上，用 fg 把暂停的后台进程调至前台运行时，系统反馈 sleep 命令调至前台运行。而再用 ps 查询不到进程，已经中断了进程。用 jobs 已经查询不到后台命令。

3、挂起命令，处于暂停状态时（Stopped），执行 kill -2 后通过 ps 还可以查询到进程， jobs还可以查询到后台命令，状态仍然是 Stopped 暂停状态。用 bg 把暂停的后台命令恢复运行时，系统反馈 sleep 命令在后台运行。再用 ps 查询进程已经中断，用 jobs 已经查询不到后台命令。

2. linux进程的几种状态

Linux中进程分类

①交互进程：由一个shell启动的进程，交互进程既可以在前台运行，也可以在后台运行。

②批处理进程：这种进程和终端没有联系，是一个进程序列。

③监控进程：也称守护进程，是一个在后台运行且不受任何终端控制的特殊进程，用于执行特定的系统任务。

进程的状态

①可运行状态：此时进程正在运行或者正在运行队列中等待准备运行。

②等待状态：此时进程在等待一个事件的发生或某种系统资源。在Linux系统中等待状态又细分为两种等待状态：可中断的等待状态和不可中断的等待状态。

③暂停状态：处于暂停状态的进程被暂停运行。

④僵死状态：每个进程在运行结束后都会处于僵死状态，等待父进程调用进而释放系统资源，处于该状态的进程已经运行结束，但是它的父进程还没有释放其系统资源。

3. linux停止进程

在linux系统中停止进程需要以下三个步骤，下面具体介绍以下：
1、打开进程id，用ps命令查找进程，使用-e选项。通过less的方式输出

今天的分享就是这些，希望能帮助大家。
本文章基于thinkpadE15品牌、centos7系统撰写的。

4. Linux中断补充

在系统结构中，CPU工作的模式有两种，一种是中断，由各种设备发起；一种是轮询，由CPU主动发起。
中断IRQ:
中断允许让设备（如键盘，串口卡，并口等设备）表明它们需要CPU。一旦CPU接收了中断请求，CPU就会暂时停止执行正在运行的程序，并且调用一个称为中断处理器或中断服务程序（interrupt service routine）的特定程序。CPU处理完中断后，就会恢复执行之前被中断的程序。
中断分类：
硬中断+软中断
硬中断：
①非屏蔽中断：不能被屏蔽，硬件发生的错误：内存错误，风扇故障，温度传感器故障等。
②可屏蔽中断：可被CPU忽略或延迟处理。当缓存控制器的外部针脚被触发的时候就会产生这种类型的中断，而中断屏蔽寄存器就会将这样的中断屏蔽掉。我们可以将一个比特位设置为0，来禁用在此针脚触发的中断。
软中断：
是软件实现的中断,也就是程序运行时其他程序对它的中断;而硬中断是硬件实现的中断,是程序运行时设备对它的中断。

CPU之间的中断处理（IPI）
处理器间中断允许一个CPU向系统其他的CPU发送中断信号，处理器间中断（IPI）不是通过IRQ线传输的，而是作为信号直接放在连接所有CPU本地APIC的总线上。
CALL_FUNCTION_VECTOR （向量0xfb）

发往所有的CPU，但不包括发送者，强制这些CPU运行发送者传递过来的函数，相应的中断处理程序叫做call_function_interrupt()，例如，地址存放在群居变量call_data中来传递的函数，可能强制其他所有的CPU都停止，也可能强制它们设置内存类型范围寄存器的内容。通常，这种中断发往所有的CPU，但通过smp_call_function()执行调用函数的CPU除外。

RESCHEDULE_VECTOR （向量0xfc）

当一个CPU接收这种类型的中断时，相应的处理程序限定自己来应答中断，当从中断返回时，所有的重新调度都自动运行。

INVALIDATE_TLB_VECTOR （向量0xfd）

发往所有的CPU，但不包括发送者，强制它们的转换后援缓冲器TLB变为无效。相应的处理程序刷新处理器的某些TLB表项。

5. linux 进程终止有哪几种方式

《UNIX环境高级编程》的第七章的7.3《进程终止》说了八种情况：
正常终止五种：
1.从main返回。
2.调用exit。
3.调用_exit或_Exit。
4.最后一个线程从其启动例程返回。
5.最后一个线程调用pthread_exit。
三种异常终止：
6.调用abort()。
7.接到一个信号并终止。
8.最后一个线程对取消请求作出响应。

6. Linux下如何强制中断一个程序的执行（利用按键，而不是kill命令）

Linux下强制中断一个程序的执行，利用按键，而不是kill命令。

可尝试以下方法：

1.CTRL + c中断。

2.CTRL + z暂停放到后台。

3.CTRL + d保存退出。

7. Linux-怎么理解软中断

中断是系统用来响应硬件设备请求的一种机制，它会打断进程的正常调度和执行，然后调用内核中的中断处理程序来响应设备的请求。

你可能要问了，为什么要有中断呢？我可以举个生活中的例子，让感受一下中断的魅力。

比如你订了一份外卖，但是不确定外卖什么时候送到，也没有别的方法了解外卖的进度，但是，配送员送外卖是不等人的，到了你这儿没人取的话，就直接走人了，所以你只能苦苦等着，时不时去门口看看外卖送到没，而不能干其他事情。

不过呢，如果在订外卖的时候，你就跟配送员约定好，让他送到后给你打个电话，那你就不用苦苦等待了，就可以去忙别的事情，直到电话一响，接电话、取外卖就可以了。

这里的“打电话”，其实就是一个中断。没接到电话的时候，你可以做其他的事情；只有接到了电话（也就是发生中断），你才要进行另一个动作：取外卖。

这个例子你就可以发现， 中断其实是一种异步的事件处理机制，可以提高系统的并发处理能力。

由于中断处理程序会打断其他进程的运行，所以， 为了减少对正常进程运行调度的影响，中断处理程序就需要尽可能快地运行。 如果中断本身要做的事情不多，那么处理起来也不会有太大问题；但如果中断要处理的事情很多，中断服务程序就有可能要运行很长时间。

特别是，中断处理程序在响应中断时，还会临时关闭中断。这就会导致上一次中断处理完成之前，其他中断都不能响应，也就是说中断有可能会丢失。

那么还是以取外卖为例。假如你订了 2 份外卖，一份主食和一份饮料，并且是由 2 个不同的配送员来配送。这次你不用时时等待着，两份外卖都约定了电话取外卖的方式。但是，问题又来了。

当第一份外卖送到时，配送员给你打了个长长的电话，商量发票的处理方式。与此同时，第二个配送员也到了，也想给你打电话。

但是很明显，因为电话占线（也就是关闭了中断响应），第二个配送员的电话是打不通的。所以，第二个配送员很可能试几次后就走掉了（也就是丢失了一次中断）。

如果你弄清楚了“取外卖”的模式，那对系统的中断机制就很容易理解了。事实上，为了解决中断处理程序执行过长和中断丢失的问题，Linux 将中断处理过程分成了两个阶段，也就是 上半部和下半部：

比如说前面取外卖的例子，上半部就是你接听电话，告诉配送员你已经知道了，其他事儿见面再说，然后电话就可以挂断了；下半部才是取外卖的动作，以及见面后商量发票处理的动作。

这样，第一个配送员不会占用你太多时间，当第二个配送员过来时，照样能正常打通你的电话。

除了取外卖，我再举个最常见的网卡接收数据包的例子，让你更好地理解。

网卡接收到数据包后，会通过 硬件中断 的方式，通知内核有新的数据到了。这时，内核就应该调用中断处理程序来响应它。你可以自己先想一下，这种情况下的上半部和下半部分别负责什么工作呢？

对上半部来说，既然是快速处理，其实就是要把网卡的数据读到内存中，然后更新一下硬件寄存器的状态（表示数据已经读好了），最后再发送一个 软中断 信号，通知下半部做进一步的处理。

而下半部被软中断信号唤醒后，需要从内存中找到网络数据，再按照网络协议栈，对数据进行逐层解析和处理，直到把它送给应用程序。

所以，这两个阶段你也可以这样理解：

实际上，上半部会打断 CPU 正在执行的任务，然后立即执行中断处理程序。而下半部以内核线程的方式执行，并且每个 CPU 都对应一个软中断内核线程，名字为 “ksoftirqd/CPU 编号”，比如说， 0 号 CPU 对应的软中断内核线程的名字就是 ksoftirqd/0。

不过要注意的是，软中断不只包括了刚刚所讲的硬件设备中断处理程序的下半部，一些内核自定义的事件也属于软中断，比如内核调度和 RCU 锁（Read-Copy Update 的缩写，RCU 是 Linux 内核中最常用的锁之一）等。

不知道你还记不记得，前面提到过的 proc 文件系统。它是一种内核空间和用户空间进行通信的机制，可以用来查看内核的数据结构，或者用来动态修改内核的配置。其中：

运行下面的命令，查看 /proc/softirqs 文件的内容，你就可以看到各种类型软中断在不同 CPU 上的累积运行次数：

在查看 /proc/softirqs 文件内容时，你要特别注意以下这两点。
第一，要注意软中断的类型，也就是这个界面中第一列的内容。从第一列你可以看到，软中断包括了 10 个类别，分别对应不同的工作类型。比如 NET_RX 表示网络接收中断，而 NET_TX 表示网络发送中断。

第二，要注意同一种软中断在不同 CPU 上的分布情况，也就是同一行的内容。正常情况下，同一种中断在不同 CPU 上的累积次数应该差不多。比如这个界面中，NET_RX 在 CPU0 和 CPU1 上的中断次数基本是同一个数量级，相差不大。

不过你可能发现，TASKLET 在不同 CPU 上的分布并不均匀。TASKLET 是最常用的软中断实现机制，每个 TASKLET 只运行一次就会结束 ，并且只在调用它的函数所在的 CPU 上运行。

因此，使用 TASKLET 特别简便，当然也会存在一些问题，比如说由于只在一个 CPU 上运行导致的调度不均衡，再比如因为不能在多个 CPU 上并行运行带来了性能限制。

另外，刚刚提到过，软中断实际上是以内核线程的方式运行的，每个 CPU 都对应一个软中断内核线程，这个软中断内核线程就叫做 ksoftirqd/CPU 编号。那要怎么查看这些线程的运行状况呢？

其实用 ps 命令就可以做到，比如执行下面的指令：

注意，这些线程的名字外面都有中括号，这说明 ps 无法获取它们的命令行参数（cmline）。一般来说，ps 的输出中，名字括在中括号里的，一般都是内核线程。

Linux 中的中断处理程序分为上半部和下半部：
上半部对应硬件中断，用来快速处理中断。
下半部对应软中断，用来异步处理上半部未完成的工作。

Linux 中的软中断包括网络收发、定时、调度、RCU 锁等各种类型，可以通过查看 /proc/softirqs 来观察软中断的运行情况。

8. 《Linux设备驱动程序》（十六）-中断处理

设备与处理器之间的工作通常来说是异步，设备数据要传递给处理器通常来说有以下几种方法：轮询、等待和中断。

让CPU进行轮询等待总是不能让人满意，所以通常都采用中断的形式，让设备来通知CPU读取数据。

2.6内核的函数参数与现在的参数有所区别，这里都主要介绍概念，具体实现方法需要结合具体的内核版本。

request_irq函数申请中断，返回0表示申请成功，其他返回值表示申请失败，其具体参数解释如下：

flags 掩码可以使用以下几个：

快速和慢速处理例程 ：现代内核中基本没有这两个概念了，使用SA_INTERRUPT位后，当中断被执行时，当前处理器的其他中断都将被禁止。通常不要使用SA_INTERRUPT标志位，除非自己明确知道会发生什么。

共享中断 ：使用共享中断时，一方面要使用SA_SHIRQ位，另一个是request_irq中的dev_id必须是唯一的，不能为NULL。这个限制的原因是：内核为每个中断维护了一个共享处理例程的列表，例程中的dev_id各不相同，就像设备签名。如果dev_id相同，在卸载的时候引起混淆（卸载了另一个中断），当中断到达时会产生内核OOP消息。

共享中断需要满足以下一个条件才能申请成功：

当不需要使用该中断时，需要使用free_irq释放中断。

通常我们会在模块加载的时候申请安装中断处理例程，但书中建议：在设备第一次打开的时候安装，在设备最后一次关闭的时候卸载。

如果要查看中断触发的次数，可以查看 /proc/interrupts 和 /proc/stat。

书中讲述了如何自动检测中断号，在嵌入式开发中通常都是查看原理图和datasheet来直接确定。

自动检测的原理如下：驱动程序通知设备产生中断，然后查看哪些中断信号线被触发了。Linux提供了以下方法来进行探测：

探测工作耗时较长，建议在模块加载的时候做。

中断处理函数和普通函数其实差不多，唯一的区别是其运行的中断上下文中，在这个上下文中有以下注意事项：

中断处理函数典型用法如下：

中断处理函数的参数和返回值含义如下：

返回值主要有两个：IRQ_NONE和IRQ_HANDLED。

对于中断我们是可以进行开启和关闭的，Linux中提供了以下函数操作单个中断的开关：

该方法可以在所有处理器上禁止或启用中断。

需要注意的是：

如果要关闭当前处理器上所有的中断，则可以调用以下方法：

local_irq_save 会将中断状态保持到flags中，然后禁用处理器上的中断；如果明确知道中断没有在其他地方被禁用，则可以使用local_irq_disable，否则请使用local_irq_save。

locat_irq_restore 会根据上面获取到flags来恢复中断；local_irq_enable 会无条件打开所有中断。

在中断中需要做一些工作，如果工作内容太多，必然导致中断处理所需的时间过长；而中断处理又要求能够尽快完成，这样才不会影响正常的系统调度，这两个之间就产生了矛盾。

现在很多操作系统将中断分为两个部分来处理上面的矛盾：顶半部和底半部。

顶半部就是我们用request_irq来注册的中断处理函数，这个函数要求能够尽快结束，同时在其中调度底半部，让底半部在之后来进行后续的耗时工作。

顶半部就不再说明了，就是上面的中断处理函数，只是要求能够尽快处理完成并返回，不要处理耗时工作。

底半部通常使用tasklet或者工作队列来实现。

tasklet的特点和注意事项：

工作队列的特点和注意事项：