簡(jiǎn)而言之，systemd是一個(gè)init程序。根據(jù)之前 Upstart的一些介紹大家應(yīng)該簡(jiǎn)要了解了傳統(tǒng)Sysvinit系統(tǒng)的不足之處。不過，這次的systemd的設(shè)計(jì)思想更為超前，也可以說是借鑒了OSX上launchd的思路。

init進(jìn)程由內(nèi)核啟動(dòng)，是所有其他進(jìn)程的父進(jìn)程（也許應(yīng)該譯為母進(jìn)程？:-）因此比其他進(jìn)程能夠做更多事情，比如在啟動(dòng)過程中加載服務(wù)進(jìn)程。

傳統(tǒng)的 sysinit 系統(tǒng)不符合一個(gè)有效的、快速的init系統(tǒng)標(biāo)準(zhǔn)：

1. 盡可能啟動(dòng)更少進(jìn)程

2. 盡可能將更多進(jìn)程并行啟動(dòng)

條款1意味著除非必須否則不啟動(dòng)。不像syslog和DBus，藍(lán)牙服務(wù)僅在藍(lán)牙適配器被插入時(shí)才被需要；打印服務(wù)僅在打印機(jī)連接或程序要打印時(shí)才需要；甚至sshd也不是必須的，管理員常常因幾個(gè)月才連接一次的ssh而一直運(yùn)行 sshd 進(jìn)行監(jiān)聽。條款2意味著不應(yīng)該像 sysvinit 一樣串行執(zhí)行啟動(dòng)進(jìn)程，以最大化CPU和IO帶寬的效率。

軟硬件的動(dòng)態(tài)改變

現(xiàn)代的操作系統(tǒng)應(yīng)具備高度的動(dòng)態(tài)特性：不同的程序啟動(dòng)、停止，不同的硬件被添加、移除，因此需要服務(wù)在被需要時(shí)動(dòng)態(tài)的啟動(dòng)。大多數(shù)當(dāng)前的系統(tǒng)在盡可能并行化啟動(dòng)過程時(shí)仍對(duì)一些守護(hù)進(jìn)程的調(diào)用保持同步：比如 Avahi 需要DBus，故僅在DBus啟動(dòng)、且 DBus 信號(hào)準(zhǔn)備完成后 Avahi 才被啟動(dòng)。與之相同的是 libvirtd 和 X11 需要HAL（雖然之后HAL會(huì)被移除），在 HAL 啟動(dòng)前，libvirtd 和 X11 不會(huì)啟動(dòng)。

并行化Socket服務(wù)

以上的同步過程導(dǎo)致了啟動(dòng)過程的串行化。能否擺脫同步與串行化的缺點(diǎn)呢？答案是能夠! 首先我們要理解 daemon 對(duì)彼此的真正依賴是什么，為什么它們?cè)趩?dòng)時(shí)被延遲了。對(duì)于傳統(tǒng)的 Unix daemon，答案是：它們?cè)谒枰姆?wù)所提供的 socket 準(zhǔn)備好連接之前一直處于等待狀態(tài)。常見的是 AFUNIX，但也可能是 AFINET。比如，需要DBus服務(wù)的客戶程序?qū)⒃?/var/run/dbus/systembussocket 可以被連接之前等待，syslog 服務(wù)的客戶程序?qū)⒃?/dev/log 上等待...而這是它們唯一需求的內(nèi)容！（意指只要這一條件滿足，客戶程序即無(wú)需等待，不論實(shí)際的服務(wù)是否已經(jīng)啟動(dòng)。下文詳細(xì)介紹）

