之前在查詢linux系統init流程的相關資料時總是能夠看到inittab的身影，但是在我的ubuntu上是沒有這個檔案的，到後來才知道採用 upstart方式的ubuntu上是沒有inittab這個檔案的。在舊式的system v initialization中，/etc/inittab可是個相當重要的檔案。init程序啟動後第一時間找的就是它！inittab負責初始化系統，設定系統runlevel及進 入各runlevel對應要執行的命令。假設當前inittab中設定的預設runlevel是5，則init會執行/etc/init.d/rc 5命令，該命令會依據系統服務的依賴關係遍歷執行/etc/rc5.d中的指令碼/程式。進入/etc/rc5.d目錄可以發現裡面的檔案都是到/etc /init.d/下對應的指令碼/程式的軟鏈結。以s開頭的為啟動的意思，以k開頭的為停止。並且s/k後面的兩位數數字代表了服務的啟動順序（由服務依賴關係決定）。
那麼upstart job是怎麼樣的呢？我們知道，system v initializaiton是以runlevel為核心，依據服務間依賴關係的init方式，但在upstart job，runlevel雖說對於服務的啟動也有影響但已不是關鍵所在。upstart job是事件驅動的，系統服務的啟動、停止等等均是由事件決定的，反過來，系統服務的啟動、停止也可以作為事件源觸發其他服務。並且事件並不一定得由系統內部產生，使用者可以手工的鍵入start/stop [service]產生事件來啟動/終止服務。man upstart-evnets檢視upstart job所定義的事件，可以發現，runlevel也被當作事件來對待（因runlevel的改變而產生的事件），諸如此類還有其他如 startup，started，filesystem等等。那麼系統服務又是如何知道自己應該什麼時候啟動，什麼時候終止的呢？答案就在於/etc /init中（有的distros可能是在/etc/event.d）。進入/etc/init目錄下一看，均是系統服務的配置檔案，或者說，是job definition files。（實際上upstart init只需要/etc/init這麼乙個目錄，不像system v init，「拐彎抹腳」轉好多圈才到達目的地，在效能上不如前者）。隨便開啟乙個檔案，比如cron.conf：
#cron - regular background program processing daemon##
cron is a standard unix program that runs user-specified programs at
#periodic scheduled times
description"
regular background program processing daemon
"start on runlevel [2345]
stop on runlevel [!2345]
expect fork
respawn
exec cron
相信敏銳的程式猿們都發現了：start on runlevel [2345]；stop on runlevel [！2345]
沒錯，配置檔案就是通過這個來設定服務何時啟動，何時終止的。
實際上並不僅僅在系統啟動初期，在系統運轉的任何時期都可以通過傳送事件來啟動或終止服務。這便是upstart job的優點之一，除了用於系統初始化，還可以在系統執行階段發揮作用。相比之下system v initialization方式下的配置檔案一般只用於系統初始化階段，當然系統執行階段我們可以通過/etc/init.d/service start/stop/othercommand來操作服務，但很明顯不如upstart方式簡潔明白。
好，介紹完system v initialization和upstart，那麼現在就能介紹ubuntu init系統初始化流程。前面提過ubuntu使用的是upstart方式的initialization，其實不全然，考慮到6.10之前的版本採用的system v init及某些服務的需要，ubuntu採用的是相容模式，即：系統中既有system v-style啟動的服務，也有upstart啟動的服務。如果你使用的是ubuntu11.04（我目前pc上的系統），那麼你可以看到系統中有這麼幾個目錄：
/etc/init/etc/init.d
/etc/rc$.d
作為兩種init方式各自特徵的/etc/init.d，/etc/rc$.d目錄和/etc/init目錄在ubuntu中都有了，那麼
ubuntu是如何實現相容的？實際上，ubuntu中並沒有直接採用system v-style啟動服務，要知道，ubuntu中的init已被替換
為upstart init，而system v-style的服務是存放於/etc/rc$.d目錄中的，（而/etc/rc$.d/
下的檔案是到/etc/init.d的軟鏈結）可upstart init並不會直接跑到這裡面去啟動服務。它是通過間接呼叫來啟動這類服務的。
換句話說，ubuntu中的init並不會直接奔著/etc/init.d或者/etc/rc$.d/而去，它採用了折衷的辦法，通過
/etc/init下的某些配置檔案呼叫/etc/rc$.d/中的指令碼以啟動採用舊式system v-style的服務。唉，說的我自
己都覺得好繞，還是見例項吧，看下面。
進入/etc/init目錄（upstart init會到該目錄下讀取配置檔案），會發現幾個跟rc有關的配置檔案：
rc.confrc-sysinit.conf
rcs.conf
rc-sysinit在startup事件發生時被啟動，rc在系統runlevel變化時被啟動，rcs在系統runlevel為s時啟動。在配置檔案的注釋中說明了，這幾個檔案，正是upstart init處理system v-style服務的關鍵。
rc-sysinit在startup事件發生時被啟動，即，upstart init會首先讀取rc-sysinit.conf並執行相關配置和指令碼。rc-sysinit.conf的主要工作是設定系統預設runlevel，檢測是否存在/etc/inittab或核心命令列，若存在，則按核心命令列》/etc/inittab>預設runlevel的順序設定系統 runlevel。最後，呼叫telinit進入設定的runlevel。
由於呼叫了telinit進入了設定的runlevel，runlevel改變的事件發生，此時rc服務啟動（當然其他服務也會）。那麼，我們就有必要來看看rc.conf中到底有什麼東西。開啟rc.conf，注意到最後一行：
exec /etc/init.d/rc $runlevel
是不是感覺/etc/init.d/rc很熟悉，沒錯，在system v initialization中，/etc/inittab中的各runlevel對應的命令列就是通過這種形式設定的。
很明顯，/etc/init.d/rc被呼叫了，並且傳入了早前設定好的系統runlevel作為引數。而/etc/init.d/rc會根據傳入 的runlevel引數呼叫/etc/rc$.d/下的指令碼（以s開頭）以啟動服務，終止在前次runlevel啟動而當前在 runlevel需要終止的服務。至此，ubuntu處理system v-style服務的流程是不是漸漸明朗了。通過rc-sysinit和rc間接的呼叫/etc/init.d/rc從而啟動system v-style服務，ubuntu在採用新式upstart init照顧了舊式的system v init。
採用upstart方式啟動的服務則在/etc/init/目錄中有屬於自己的乙份配置檔案，終端下鍵入：initctl list，看看列出的服務是否同/etc/init/下的服務完全一致！
ubuntu init啟動過程
傳統上，linux有幾種不同的執行級別，包括如下幾種 0 停機 1 單使用者模式 2 多使用者，沒有 nfs 3 完全多使用者模式 標準的執行級 4 系統保留的 5 x11 x window 6 重新啟動 系統啟動後處於哪一種級別由init讀取 etc inittab檔案中的預設級別設定來確定，一半...
ContentProvider啟動流程分析（一）
本片部落格對應時序圖上的step1 5 下接第二篇contentprovider啟動流程分析二！作為安卓設計的四大元件之一，是跨程序共享資料的一把利器，所謂跨程序共享資料，通俗理解就是，應用程式a可以訪問操作應用程式b共享出來的資料，這些共享出來的資料一般都有其對應的uri 統一資源識別符號 那麼就...
專題分綱目錄 android 開機啟動流程分析
android 開機啟動流程分析 01 init之前啟動說明 android 開機啟動流程分析 02 init的啟動流程分析 android 開機啟動流程分析 03 init啟動中關鍵程序 uevent watchdog android 開機啟動流程分析 04 init啟動中關鍵服務 屬性服務 an...