Linux進程狀態解析之T、Z、X
上面一篇文章中我們介紹了Linux進程的R、S、D三種狀態，這里接著上面的文章介紹另外三個狀態。
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狀態的進程：
- #include
- void main() {
- if (fork())
- while(1) sleep(100);
- }
編譯運行，然后ps一下：
- kouu@kouu-one:~/test$ ps -ax | grep a\.out
- 10410 pts/0 S+ 0:00 ./a.out
- 10411 pts/0 Z+ 0:00 [a.out]
- 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上執行的情況下。
【編輯推薦】