以上就是等待的真正含義。如果能盡早建立客戶程序所必須的 socket 而令客戶程序處于等待狀態(tài)而不是在服務(wù)程序完全啟動(dòng)后再啟動(dòng)客戶程序，我們就能加快啟動(dòng)進(jìn)程，進(jìn)一步并行化進(jìn)程啟動(dòng)。如何做到這一點(diǎn)？在 Unix 族系統(tǒng)上非常簡(jiǎn)單：在真正需要啟動(dòng)服務(wù)之前先監(jiān)聽其 socket，然后將 socket 傳遞給 exec() (此處直譯，含義不懂)，如此，在 init 系統(tǒng)中第一步就可建立所有 daemon 所需的所有 socket，在第二步中一次運(yùn)行所有的 daemon。如果一個(gè)服務(wù)需要另一個(gè)，但被需者未完全啟動(dòng)號(hào)，也完全沒有問題在被需者查詢 socket，處理請(qǐng)求之前，客戶進(jìn)程將因這個(gè)請(qǐng)求而被阻塞，但僅有被這個(gè)請(qǐng)求阻塞的客戶進(jìn)程被阻塞。并且服務(wù)之間的依賴關(guān)系將不再需要（手動(dòng)）配置：如果一次建立所有服務(wù)所必須的所有 socket（及啟動(dòng)所有相關(guān)服務(wù)），則所有服務(wù)的所有需求一定在最后會(huì)被滿足。

下列所說將是重點(diǎn)：如果同時(shí)啟動(dòng)了 syslog 和多個(gè)其客戶進(jìn)程（意指syslog尚未啟動(dòng)準(zhǔn)備好處理請(qǐng)求），而客戶進(jìn)程開始發(fā)送請(qǐng)求，則請(qǐng)求會(huì)被寫入 /dev/log 的Socket 緩存中。除非緩存填滿，否則客戶進(jìn)程無(wú)需任何等待即可繼續(xù)完成其啟動(dòng)過程。當(dāng) syslog 啟動(dòng)完全后，處理器所有的消息。另一個(gè)例子：DBus與其客戶進(jìn)程一起啟動(dòng)，當(dāng)同步請(qǐng)求發(fā)出但沒有接受到預(yù)想的回應(yīng)，客戶進(jìn)程將阻塞。當(dāng) DBus 啟動(dòng)完成后處理請(qǐng)求，客戶進(jìn)程繼續(xù)。

內(nèi)核的socket 緩存將輔助達(dá)成最大的并行化。因?yàn)閮?nèi)核完成了同步，不再需要用戶空間的任何的額外管理！如果在 daemon 啟動(dòng)前所有必須的 socket 都已經(jīng)可用，依賴關(guān)系就變得多余（至少是次要了）。daemon A 需要另一個(gè) daemon B，簡(jiǎn)單的連接到B。若B已經(jīng)啟動(dòng)，A的請(qǐng)求成功。若B未完成啟動(dòng)，假如A發(fā)出的不是一個(gè)同步請(qǐng)求，甚至無(wú)需理會(huì)（B沒有完全啟動(dòng)）。甚至即使B完全沒有執(zhí)行（比如crash了）時(shí)再重啟B也為時(shí)不晚對(duì)于A而言二者沒有任何分別。借此可達(dá)成最佳的并行化和隨意的需求時(shí)（on-demand）加載。而且在此基礎(chǔ)上能夠更加魯棒。因?yàn)?socket 即使在相應(yīng)服務(wù)是暫時(shí)不可用（如crash）時(shí)也可用，所以客戶進(jìn)程不會(huì)丟失任何的請(qǐng)求（request入buffer，待重啟服務(wù)后處理）

更多有趣之事

首先，這不是一種全新的邏輯，這正像是Apple的launchd系統(tǒng)所做的：OSX 中所有 daemon 所需的 socket 都由 launchd 建立，然后服務(wù)本身并行啟動(dòng)，無(wú)需手動(dòng)指定相關(guān)的依賴性。這一設(shè)計(jì)創(chuàng)意獨(dú)具，也正是OSX急速啟動(dòng)的原因。但這一思想在Apple之外未有任何系統(tǒng)有所體現(xiàn)。

在 launchd 之前,這一思想有更早的體現(xiàn)者：古老的 inetd 就如此工作：socket 被 daemon 建立而實(shí)際的服務(wù)在daemon通過exec()啟動(dòng)相關(guān)進(jìn)程時(shí)傳遞socket的文件描述符。然而 inetd 所關(guān)注的當(dāng)然不是本地服務(wù)，而是網(wǎng)絡(luò)上的服務(wù)。他也不是并行化啟動(dòng)或者隱藏依賴的正確工具。

