linux中斷數

⑴ linux內核中斷之中斷申請介面

本文基於 RockPI 4A 單板Linux4.4內核介紹中斷申請的常用介面函數。

1、文件

2、定義

說明：

1）、 irq ：要申請的中斷號，可通過 platform_get_irq() 獲取，見「Linux內核中斷之獲取中斷號」。

2）、 handler ：中斷處理函數，發生中斷時，先處理中斷處理函數，然後返回 IRQ_WAKE_THREAD 喚醒中斷處理線程。中斷處理函數盡可能簡單。

中斷處理函數定義： typedef irqreturn_t (*irq_handler_t)(int, void *);

中斷返回值如下：

3）、 thread_fn ：中斷處理線程，該參數可為NULL。類似於中斷處理函數的下半部分。

4）、 irqflags ：中斷類型標志。

定義文件： include/linux/interrupt.h ，內容如下：

5）、 devname ：中斷名稱，可使用 cat /proc/interrupts 命令查看。

6）、 dev_id ：設備ID，該值唯一。

在使用共享中斷時（即設置 IRQF_SHARED ），必須傳入 dev_id ，在中斷處理和釋放函數中都會使用該參數。

註：

1、 request_threaded_irq() 函數可替代 request_irq 加 tasklet 或 workqueue 的方式。

2、對應的中斷釋放函數為： void free_irq(unsigned int, void *) ，需要和中斷申請函數成對出現。

1、文件

2、定義

說明：

1）、 __must_check ：指調用函數一定要處理函數的返回值，否則編譯器會給出警告。

2）、 request_irq() 函數本質上是中斷處理線程 thread_fn 為空的 request_threaded_irq() 函數。

注 ：

對應的中斷釋放函數為： void free_irq(unsigned int, void *) ，需要和中斷申請函數成對出現。

1、文件

2、定義

說明 ：

devm_request_threaded_irq() 本質上還是使用 request_threaded_irq() 函數實現中斷申請。

兩者區別：

1）多了一個 dev 參數；

2）在設備驅動卸載時，中斷會自動釋放；

3）如果想單獨釋放中斷，可使用 void devm_free_irq(struct device *dev, unsigned int irq, void *dev_id) 函數。

1、文件

2、定義

devm_request_irq() 函數本質上是中斷處理線程 thread_fn 為空的 devm_request_threaded_irq() 函數。

1、獲取中斷號

2、申請中斷

3、中斷處理函數

4、中斷處理線程

5、查看中斷

⑵ 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 來觀察軟中斷的運行情況。

⑶ Linux幾種中斷信號的區別：HUP，INT，KILL，TERM，TSTP

Linux的HUP，INT，KILL，TERM，TSTP中斷信號區別為：鍵入不同、對應操作不同、啟用不同。

一、鍵入不同

1、HUP中斷信號：HUP中斷信號是當用戶鍵入<Ctrl+X>時由終端驅動程序發送的信號。

2、INT中斷信號：INT中斷信號是當用戶鍵入<Ctrl+I>時由終端驅動程序發送的信號。

3、KILL中斷信號：KILL中斷信號是當用戶鍵入<Ctrl+Z>時由終端驅動程序發送的信號。

4、TERM中斷信號：TERM中斷信號是當用戶鍵入<Ctrl+>時由終端驅動程序發送的信號。

5、TSTP中斷信號：TSTP中斷信號是當用戶鍵入<Ctrl+T>時由終端驅動程序發送的信號。二、對應操作不同

1、HUP中斷信號：HUP中斷信號的對應操作為讓進程掛起，睡眠。

2、INT中斷信號：INT中斷信號的對應操作為正常關閉所有進程。

3、KILL中斷信號：KILL中斷信號的對應操作為強制關閉所有進程。

4、TERM中斷信號：TERM中斷信號的對應操作為正常的退出進程。

5、TSTP中斷信號：TSTP中斷信號的對應操作為暫時停用進程。

三、啟用不同

1、HUP中斷信號：HUP中斷信號發送後，可以重新被用戶再次輸入恢復啟用進程。

2、INT中斷信號：INT中斷信號發送後，不可以重新被用戶再次輸入恢復啟用進程。

3、KILL中斷信號：KILL中斷信號發送後，不可以重新被用戶再次輸入恢復啟用進程。

4、TERM中斷信號：TERM中斷信號發送後，可以重新被用戶再次輸入啟用進程。

5、TSTP中斷信號：TSTP中斷信號發送後，可以重新被用戶再次輸入繼續使用進程。

⑷ linux系統中的中斷指令是什麼

