模板
教程
環境
性能
功能
管理
優化Linux 系統服務來提高引導速度
本文向您描述了如何在不影響可用性的前提下加快 Linux 操作系統的引導速度。當然，這種方法要求您對系統服務及服務之間的依賴關系有所理解，如果它們可以并行啟動，就讓它們并行啟動而不是串行啟動。
毫無疑問 Linux 是一個優秀的系統，但仍然無法擺脫一個常見的責難（尤其是來自具有 Microsoft Windows 背景的人），那就是 Linux 系統從按下“on”鍵開始到可以使用，需要的時間太長。其實他們說的沒錯，Linux 確實需要比較長的引導時間。
在這里我所描述的加快 Linux 引導速度的技術雖然理解起來很簡單，但真正實現卻需要謹慎行事。我希望 Linux 的發行商能采用這種方法，這樣用戶就可以省去那些配置任務。不過如果您喜歡冒險，請繼續閱讀本文。
我強烈建議您在考慮用我所建議的方法修改一個正式的系統之前，先去修改一個無關緊要的測試系統。如果您只有一臺機器，那么您可以使用 UML (User Mode Linux) 這一非常有用的工具。UML是一個內核補丁，它可以將Linux內核編譯成為一個二進制文件，然后您可以像運行一個普通的程序一樣去運行這個內核。也就是說，您可以在您的正常的系統之上以一個進程的方式來運行一個完整的 Linux 系統。您可以將其想象為在一個正常的系統 中運行一個 Linux 系統。(請參閱本文末尾的 參考資料，可以找到可以下載UML的站點以及 developerWorks網站上關于UML的教程)。
使用UML您可以工作于一個測試系統，哪怕把這個測試系統完全破壞掉，也不會影響您正常的系統。
概述
本文的第一部分介紹當 Linux 內核（Linux 機器的的“核心”）加載后，一個 Linux 系統怎樣在后臺啟動。然后介紹加快您的系統引導速度的技術。
如果您對運行級和服務啟動腳本已經熟悉，您可能希望直接跳轉到 傳統服務框架的局限。
一個 Linux 系統的引導過程可以分為幾個階段。本文并不會解釋所有的不同階段，因為我們所關心只是當內核加載后的那一個階段。
您可以運行 /sbin/runlevel 命令來確定您的系統當前的運行級。（更多詳細信息請查閱 man runlevel）。
當內核被加載并開始運行時會調用 /sbin/init 程序。這個程序以 root 身份運行，并且在開始引導時按照要求設定為“運行級”。（更多關于 init 程序的詳細信息，請參考 man init）
一個 運行級僅僅是一個數字，Linux根據這個數字來區分不同類型的高層次配置，系統將按照不同的高層次配置來進行引導。由于絕大部分運行級數字都定義了明確的含義，因而它們基本上是“眾所周知”的。Red Hat Linux 系統的主要運行級見表1。
表 1. Red Hat Linux運行級
| 運行級 | 說明 |
| 0 | 關閉 |
| 1 | 單一用戶模式（一般僅用于管理目的） |
| 2 | 多用戶模式，不允許使用網絡 |
| 3 | 多用戶模式，允許使用網絡 |
| 4 | 沒有用到的運行級 |
| 5 | 多用戶模式，允許使用網絡，X-Windows 方式（圖形登錄界面） |
| 6 | 重新引導 |
 |
