程式扎記: [Linux 文章收集] Linux進程狀態(ps stat)之R、S、D、T、Z、X

標籤

2012年8月11日 星期六

[Linux 文章收集] Linux進程狀態(ps stat)之R、S、D、T、Z、X


來源自 這裡
Preface :
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 狀態存在的意義就在於,內核(Kernel) 的某些處理流程是不能被打斷的. 如果響應異步信號,程序的執行流程中就會被插入一段用於處理異步信號的流程(這個插入的流程可能只存在於內核態,也可能延伸到用戶態),於是原有的流程就被中斷了。(參見《linux內核異步中斷淺析》)在進程對某些硬件進行操作時(比如進程調用read系統調用對某個設備文件進行讀操作,而read系統調用最終執行到對應設備驅動的代碼,並與對應的物理設備進行交互),可能需要使用TASK_UNINTERRUPTIBLE狀態對進程進行保護,以避免進程與設備交互的過程被打斷,造成設備陷入不可控的狀態。這種情況下的 TASK_UNINTERRUPTIBLE 狀態總是非常短暫的,通過 ps 命令基本上不可能捕捉到.

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. #include   
  3.   
  4.   
  5. void main()  
  6. {  
  7.     if(fork())  
  8.     {  
  9.         while(1) sleep(100);  
  10.     }  
  11. }  
編譯運行,然後ps一下 :


只要父進程不退出,這個殭屍狀態的子進程就一直存在。那麼如果父進程退出了呢,誰又來給子進程“收屍”?
當進程退出的時候,會將它的所有子進程都託管給別的進程(使之成為別的進程的子進程). 託管給誰呢?可能是退出進程所在進程組的下一個進程(如果存在的話),或者是1號進程。所以每個進程、每時每刻都有父進程存在。除非它是1號進程. 1號進程,pid為1的進程,又稱init進程. linux系統啟動後,第一個被創建的用戶態進程就是init進程. 在這裡它有兩項使命 :
1. 執行系統初始化腳本,創建一系列的進程(它們都是init進程的子孫);
2. 在一個死循環中等待其子進程的退出事件,並調用waitid系統調用來完成 "收屍" 工作

init進程不會被暫停、也不會被殺死(這是由內核來保證的)。它在等待子進程退出的過程中處於TASK_INTERRUPTIBLE狀態,“收屍”過程中則處於TASK_RUNNING狀態.

Linux進程狀態 : X (TASK_DEAD – EXIT_DEAD),退出狀態,進程即將被銷毀
而進程在退出過程中也可能不會保留它的t ask_struct. 比如這個進程是多線程程序中被detach過的進程, 或者父進程通過設置 SIGCHLD 信號的 handler 為 SIG_IGN,顯式的忽略了SIGCHLD 信號.(這是posix的規定,儘管子進程的退出信號可以被設置為SIGCHLD以外的其他信號.) 此時,進程將被置於EXIT_DEAD退出狀態,這意味著接下來的代碼立即就會將該進程徹底釋放。所以EXIT_DEAD狀態是非常短暫的,幾乎不可能通過 ps 命令捕捉到.

進程的初始狀態 :
進程是通過fork系列的系統調用(forkclonevfork)來創建的,內核(或內核模塊)也可以通過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上執行的情況下.

補充說明 :
鳥哥 Linux 私房菜 : 第十七章、程序管理與 SELinux 初探
永遠的 unix : 讀核日記(三)
在linux 中每一個進程都由task_struct 數據結構來定義. task_struct就是我們通常所說的PCB. 她是對進程控制的唯一手段也是最有效的手段...
This message was edited 11 times. Last update was at 11/08/2012 16:29:17

沒有留言:

張貼留言

網誌存檔

關於我自己

我的相片
Where there is a will, there is a way!