對(duì)于 TCP 的 socket inetd 對(duì)于每個(gè)進(jìn)入的連接都建立一個(gè)新的 daemon 實(shí)例，這意味著每個(gè)連接將導(dǎo)致一次進(jìn)程初始化，這無(wú)助于高性能服務(wù)器。然而此后inetd支持另一種模式單：當(dāng)?shù)谝粋€(gè)連接到來時(shí)，第一個(gè)實(shí)例（單例）被啟動(dòng)，并將繼續(xù)接受后續(xù)的請(qǐng)求。

并行化Bus服務(wù)

Linux上現(xiàn)代的daemon都通過DBus而非socket來交互，現(xiàn)在的問題是，對(duì)于這些服務(wù)，能否施加與啟動(dòng)傳統(tǒng)的、基于socket的服務(wù)邏輯相同的并行化？答案是可以，DBus已經(jīng)提供了所有必要的hook：使用DBus將會(huì)在第一次訪問時(shí)加載服務(wù)，并且給予最小的、每請(qǐng)求一個(gè)的、消費(fèi)者與生產(chǎn)者同時(shí)啟動(dòng)的同步機(jī)制。例如Avahi與CUPS（CUPS需要Avahi進(jìn)行 mDNS/DNS-SD上打印機(jī)掃描）同時(shí)啟動(dòng)，僅僅是簡(jiǎn)單的同時(shí)啟動(dòng)二者，若CUPS比Avahi啟動(dòng)快，則DBus將把請(qǐng)求緩存入隊(duì)列，直到 Avahi服務(wù)進(jìn)行了處理。

所以，總結(jié)如下：基于Socket和基于DBus的服務(wù)可一次并行啟動(dòng)所有進(jìn)程，無(wú)需任何額外的同步。基于激活的策略還能令我們進(jìn)行延遲加載服務(wù)。如果服務(wù)很少被用到，我們可以在第一次被訪問時(shí)啟動(dòng)，而不是在啟動(dòng)過程中啟動(dòng)。

并行化文件系統(tǒng)任務(wù)

對(duì)于當(dāng)前發(fā)行版的啟動(dòng)序列圖可以看出，文件系統(tǒng)任務(wù)所發(fā)生的同步點(diǎn)大于 daemon 啟動(dòng)時(shí)的同步點(diǎn)：mount fsck等?，F(xiàn)在，啟動(dòng)時(shí)很多時(shí)間都花費(fèi)在空閑等待所有fstab 中列舉的文件系統(tǒng)被加載、 fsck的過程中，僅在完全完成后啟動(dòng)進(jìn)程才會(huì)繼續(xù)。如何改進(jìn)？答案是autofs系統(tǒng)。就如同connect() 調(diào)用表示一個(gè)服務(wù)對(duì)另一個(gè)服務(wù)感興趣，open() 調(diào)用（或相似的調(diào)用）表示服務(wù)對(duì)特定的文件或文件系統(tǒng)有需求。所以，我們應(yīng)該僅令那些訪問暫時(shí)還不可用（暫未完成 mount、fsck）文件系統(tǒng)的服務(wù)阻塞，這樣就改進(jìn)了并行性。首先加載autofs，然后繼續(xù)正常的mount過程，當(dāng)被訪問的文件系統(tǒng)未準(zhǔn)備好，內(nèi)核將會(huì)緩存請(qǐng)求調(diào)用，訪問進(jìn)程將被阻塞，一個(gè)未成功的訪問僅可能阻塞一個(gè)進(jìn)程。當(dāng)真正的文件系統(tǒng)加載完成后，啟動(dòng)進(jìn)程如同正常般完成，沒有任何缺失的文件，如此我們能夠在所有文件系統(tǒng)都準(zhǔn)備好之前就加載服務(wù)。

假如有人提出將autofs內(nèi)置于 init 是不妥當(dāng)?shù)奈也⒉桓杏X奇怪，也許這會(huì)導(dǎo)致更多 crash。然而經(jīng)過實(shí)驗(yàn)，我可以說這并不正確。使用autofs意味著無(wú)需馬上提供后臺(tái)的真實(shí)文件系統(tǒng)，這只會(huì)導(dǎo)致訪問被延遲。如果進(jìn)程嘗試訪問autofs但真實(shí)的文件系統(tǒng)很長(zhǎng)時(shí)間都沒能加載，進(jìn)程將被一個(gè)sleep中斷上被掛起，意味著你可以安全的cancel 它。如果最后這個(gè)文件系統(tǒng)都沒能加載，那么令 autofs 返回一個(gè)error Code（例如 ENOENT）。所以我認(rèn)為內(nèi)置 autofs 到init中是正確的。實(shí)驗(yàn)代碼顯示這一想法在實(shí)踐中工作的很好。

