我們先來了解一下各種程序狀態：

• TASK_RUNNING：程序當前正在執行，或者正在執行佇列中等待排程。
• TASK_INTERRUPTIBLE：程序處於睡眠狀態，正在等待某些事件發生。程序可以被訊號中斷。接收到訊號或被顯式的喚醒呼叫喚醒之後，程序將轉變為TASK_RUNNING 狀態。
• TASK_UNINTERRUPTIBLE：此程序狀態類似於 TASK_INTERRUPTIBLE，只是它不會處理訊號。中斷處於這種狀態的程序是不合適的，因為它可能正在完成某些重要的任務。 當它所等待的事件發生時，程序將被顯式的喚醒呼叫喚醒。(task_UNINTERRUPTIBLE)狀態不會響應任何訊號，所有Kill -9 pid，會發現程序依然存在
• TASK_STOPPED：程序已中止執行，它沒有執行，並且不能執行。接收到 SIGSTOP 和 SIGTSTP 等訊號時，程序將進入這種狀態。接收到 SIGCONT 訊號之後，程序將再次變得可執行。
• TASK_TRACED：正被除錯程式等其他程序監控時，程序將進入這種狀態。
• EXIT_ZOMBIE：程序已終止，它正等待其父程序收集關於它的一些統計資訊。
• EXIT_DEAD：最終狀態（正如其名）。將程序從系統中刪除時，它將進入此狀態，因為其父程序已經通過 wait4() 或waitpid() 呼叫收集了所有統計資訊。

核心對映

Linux 核心提供了兩種方法將程序置為睡眠狀態。

將程序置為睡眠狀態的普通方法是將程序狀態設定為 TASK_INTERRUPTIBLE

或 TASK_UNINTERRUPTIBLE 並呼叫排程程式的schedule() 函式。這樣會將程序從 CPU 執行佇列中移除。如果程序處於可中斷模式的睡眠狀態（通過將其狀態設定為TASK_INTERRUPTIBLE），那麼可以通過顯式的喚醒呼叫（wakeup_process()）或需要處理的訊號來喚醒它。

但是，如果程序處於非可中斷模式的睡眠狀態（通過將其狀態設定為 TASK_UNINTERRUPTIBLE），那麼只能通過顯式的喚醒呼叫將其喚醒。除非萬不得已，否則我們建議您將程序置為可中斷睡眠模式，而不是不可中斷睡眠模式（比如說在裝置 I/O 期間，處理訊號非常困難時）。

當處於可中斷睡眠模式的任務接收到訊號時，它需要處理該訊號（除非它已被屏弊），離開之前正在處理的任務（此處需要清除程式碼），並將 -EINTR

返回給使用者空間。再一次，檢查這些返回程式碼和採取適當操作的工作將由程式設計師完成。因此，懶惰的程式設計師可能比較喜歡將程序置為不可中斷模式的睡眠狀態，因為訊號不會喚醒這類任務。但需要注意的一種情況是，對不可中斷睡眠模式的程序的喚醒呼叫可能會由於某些原因不會發生，這會使程序無法被終止，從而最終引發問題，因為惟一的解決方法就是重啟系統。一方面，您需要考慮一些細節，因為不這樣做會在核心端和使用者端引入 bug。另一方面，您可能會生成永遠不會停止的程序（被阻塞且無法終止的程序）。

現在，我們在核心中實現了一種新的睡眠方法！Linux Kernel 2.6.25 引入了一種新的程序睡眠狀態，TASK_KILLABLE：當程序處於這種可以終止的新睡眠狀態中，它的執行原理類似於TASK_UNINTERRUPTIBLE，只不過可以響應致命訊號，kill -9

一個程序在呼叫exit命令結束自己的生命的時候，其實它並沒有真正的被銷燬，而是留下一個稱為殭屍程序（Zombie）的資料結構（系統呼叫 exit，它的作用是使程序退出，但也僅僅限於將一個正常的程序變成一個殭屍程序，並不能將其完全銷燬）。

