最近，因和隊友一起做linux開發，因為用的不是同一版本linux（他用arch, 我用ubuntu）,再配置上經常就不一樣,就如這個inittab檔案，於是深究了一下原因：

Linux 核心啟動 init ，init程序ID是1，是所有程序的父程序，所有程序由它控制。

Ubuntu 的啟動由upstart控制，自9.10後不再使用/etc/event.d目錄的配置檔案，改為/etc/init。

檢視當前的執行級別，Ubuntu 桌面預設是2。

Ubuntu 的系統執行級別：

切換執行級別，執行命令：

即在 init 命令後跟一個引數，此引數是要切換到的執行級的執行級代號，如：用 init 0 命令關機；用 init 6 命令重新啟動。

這就是我們的關機命令之一 $ sudo init 0  的由來:

檢視系統當前執行等級：

檢視系統在什麼地方設定這個初始值，開啟檔案： （後面詳細介紹為什麼）

你會發現這麼一句：  

Ubuntu init啟動流程分析:

現行的Linux distros主流的有兩種init方式：一種是廣為流傳的System V initialization，它來源於Unix並且至今仍被各種Linux distros所採用；另一種是近幾年提出的Upstart方式，基於事件機制，系統的所有服務，任務都是由事件驅動的。據我所知，採用後一種方式的目前有Ubuntu（6.10 and later），Fedora（9.10 and later），Debian（optional）。雖然採用Upstart的發行版並不多，但它旨在取代舊式的System V initialization。

作為知識梳理，我現在就先在這裡總結一下這兩種方式各自的初始化流程，這也是為了方便整理思路：

之前在查詢Linux系統init流程的相關資料時總是能夠看到inittab的身影，但是在我的Ubuntu上是沒有這個檔案的，到後來才知道採用 Upstart方式的Ubuntu上是沒有inittab這個檔案的。在舊式的System V initialization中，/etc/inittab可是個相當重要的檔案。init程序啟動後第一時間找的就是它！inittab負責初始化系統，設定系統runlevel及進 入各runlevel對應要執行的命令。假設當前inittab中設定的預設runlevle是5，則init會執行/etc/init.d/rc 5命令，該命令會依據系統服務的依賴關係遍歷執行/etc/rc5.d中的指令碼/程式。進入/etc/rc5.d目錄可以發現裡面的檔案都是到/etc /init.d/下對應的指令碼/程式的軟連結。以S開頭的為啟動的意思，以K開頭的為停止。並且S/K後面的兩位數數字代表了服務的啟動順序（由服務依賴關係決定）。

【注】   網上查了一下， .d 檔案的作用 ： .d代表目錄即資料夾的意思。/etc是存放配置檔案的目錄，配置檔案有的是單獨的，有的是一類，通常單獨的配置檔案字尾是.conf，一類的配置檔案放在一個目錄中，目錄名就叫XX.d，XX指的是哪方面的配置檔案，比如init.d就存放有關linux啟動的配置檔案。

那麼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：

相信敏銳的程式猿們都發現了：start on runlevel [2345]；stop on runlevel [！2345]

沒錯，配置檔案就是通過這個來設定服務何時啟動，何時終止的。

實際上並不僅僅在系統啟動初期，在系統運轉的任何時期都可以通過傳送事件來啟動或終止服務。這便是Upstart job的優點之一，除了用於系統初始化，還可以在系統執行階段發揮作用。相比之下System V initialization方式下的配置檔案一般只用於系統初始化階段，當然系統執行階段我們可以通過/etc/init.d/Service start/stop/otherCommand來操作服務，但很明顯不如Upstart方式簡潔明白。(如果你是linux 使用者，你一定不陌生這些，一定很清楚。)

好，介紹完System V initialization和Upstart，那麼現在就能介紹Ubuntu init系統初始化流程。前面提過Ubuntu使用的是Upstart方式的initialization，其實不全然，考慮到6.10之前的版本採用的System V init及某些服務的需要，Ubuntu採用的是相容模式，即：系統中既有System V-style啟動的服務，也有Upstart啟動的服務。如果你使用的是Ubuntu11.04（我目前PC上的系統），那麼你可以看到系統中有這麼幾個目錄：

作為兩種init方式各自特徵的/etc/init.d，/etc/rc${runlevel}.d目錄和/etc/init目錄在Ubuntu中都有了，那麼Ubuntu是如何實現相容的？實際上，Ubuntu中並沒有直接採用System V-style啟動服務，要知道，Ubuntu中的init已被替換為Upstart init，而System V-style的服務是存放於/etc/rc${runlevel}.d目錄中的，（而/etc/rc${runlevle}.d/下的檔案是到/etc/init.d的軟連結）可Upstart init並不會直接跑到這裡面去啟動服務。它是通過間接呼叫來啟動這類服務的。換句話說，Ubuntu中的init並不會直接奔著/etc/init.d或者/etc/rc${runlevel}.d/而去，它採用了折衷的辦法，通過/etc/init下的某些配置檔案呼叫/etc/rc${runlevel}.d/中的指令碼以啟動採用舊式System V-style的服務。（這是精髓）唉，說的我自己都覺得好繞，還是見例項吧，看下面。

進入/etc/init目錄（Upstart init會到該目錄下讀取配置檔案），會發現幾個跟rc有關的配置檔案：

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，注意到最後一行：

是不是感覺/etc/init.d/rc很熟悉，沒錯，在System V initialization中，/etc/inittab中的各runlevel對應的命令列就是通過這種形式設定的。

很明顯，/etc/init.d/rc被呼叫了，並且傳入了早前設定好的系統runlevel作為引數。而/etc/init.d/rc會根據傳入 的runlevel引數呼叫/etc/rc${runlevel}.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/下的服務完全一致！

哈哈，完了。

來源：http://www.ginchenorlee.com/?p=315