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

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