　 　在Linux程序的狀態中，殭屍程序是非常特殊的一種，它已經放棄了幾乎所有記憶體空間，沒有任何可執行程式碼，也不能被排程，僅僅在程序列表中保留一個位 置，記載該程序的退出狀態等資訊供其他程序收集，除此之外，殭屍程序不再佔有任何記憶體空間。它需要它的父程序來為它收屍，如果他的父程序沒安裝 SIGCHLD訊號處理函式呼叫wait或waitpid()等待子程序結束，又沒有顯式忽略該訊號，那麼它就一直保持殭屍狀態，如果這時父程序結束了， 那麼init程序自動會接手這個子程序，為它收屍，它還是能被清除的。但是如果如果父程序是一個迴圈，不會結束，那麼子程序就會一直保持殭屍狀態，這就是 為什麼系統中有時會有很多的殭屍程序。

在UNIX 系統中,一個程序結束了,但是他的父程序沒有等待(呼叫wait / waitpid)他, 那麼他將變成一個殭屍程序.  在fork()/execve()過程中，假設子程序結束時父程序仍存在，而父程序fork()之前既沒安裝SIGCHLD訊號處理函式呼叫 waitpid()等待子程序結束，又沒有顯式忽略該訊號，則子程序成為殭屍程序。

因此，一個殭屍程序產生的過程是：父程序呼叫fork建立子程序後，子程序執行直至其終止，它立即從記憶體中移除，但程序描述符仍然保留在記憶體中（程序描述符佔有極少的記憶體空間）。子程序的狀態變成EXIT_ZOMBIE，並且向父程序傳送SIGCHLD 訊號，父程序此時應該呼叫 wait() 系 統呼叫來獲取子程序的退出狀態以及其它的資訊。在 wait 呼叫之後，殭屍程序就完全從記憶體中移除。因此一個殭屍存在於其終止到父程序呼叫 wait 等函式這個時間的間隙，一般很快就消失，但如果程式設計不合理，父程序從不呼叫 wait 等系統呼叫來收集殭屍程序，那麼這些程序會一直存在記憶體中。

怎樣來清除殭屍程序：

　 　1.改寫父程序，在子程序死後要為它收屍。具體做法是接管SIGCHLD訊號。子程序死後，會發送SIGCHLD訊號給父程序，父程序收到此訊號後，執 行waitpid()函式為子程序收屍。這是基於這樣的原理：就算父程序沒有呼叫wait，核心也會向它傳送SIGCHLD訊息，儘管對的預設處理是忽 略，如果想響應這個訊息，可以設定一個處理函式。

　　2.把父程序殺掉。父程序死後，殭屍程序成為"孤兒程序"，過繼給1號程序init，init始終會負責清理殭屍程序．它產生的所有殭屍程序也跟著消失。

The system load data is collected by the calc_load( ) function, which is invoked by update_times( ). This activity is therefore performed in the TIMER_BH bottom half. calc_load( ) counts the number of processes in the TASK_RUNNING or TASK_UNINTERRUPTIBLE state and uses this number to update the CPU usage statistics. 上面清楚的說明，Linux在計算CPU負載的時候，TASK_RUNNING和TASK_UNINTERRUPTIBLE兩種狀態的程序都會被統計

Linux是一個多使用者，多工的系統，可以同時執行多個使用者的多個程式，就必然會產生很多的程序，而每個程序會有不同的狀態。

Linux程序狀態：R (TASK_RUNNING)，可執行狀態。

只有在該狀態的程序才可能在CPU上執行。而同一時刻可能有多個程序處於可執行狀態，這些程序的task_struct結構（程序控制塊）被放入對應CPU的可執行佇列中（一個程序最多隻能出現在一個CPU的可執行佇列中）。程序排程器的任務就是從各個CPU的可執行佇列中分別選擇一個程序在該CPU上執行。

很多作業系統教科書將正在CPU上執行的程序定義為RUNNING狀態、而將可執行但是尚未被排程執行的程序定義為READY狀態，這兩種狀態在linux下統一為 TASK_RUNNING狀態。

Linux程序狀態：S (TASK_INTERRUPTIBLE)，可中斷的睡眠狀態。

處於這個狀態的程序因為等待某某事件的發生（比如等待socket連線、等待訊號量），而被掛起。這些程序的task_struct結構被放入對應事件的等待佇列中。當這些事件發生時（由外部中斷觸發、或由其他程序觸發），對應的等待佇列中的一個或多個程序將被喚醒。