什麼是中斷
Linux 內核需要對連接到計算機上的所有硬體設備進行管理，毫無疑問這是它的份內事。如果要管理這些設備，首先得和它們互相通信才行，一般有兩種方案可實現這種功能：
輪詢（polling） 讓內核定期對設備的狀態進行查詢，然後做出相應的處理；中斷（interrupt） 讓硬體在需要的時候向內核發出信號（變內核主動為硬體主動）。
第一種方案會讓內核做不少的無用功，因為輪詢總會周期性的重復執行，大量地耗用 CPU 時間，因此效率及其低下，所以一般都是採用第二種方案 。
對於中斷的理解我們先看一個生活中常見的例子:QQ。第一種情況:你正在工作,然後你的好友突然給你發送了一個窗口抖動,打斷你正在進行的工作。第
二種情況:當然你有時候也會每隔 5 分鍾就去檢查一下 QQ
看有沒有好友找你,雖然這很浪費你的時間。在這里,一次窗口抖動就可以被相當於硬體的中斷,而你就相當於 CPU,你的工作就是 CPU
這在執行的進程。而定時查詢就被相當於 CPU 的輪詢。在這里可以看到:同樣作為 CPU 和硬體溝通的方式,中斷是硬體主動的方式,較輪詢(CPU
主動)更有效些,因為我們都不可能一直無聊到每隔幾分鍾就去查一遍好友列表。
CPU
有大量的工作需要處理,更不會做這些大量無用功。當然這只是一般情況下。好了,這里又有了一個問題,每個硬體設備都中斷,那麼如何區分不同硬體呢?不同設
備同時中斷如何知道哪個中斷是來自硬碟、哪個來自網卡呢?這個很容易,不是每個 QQ 號碼都不相同嗎?同樣的,系統上的每個硬體設備都會被分配一個
IRQ 號,通過這個唯一的 IRQ 號就能區別張三和李四了。
從物理學的角度看，中斷是一種電信號，由硬體設備產生，並直接送入中斷控制器（如
8259A）的輸入引腳上，然後再由中斷控制器向處理器發送相應的信號。處理器一經檢測到該信號，便中斷自己當前正在處理的工作，轉而去處理中斷。此後，
處理器會通知 OS 已經產生中斷。這樣，OS
就可以對這個中斷進行適當的處理。不同的設備對應的中斷不同，而每個中斷都通過一個唯一的數字標識，這些值通常被稱為中斷請求線。

⑸ Linux內核中斷之獲取中斷號

Linux內核中可使用 platform_get_irq() 函數獲取 dts 文件中設置的中斷號。

函數原型： int platform_get_irq(struct platform_device *dev, unsigned int num)

定義文件： driversaseplatform.c

中斷號獲取函數 platform_get_irq() 調用流程如下：

rk3399 使用的是 GICv3 ，對應 irq_domain->name 。

文件： drivers/irqchip/irq-gic-v3.c 。

translate() 函數實現如下：

以 RockPI 4A 單板 Debian 系統Linux 4.4內核中的獲取 HDMI 中斷號為例。

1、查找中斷號

從手冊「Rockchip RK3399 TRM V1.3 Part1.pdf」中，可以查到 HDMI_IRQ 中斷號，即55。

2、 dts 配置

文件： arch/arm64/boot/dts/rockchip/rk3399.dtsi

hdmi 使用的是 GIC_SPI 中斷，按照 gic_irq_domain_translate() 函數中處理，需要將中斷號55減去32，得到 dts 中的中斷號23。

註： interrupts = <中斷類型 中斷號 中斷觸發類型 中斷分區(對應哪個CPU cluster，PPI類型中斷特有)>

3、驅動函數

文件： driversgpudrm ockchipdw_hdmi-rockchip.c

此時， irq 返回值為55。

後續會介紹 GIC 和中斷注冊等實現函數。

⑹ 《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的特點和注意事項：

工作隊列的特點和注意事項：

⑺ 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表項。

⑻ linux中斷函數里如何判斷上升下降

中斷服務函數里判斷。根據查詢今日頭條得知，linux中斷函數里在中斷服務函數里判斷上升下降。中斷函數是在發生中斷時間後，主程序自動進入中斷函數運行，運行結束後在退出中斷函數，返回到進入中斷函數之前的運行狀態。

⑼ Linux中斷與定時器

所謂中斷是指CPU在執行程序的過程中，出現了某些突發事件急待處理，CPU必須暫停當前程序的執行，轉去處理突發事件，處理完畢後又返回原程序被中斷的位置繼續執行。根據中斷的來源，中斷可分為內部中斷和外部中斷，內部中斷的中斷源來自CPU內部（軟體中斷指令、溢出、除法錯誤等，例如，操作系統從用戶態切換到內核態需藉助CPU內部的軟體中斷），外部中斷的中斷源來自CPU外部，由外設提出請求。根據中斷是否可以屏蔽，中斷可分為可屏蔽中斷與不可屏蔽中斷（NMI），可屏蔽中斷可以通過設置中斷控制器寄存器等方法被屏蔽，屏蔽後，該中斷不再得到響應，而不可屏蔽中斷不能被屏蔽。
根據中斷入口跳轉方法的不同，中斷可分為向量中斷和非向量中斷。採用向量中斷的CPU通常為不同的中斷分配不同的中斷號，當檢測到某中斷號的中斷到來後，就自動跳轉到與該中斷號對應的地址執行。不同中斷號的中斷有不同的入口地址。非向量中斷的多個中斷共享一個入口地址，進入該入口地址後，再通過軟體判斷中斷標志來識別具體是哪個中斷。也就是說，向量中斷由硬體提供中斷服務程序入口地址，非向量中斷由軟體提供中斷服務程序入口地址。
嵌入式系統以及x86PC中大多包含可編程中斷控制器（PIC），許多MCU內部就集成了PIC。如在80386中，PIC是兩片i8259A晶元的級聯。通過讀寫PIC的寄存器，程序員可以屏蔽/使能某中斷及獲得中斷狀態，前者一般通過中斷MASK寄存器完成，後者一般通過中斷PEND寄存器完成。定時器在硬體上也依賴中斷來實現，典型的嵌入式微處理器內可編程間隔定時器（PIT）的工作原理，它接收一個時鍾輸入，當時鍾脈沖到來時，將目前計數值增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 已經查詢不到後台命令。