保持第一個(gè)登錄的用戶的 PID 很?。ㄒ饧磫?dòng)進(jìn)程中少啟動(dòng)進(jìn)程）

我們可以從MacOS的啟動(dòng)邏輯中學(xué)到的另一個(gè)內(nèi)容是：shell腳本是有害的。Shell很容易 hack，但是執(zhí)行卻太慢。傳統(tǒng)sysvinit啟動(dòng)邏輯就是圍繞shell腳本的一種模式不論是/bin/bash還是其他shell（被用來更快執(zhí)行shell腳本），最后的結(jié)果注定很慢在我的系統(tǒng)中，/etc/init.d中的系統(tǒng)腳本至少調(diào)用grep 77次，awk92次，cut23次，sed74次。每次調(diào)用時(shí)這屆進(jìn)程都被產(chǎn)生一次，庫(kù)被搜索一次，有些像i18n這樣的還會(huì)加載更多。這些基于瑣碎字串比較的進(jìn)程導(dǎo)致最終難以置信的慢。只有shell腳本如此工作。除此外shell腳本也非常脆弱，環(huán)境變量之類能夠徹底改變腳本的行為（behaviour），最終難于檢查和控制。

所以在啟動(dòng)過程中擺脫shell腳本！在如此之前先要明確使用 shell腳本的實(shí)際用意何在：大體上來說，shell 腳本在完成的是些令人厭煩的工作，用于瑣碎的設(shè)置和卸載服務(wù)。這些內(nèi)容應(yīng)該用C來完成，位于分離的可執(zhí)行程序，或者移至daemon本身，或者交給init?？雌饋砦覀冞€無(wú)法馬上在啟動(dòng)過程中擺脫腳本，用C重寫需要時(shí)間，且在有些時(shí)候也不行 shell 腳本太過靈活以至于無(wú)法脫離，但我們當(dāng)然能讓它們不像現(xiàn)在這樣突出（被大量使用）。

簡(jiǎn)單測(cè)量shell 腳本對(duì)于啟動(dòng)過程的危害可以從你在系統(tǒng)完全啟動(dòng)后加載的第一個(gè)進(jìn)程的PID看出來：?jiǎn)?dòng)、登錄、打開終端，輸入echo $$，對(duì)比Linux和MacOS，如下：Linux PID:1823，MacOS PID:154。自己測(cè)去吧。

接下來作者分析了Upstart對(duì)于這些問題的一些解決方法以及不足之處，接下來介紹了作者的最終結(jié)論： putting it all together:systemd

其特性就是，上文中如此多的翻譯已經(jīng)說明了其核心思路，就不具體介紹其中的詳細(xì)概念了。值得一提的是systemd解析傳統(tǒng)的SysVinit 腳本，將其依賴關(guān)系轉(zhuǎn)化為其原生的依賴關(guān)系，因此兼容 Sysvinit 腳本的同時(shí)仍能提供并行性，而 Upstart 無(wú)法對(duì)傳統(tǒng)腳本進(jìn)行并行化。且可通過DBus界面控制。

目前狀態(tài)：已經(jīng)可作為Sysinit或 Upstart的替代來使用，有一個(gè)修改過的 Fedora 13 qemu 鏡像可供下載使用。作者秒表計(jì)時(shí) Fedora13用Upstart啟動(dòng)27s，systemd24s（從grub到 gdm ,相同系統(tǒng),相同設(shè)置，兩次連續(xù)的啟動(dòng)過程中取較少者）。

【編輯推薦】

1. Linux查看版本信息及CUP內(nèi)核、型號(hào)等
2. Linux管理員們，該刷新內(nèi)核了
3. Linux新突破：新的內(nèi)核與新的文件系統(tǒng)
4. Linux內(nèi)核編譯后地址空間的整理