通過ps命令我們會看到，一般情況下，程序列表中的絕大多數程序都處於TASK_INTERRUPTIBLE狀態（除非機器的負載很高）。畢竟CPU就這麼一兩個，程序動輒幾十上百個，如果不是絕大多數程序都在睡眠，CPU又怎麼響應得過來。

Linux程序狀態：D (TASK_UNINTERRUPTIBLE)，不可中斷的睡眠狀態。

與TASK_INTERRUPTIBLE狀態類似，程序處於睡眠狀態，但是此刻程序是不可中斷的。不可中斷，指的並不是CPU不響應外部硬體的中斷，而是指程序不響應非同步訊號。
絕大多數情況下，程序處在睡眠狀態時，總是應該能夠響應非同步訊號的。否則你將驚奇的發現，kill -9竟然殺不死一個正在睡眠的程序了！於是我們也很好理解，為什麼ps命令看到的程序幾乎不會出現TASK_UNINTERRUPTIBLE狀態，而總是TASK_INTERRUPTIBLE狀態。

而TASK_UNINTERRUPTIBLE狀態存在的意義就在於，核心的某些處理流程是不能被打斷的。如果響應非同步訊號，程式的執行流程中就會被插入一段用於處理非同步訊號的流程（這個插入的流程可能只存在於核心態，也可能延伸到使用者態），於是原有的流程就被中斷了。（參見《linux核心非同步中斷淺析》）
在程序對某些硬體進行操作時（比如程序呼叫read系統呼叫對某個裝置檔案進行讀操作，而read系統呼叫最終執行到對應裝置驅動的程式碼，並與對應的物理裝置進行互動），可能需要使用TASK_UNINTERRUPTIBLE狀態對程序進行保護，以避免程序與裝置互動的過程被打斷，造成裝置陷入不可控的狀態。這種情況下的TASK_UNINTERRUPTIBLE狀態總是非常短暫的，通過ps命令基本上不可能捕捉到。

linux系統中也存在容易捕捉的TASK_UNINTERRUPTIBLE狀態。執行vfork系統呼叫後，父程序將進入TASK_UNINTERRUPTIBLE狀態，直到子程序呼叫exit或exec（參見《神奇的vfork》）。
通過下面的程式碼就能得到處於TASK_UNINTERRUPTIBLE狀態的程序：

1. #include
2. void main() {
3. if (!vfork()) sleep(100);
4. }

編譯執行，然後ps一下：

1. [email protected]:~/test$ ps -ax | grep a\.out
2. 4371 pts/0    D+     0:00 ./a.out
3. 4372 pts/0    S+     0:00 ./a.out
4. 4374 pts/1    S+     0:00 grep a.out

然後我們可以試驗一下TASK_UNINTERRUPTIBLE狀態的威力。不管kill還是kill -9，這個TASK_UNINTERRUPTIBLE狀態的父程序依然屹立不倒。

Linux程序狀態：T (TASK_STOPPED or TASK_TRACED)，暫停狀態或跟蹤狀態。

向程序傳送一個SIGSTOP訊號，它就會因響應該訊號而進入TASK_STOPPED狀態（除非該程序本身處於TASK_UNINTERRUPTIBLE狀態而不響應訊號）。（SIGSTOP與SIGKILL訊號一樣，是非常強制的。不允許使用者程序通過signal系列的系統呼叫重新設定對應的訊號處理函式。）
向程序傳送一個SIGCONT訊號，可以讓其從TASK_STOPPED狀態恢復到TASK_RUNNING狀態。

當程序正在被跟蹤時，它處於TASK_TRACED這個特殊的狀態。“正在被跟蹤”指的是程序暫停下來，等待跟蹤它的程序對它進行操作。比如在gdb中對被跟蹤的程序下一個斷點，程序在斷點處停下來的時候就處於TASK_TRACED狀態。而在其他時候，被跟蹤的程序還是處於前面提到的那些狀態。