|
系統服務
rc 腳本負責啟動用戶需要的所有服務。就像名字所描述的一樣，所謂服務就是系統提供的有用的工具?？赡軙泻芏喾招枰獑?。大部分的 Linux 系統會啟動 sshd（安全Shell服務）、syslog（系統日志工具）和 lpd（打印服務），但還會有更多的服務需要啟動。比如，我的 Red Hat 9 系統現在運行著29個服務，但如果我把所有的服務都啟動，那么我的系統中將會有近50服務在運行。
|
|
通常在 /etc/rc.d/init.d/ 目錄下可以找到服務程序。
如果你瀏覽一下這個目錄，你就會發現相當多的（如果不是全部都是的話）服務程序實際上都是 shell 腳本，用于調用其他程序完成實際的工作。
rc 腳本如何知道在每個運行級下去運行哪些腳本？
回顧一下，如果我們不希望在某個運行級下運行某個腳本，我們如何告訴系統這樣去做？答案是在 /etc/rc.d/ 目錄下，在這個目錄下，除了我們已經討論過的 init.d/ 目錄以外，還有一組目錄，每一個目錄對應一個運行級。這些目錄以 rc<runlevel>.d 的形式來命名，比如，對應運行級5的目錄為 /etc/rc.d/rc5.d/ 。在這些rc.d目錄中，每一個目錄下都有一組符號鏈接，指向 /etc/rc.d/init.d 中的真正的服務程序。實際上，后邊我們會發現，每個服務事實上有兩個符號鏈接。
服務鏈接名
這些指向實際服務程序的符號鏈接的名字很重要，它們遵循嚴格的命名約定，這樣 rc 腳本就知道如何處理它們。
為了便于標識，每個鏈接的名字都以它們所指向的服務的名字做為后綴。
前綴由兩部分構成：一個大寫字母，緊跟著是一個兩位的十進制數。前綴中的大寫字母是“S”（表示“啟動”），或者“K”（表示“殺死”，或者停止）。兩位數的大小范圍是自00到99。
|
|
啟動和停止服務
如果我們決定讓 Linux 機器引導到圖形模式（運行級5），當 init 調用 rc 腳本并傳遞給它運行級數字時，rc 腳本將到 /etc/rc.d/rc5.d/ 中查找，并且去運行它所能找到的所有符號鏈接（也就是說，它將運行每個鏈接指向的程序/腳本）。它將在兩個截然不同的階段來運行這些鏈接；首先它會執行所有以“K”開頭的鏈接，同時傳遞給它們參數“stop”。執行完以后，所有這些鏈接指向的服務都被停止。
rc 把參數“tart”或者“stop”傳遞給每一個服務程序，這樣做是為了只用一個服務程序可以啟動或停止那個服務——服務程序根據傳遞給它的參數值分辨系統是正在引導還是正在關閉。
清單 1. 運行級5的指向服務程序的鏈接
|
這看起來好象是非常復雜的系統，但實際上它提供了極好的靈活性，因為如果您想臨時禁止某個特定運行級中的服務，只要把適當的符號鏈接刪除即可。不過，手工管理這些鏈接可能會讓人感覺厭煩，并且容易出錯（尤其當您累了的時候），所以可以采用一個相對好一些的方法，使用 chkconfig 命令。
|
|
如何找出激活的服務
想查看您已經激活了多少服務，運行這個命令：
chkconfig 命令還可以用來切換任何一個服務的開或關。詳細信息請參考手冊頁（man chkconfig）。
清單 2. chkconfig --list|sort的輸出
|
清單 2中第一列是服務的名字，接下來的列是運行級和每一個運行級中服務的狀態。例如，ntpd (Network time daemon)服務被配置為只在運行級3中（多用戶，無圖形）和運行級5（多用戶，有圖形）中啟動，sshd 服務在運行級2，3，4和5中都被切換到開的狀態。
注意在運行級0和6中沒有一個服務要啟動?；仡櫛?1，原因顯而易見。運行級1表示要關閉或停止系統，因此在機器將要“關閉”時，您不會想要 啟動任何服務。運行級6中也是如此。
運行級1——“單一用戶模式”——是一個特別的運行級，一般在系統出問題的時候使用。一直以來，在運行級1中運行的唯一一個應用程序是 shell，允許超級用戶來修復系統或者讓超級用戶在一個安全的環境中修改系統。這樣是安全的——就像它的名字“單一用戶模式”的含意一樣——只有超級用戶可以訪問系統。并且，聯網是禁用的，所以沒有人可以遠程登錄。如表 1所示，單一用戶模式中運行的唯一一個服務是keytable，這樣使得超級用戶的鍵盤可以正常使用。
激活服務與運行服務的對比
有時服務會由于某種原因無法啟動，用下面這個命令查看當前有哪些服務正在運行：
關鍵的是，只有當配置中的所有服務都啟動以后，您才可以登錄進入您的 Linux 系統。等待50個服務啟動可能會需要若干分鐘，而這本來應該是您享用Linux系統的時間。
我已經找到了一個加速這個過程的方法。注意這種方法不會停止任何服務。不管怎樣，停掉那些不用的服務是很明智的，不僅是因為這樣可以加快引導的速度（在機器可以登錄之前需要運行的服務少了），而且，由于很多服務要以 root 用戶身份來運行，停掉不用的服務會減少您的安全隱患。
扼要重述一下，當一個 Linux 系統引導時，它以一種連續的方式來運行所有的某個運行級所配置的所有服務—— 一個接一個地。這是一個耗時的操作。
或許一個很明顯的加快服務啟動速度的方法是并行地啟動所有的服務，這樣它們就可以同時啟動。不幸的是，雖然這聽起來很吸引人，卻不可行。原因是各個服務之間存在依賴的關系。Linux沒有把這些依賴關系完全顯式地表示出來，但是事實上這些依賴關系是存在的。還記得我們先前討論的關于鏈接名字格式的問題嗎？在 “S”和“K”之后的兩位數決定了鏈接（也就是它們指向的服務）的運行順序。這些數字確定了一個硬性的順序，這樣一定程度上也強化了服務之間的依賴關系。
回顧 清單 1,我們可以看到 network 服務（S10network）將在ntpd服務（S58ntpd）之前運行。這是我們所期望的，因為 ntpd 服務要求網絡可達，以使它可以連接一個本地時間服務器。不幸的是，這個硬性的順序并不能告訴我們足夠的信息，并且會讓人誤解。例如，在 清單 1中我們可以看到 lpd 服務(S60lpd)將在 network 服務之后運行。雖然這樣對那些連接到網絡并且使用網絡打印機的 Linux 系統來說是正確的，但是這并不說明當背板上有一個 inkjet 打印機連接到本地系統時，lpd 服務還是必須要在 network 服務之后運行。實際上，在這種情況下，在啟動 network 之前先啟動 lpd 會更好一些。
再來看另外一個例子：crond （cron daemon）服務 (在 清單 1中的 S90crond)也是在 network 啟動之后運行?？墒?，如果您沒有使用遠程機器文件的 cron 文件，那么就應該讓 crond 在 network 之前啟動。
由于我剛才介紹的 Linux 下啟動服務的傳統方法有一定的局限性，往往傾向于“安全第一"，讓所有的重要的服務先啟動，然后再啟動余下的那些。
所以，盡管我們不能并行地啟動 所有的服務，但我們可以并行地啟動那些 相互間沒有依賴關系的服務。當這些相互間無依賴的服務啟動以后，我們可以啟動那些所有依賴條件已經滿足（也就是說，那些服務所依賴的服務已經啟動）的服務。然后重復這一過程，直到所有服務全部啟動。
這個看起來是一個復雜的問題，不過幸運的是，已經有一個現成的可以用來解決這個問題的程序。這個程序不是別的，正是 make。
通常當編譯軟件時，make 會提供我們所需要的嚴密的框架。所有我們要做的就是告訴 make 什么是服務之間的依賴；它可以去做所有的計算交叉依賴的艱難工作，并且，使用它的鮮為人知的標記 -j ，它可以作為許多"作業"而 同步運行。
|
|
現在，我們來做一個簡單的實例。我們都知道，ntpd 服務需要網絡，這說明 ntpd 服務依賴于network 服務。在 make 語法中這個依賴關系這樣表示：
|
這看起來沒什么，但是您知道這意味著什么嗎？這意味著一旦 network 服務啟動完成，我們可以 并行地啟動 ntpd，netfs 和 autofs 服務。
為什么會這樣？好了請看，network 服務啟動需要10秒時間，但是（因為當 rc 腳本在運行時，機器處于完全多任務的狀態）其余三個服務可以 同時啟動，所以這三個服務 合起來的啟動時間是10秒。
事實上，大部分服務需要的啟動時間可能不是10秒，但是既然每一個服務要做一些完全不同的事情，啟動它們所需要的時間會很可觀。
樣例實現
我在 參考資料部分提供的壓縮文件中有一個使用上述技術的樣例實現。包括一個修改過的用于調用 make 命令的 rc 腳本，以及樣例GNU makefile文件，分別是 runlevel.mk，start5.mk和stop5.mk。makefile 文件 runlevel.mk 是控制程序，start5.mk 文件和stop5.mk 文件分別是運行級5時啟動和停止服務時的服務依賴描述文件。
注意所給出的啟動和停止 makefile 文件提供的不是完全的服務間依賴關系列表，而僅僅是一個例子。同時也要注意，如果您不修改這些文件就在您的系統上使用，幾乎不可能成功，因為您的服務列表可能和我的并不一樣。
- 一些服務程序僅僅是在后臺運行一個程序，它們自己就退出了（也就是說，服務程序結束了，但是真實的工作仍然在后臺進行）。這說明了一個事實，那就是傳統的系統是不完善的，這種服務程序編寫者試圖在現有框架的界限內減少一些時鐘周期。采用本文描述的這種方法將會使依賴關系更加顯式化，不需要服務編寫者再去“欺騙”。這種方法考慮到在這些服務程序之外建立一個更為高效的框架。
- 當您希望“交互式”引導您的系統時，這里所提到的技術不再適用，因為您通常是當系統某些地方出錯的時候才會這樣去做；在這種情況下，您可能希望串行地去啟動所有的服務以找出出錯的原因。不過，修改系統的啟動過程，來讓用戶在系統引導來選擇是以串行的方式（允許交互的服務啟動）或者“并行”的服務啟動方式，是容易實現的。
- 采用這種方法可能還需要更深入的考慮，因為如果傳統的系統和新的系統都提供給用戶，將需要同步維持兩組關于服務如何啟動的信息（有序的 rc.d/ 鏈接文件和運行級 make 文件）。一個更好一些的解決方案是 Linux 發行版本能從 makefile 文件自動生成鏈接文件，因為 makefile 文件比鏈接文件記錄了更多的關于服務的信息。
- 這個系統可能對一個專用的服務器來說并不適合，因為當一個服務發生錯誤時，管理員希望能在錯誤發生時在控制臺中馬上可以看到這個錯誤。不過，對于普通的終端用戶來說，并行化的方法可以在允許用戶查看是否有問題發生的前提下顯著地加快引導速度。
- 有趣的是，盡管我提出的這種方法從傳統觀點來看不是“類似Linux的”，但 Linux 基礎標準 (LSB，Linux Standards Base)看起來并沒有要指定 init.d 腳本的運行順序，所以這種方法有可能被 Linux 發行商所采用，而且使之仍然符合 LSB。這對用戶來說是一個好消息，如前面所提到的，因為發行商可以為我們計算出所有的軟件包之間的依賴關系。
- 有一種方法可能更為大膽，那就是 /etc/inittab 文件中的“action field”的“wait”修改為“once”。這樣用戶在服務啟動完成之前就可以登錄。不過，這已經超出了本文的范圍。要得到更詳細的信息請查閱 man inittab，并且請記住，UML是您的好幫手。
原文轉自：http://www.anti-gravitydesign.com