對於程序本身來說，TASK_STOPPED和TASK_TRACED狀態很類似，都是表示程序暫停下來。
而TASK_TRACED狀態相當於在TASK_STOPPED之上多了一層保護，處於TASK_TRACED狀態的程序不能響應SIGCONT訊號而被喚醒。只能等到除錯程序通過ptrace系統呼叫執行PTRACE_CONT、PTRACE_DETACH等操作（通過ptrace系統呼叫的引數指定操作），或除錯程序退出，被除錯的程序才能恢復TASK_RUNNING狀態。

Linux程序狀態：Z (TASK_DEAD – EXIT_ZOMBIE)，退出狀態，程序成為殭屍程序。

程序在退出的過程中，處於TASK_DEAD狀態。

在這個退出過程中，程序佔有的所有資源將被回收，除了task_struct結構（以及少數資源）以外。於是程序就只剩下task_struct這麼個空殼，故稱為殭屍。
之所以保留task_struct，是因為task_struct裡面儲存了程序的退出碼、以及一些統計資訊。而其父程序很可能會關心這些資訊。比如在shell中，$?變數就儲存了最後一個退出的前臺程序的退出碼，而這個退出碼往往被作為if語句的判斷條件。
當然，核心也可以將這些資訊儲存在別的地方，而將task_struct結構釋放掉，以節省一些空間。但是使用task_struct結構更為方便，因為在核心中已經建立了從pid到task_struct查詢關係，還有程序間的父子關係。釋放掉task_struct，則需要建立一些新的資料結構，以便讓父程序找到它的子程序的退出資訊。

父程序可以通過wait系列的系統呼叫（如wait4、waitid）來等待某個或某些子程序的退出，並獲取它的退出資訊。然後wait系列的系統呼叫會順便將子程序的屍體（task_struct）也釋放掉。
子程序在退出的過程中，核心會給其父程序傳送一個訊號，通知父程序來“收屍”。這個訊號預設是SIGCHLD，但是在通過clone系統呼叫建立子程序時，可以設定這個訊號。

通過下面的程式碼能夠製造一個EXIT_ZOMBIE狀態的程序：

1. #include
2. void main() {
3. if (fork())
4. while(1) sleep(100);
5. }

編譯執行，然後ps一下：

1. [email protected]:~/test$ ps -ax | grep a\.out
2. 10410 pts/0    S+     0:00 ./a.out
3. 10411 pts/0    Z+     0:00 [a.out]
4. 10413 pts/1    S+     0:00 grep a.out

只要父程序不退出，這個殭屍狀態的子程序就一直存在。那麼如果父程序退出了呢，誰又來給子程序“收屍”？
當程序退出的時候，會將它的所有子程序都託管給別的程序（使之成為別的程序的子程序）。託管給誰呢？可能是退出程序所在程序組的下一個程序（如果存在的話），或者是1號程序。所以每個程序、每時每刻都有父程序存在。除非它是1號程序。

1號程序，pid為1的程序，又稱init程序。
linux系統啟動後，第一個被建立的使用者態程序就是init程序。它有兩項使命：
1、執行系統初始化指令碼，建立一系列的程序（它們都是init程序的子孫）；
2、在一個死迴圈中等待其子程序的退出事件，並呼叫waitid系統呼叫來完成“收屍”工作；
init程序不會被暫停、也不會被殺死（這是由核心來保證的）。它在等待子程序退出的過程中處於TASK_INTERRUPTIBLE狀態，“收屍”過程中則處於TASK_RUNNING狀態。

Linux程序狀態：X (TASK_DEAD – EXIT_DEAD)，退出狀態，程序即將被銷燬。

而程序在退出過程中也可能不會保留它的task_struct。比如這個程序是多執行緒程式中被detach過的程序（程序？執行緒？參見《linux執行緒淺析》）。或者父程序通過設定SIGCHLD訊號的handler為SIG_IGN，顯式的忽略了SIGCHLD訊號。（這是posix的規定，儘管子程序的退出訊號可以被設定為SIGCHLD以外的其他訊號。）
此時，程序將被置於EXIT_DEAD退出狀態，這意味著接下來的程式碼立即就會將該程序徹底釋放。所以EXIT_DEAD狀態是非常短暫的，幾乎不可能通過ps命令捕捉到。

程序的初始狀態

程序是通過fork系列的系統呼叫（fork、clone、vfork）來建立的，核心（或核心模組）也可以通過kernel_thread函式建立核心程序。這些建立子程序的函式本質上都完成了相同的功能——將呼叫程序複製一份，得到子程序。（可以通過選項引數來決定各種資源是共享、還是私有。）
那麼既然呼叫程序處於TASK_RUNNING狀態（否則，它若不是正在執行，又怎麼進行呼叫？），則子程序預設也處於TASK_RUNNING狀態。
另外，在系統呼叫呼叫clone和核心函式kernel_thread也接受CLONE_STOPPED選項，從而將子程序的初始狀態置為 TASK_STOPPED。

程序狀態變遷

程序自建立以後，狀態可能發生一系列的變化，直到程序退出。而儘管程序狀態有好幾種，但是程序狀態的變遷卻只有兩個方向——從TASK_RUNNING狀態變為非TASK_RUNNING狀態、或者從非TASK_RUNNING狀態變為TASK_RUNNING狀態。
也就是說，如果給一個TASK_INTERRUPTIBLE狀態的程序傳送SIGKILL訊號，這個程序將先被喚醒（進入TASK_RUNNING狀態），然後再響應SIGKILL訊號而退出（變為TASK_DEAD狀態）。並不會從TASK_INTERRUPTIBLE狀態直接退出。

程序從非TASK_RUNNING狀態變為TASK_RUNNING狀態，是由別的程序（也可能是中斷處理程式）執行喚醒操作來實現的。執行喚醒的程序設定被喚醒程序的狀態為TASK_RUNNING，然後將其task_struct結構加入到某個CPU的可執行佇列中。於是被喚醒的程序將有機會被排程執行。

而程序從TASK_RUNNING狀態變為非TASK_RUNNING狀態，則有兩種途徑：
1、響應訊號而進入TASK_STOPED狀態、或TASK_DEAD狀態；
2、執行系統呼叫主動進入TASK_INTERRUPTIBLE狀態（如nanosleep系統呼叫）、或TASK_DEAD狀態（如exit系統呼叫）；或由於執行系統呼叫需要的資源得不到滿足，而進入TASK_INTERRUPTIBLE狀態或TASK_UNINTERRUPTIBLE狀態（如select系統呼叫）。
顯然，這兩種情況都只能發生在程序正在CPU上執行的情況下。

核心模組程式碼：
—————-killd.c—————-
#include #include #include //for_each_process
MODULE_LICENSE(“BSD”);
static int pid = -1;
module_param(pid, int, S_IRUGO);
static int killd_init(void)
{
struct task_struct * p;
printk(KERN_ALERT “killd: force D status process to death\n”);
printk(KERN_ALERT “killd: pid=%d\n”, pid);
//read_lock(&tasklist_lock);
for_each_process(p){
if(p->pid == pid){
printk(“killd: found\n”);
set_task_state(p, TASK_STOPPED);
printk(KERN_ALERT “killd: aha, dead already\n”);
return 0;
}
}
printk(“not found”);
//read_unlock(&tasklist_lock);
return 0;
}
static void killd_exit(void)
{
printk(KERN_ALERT “killd: bye\n”);
}
module_init(killd_init);
module_exit(killd_exit);
—–Makefile————
obj-m := killd.o
編譯模組
make -C yourkerneltree M=`pwd` modules
插入模組的時候提供D狀態的程序號，就可以將其轉換為stopped狀態，使用普通kill就可以殺死。
./insmod ./killd.ko pid=1234

ps -uax程序狀態符號意義（man ps中PROCESS STATE CODES章節copy過來）：

               D    uninterruptible sleep (usually IO)
               R    running or runnable (on run queue)
               S    interruptible sleep (waiting for an event to complete)
               T    stopped, either by a job control signal or because it is being traced
               W    paging (not valid since the 2.6.xx kernel)
               X    dead (should never be seen)
               Z    defunct ("zombie") process, terminated but not reaped by its parent

       For BSD formats and when the stat keyword is used, additional characters may be displayed:

               <    high-priority (not nice to other users)
               N    low-priority (nice to other users)
               L    has pages locked into memory (for real-time and custom IO)
               s    is a session leader
               l    is multi-threaded (using CLONE_THREAD, like NPTL pthreads do)
               +    is in the foreground process group