Linux系統中的進程管理工具SystemD介紹

 　　SystemD是Linux下的一種init軟件，由Lennart Poettering帶頭開發，並在LGPL 2.1及其後續版本許可證下開源發布。Lennart是redhat員工，但SystemD不是redhat項目。其開發目標是提供更優秀的框架以表示系統服務間的依賴關系，並依此實現系統初始化時服務的並行啟動，同時達到降低Shell的系統開銷的效果，最終代替現在常用的System V與BSD風格init程序。

　　SystemD這一名字源於Unix中的一個慣例：在Unix中常以“d”作為系統守護進程(英語：daemon，亦稱後台進程)的後綴標識。除此以外，SystemD亦是借代英文術語D體系，而這一術語即是用於描述一個人具有快速地適應環境並解決困難的能力。

　　SystemD被設計用來改進SysVinit的缺點，與Ubuntu的upstart形成技術競爭。SystemD的很多概念來源於蘋果的launchd。目標是盡可能啟動更少進程;盡可能將更多進程並行啟動(這是性能優於SysVinit的理念基礎)。SystemD盡可能減少對Shell腳本的依賴。傳統SysVinit使用inittab來決定運行哪些Shell腳本，大量使用Shell腳本被認為是效率低下無法並行的原因。SystemD使用了Linux專屬技術，不再顧及POSIX兼容，只要能滿足社會變革的需要，突破一些可能過時的技術約束，這也是當今創信理念的需要，相信市場會給出評判。

　　與多數發行版使用的System V風格init相比，SystemD采用了以下新技術：

　　采用Socket激活式與總線激活式服務，以提高相互依賴的各服務的並行運行性能;

　　用cgroups代替PID來追蹤進程，因此即使是兩次fork之後生成的守護進程也不會脫離systemd的控制。

　　從設計構思上說，由於SystemD使用了cgroup與fanotify等組件以實現其特性，所以只適用於Linux。有鑒於此，基於kFreeBSD分支的軟件源無法納入SystemD。

　　大多數主流發行版要麼已經采用 Systemd，要麼即將在下個發布中采用(如 Debian 和 Ubuntu)。在本教程中，我們使用 Fedora 21(該發行版已經是 Systemd 的優秀實驗場地)的一個預覽版進行演示，但不論您用哪個發行版，要用到的命令和注意事項都應該是一樣的。這是 Systemd 的一個加分點：它消除了不同發行版之間許多細微且瑣碎的區別。

　　在終端中輸入 ps ax | grep systemd，看到第一行，其中的數字 1 表示它的進程號是1，也就是說它是 Linux 內核發起的第一個程序。因此，內核一旦檢測完硬件並組織好了內存，就會運行 /usr/lib/systemd/systemd 可執行程序，這個程序會按順序依次發起其他程序。(在還沒有 Systemd 的日子裡，內核會去運行 /sbin/init，隨後這個程序會在名為 SysVinit 的系統中運行其余的各種啟動腳本。)

　　Systemd 的核心是一個叫單元 unit的概念，它是一些存有關於服務service(在運行在後台的程序)、設備、掛載點、和操作系統其他方面信息的配置文件。Systemd 的其中一個目標就是簡化這些事物之間的相互作用，因此如果你有程序需要在某個掛載點被創建或某個設備被接入後開始運行，Systemd 可以讓這一切正常運作起來變得相當容易。(在沒有 Systemd 的日子裡，要使用腳本來把這些事情調配好，那可是相當丑陋的。)要列出您 Linux 系統上的所有單元，輸入以下命令：

　　復制代碼

　　代碼如下:

　　systemctl list-unit-files

　　現在，systemctl 是與 Systemd 交互的主要工具，它有不少選項。在單元列表中，您會注意到這兒有一些格式化：被使能enabled的單元顯示為綠色，被禁用disabled的顯示為紅色。標記為“static”的單元不能直接啟用，它們是其他單元所依賴的對象。若要限制輸出列表只包含服務，使用以下命令：

　　復制代碼

　　代碼如下:

　　systemctl list-unit-files --type=service

　　注意，一個單元顯示為“enabled”，並不等於對應的服務正在運行，而只能說明它可以被開啟。要獲得某個特定服務的信息，以 GDM (Gnome Display Manager) 為例，輸入以下命令：

　　復制代碼

　　代碼如下:

　　systemctl status gdm.service

　　這條命令提供了許多有用的信息：一段給人看的服務描述、單元配置文件的位置、啟動的時間、進程號，以及它所從屬的 CGroups(用以限制各組進程的資源開銷)。

　　如果您去查看位於 /usr/lib/systemd/system/gdm.service 的單元配置文件，您可以看到各種選項，包括要被運行的二進制文件(“ExecStart”那一行)，相沖突的其他單元(即不能同時進入運行的單元)，以及需要在本單元執行前進入運行的單元(“After”那一行)。一些單元有附加的依賴選項，例如“Requires”(必要的依賴)和“Wants”(可選的依賴)。

　　此處另一個有趣的選項是：

　　復制代碼

　　代碼如下:

　　Alias=display-manager.service

　　當您啟動 gdm.service 後，您將可以通過 systemctl status display-manager.service 來查看它的狀態。當您知道有顯示管理程序 display manager在運行並想對它做點什麼，但您不關心那究竟是 GDM，KDM，XDM 還是什麼別的顯示管理程序時，這個選項會非常有用。

　　“目標target”鎖定

　　如果您在 /usr/lib/systemd/system 目錄中輸入 ls 命令，您將看到各種以 .target 結尾的文件。啟動目標 target是一種將多個單元聚合在一起以致於將它們同時啟動的方式。例如，對大多數類 Unix 操作系統而言有一種“多用戶multi-user”狀態，意思是系統已被成功啟動，後台服務正在運行，並且已准備好讓一個或多個用戶登錄並工作——至少在文本模式下。(其他狀態包括用於進行管理工作的單用戶single-user狀態，以及用於機器關機的重啟reboot狀態。)

　　如果您打開 multi-user.target 文件一探究竟，您可能期待看到的是一個要被啟動的單元列表。但您會發現這個文件內部幾乎空空如也——其實，一個服務會通過 WantedBy 選項讓自己成為啟動目標的依賴。因此如果您去打開 avahi-daemon.service, NetworkManager.service 及其他 .service 文件看看，您將在 Install 段看到這一行：

　　復制代碼

　　代碼如下:

　　WantedBy=multi-user.target

　　因此，切換到多用戶啟動目標會使能enable那些包含上述語句的單元。還有其他一些啟動目標可用(例如 emergency.target 提供一個緊急情況使用的 shell，以及 halt.target 用於機器關機)，您可以用以下方式輕松地在它們之間切換：

　　復制代碼

　　代碼如下:

　　systemctl isolate emergency.target

　　在許多方面，這些都很像 SysVinit 中的運行級 runlevel，如文本模式的 multi-user.target 類似於第3運行級，graphical.target 類似於第5運行級，reboot.target 類似於第6運行級，諸如此類。

　　開啟與停止

　　現在您也許陷入了沉思：我們已經看了這麼多，但仍沒看到如何停止和開啟服務!這其實是有原因的。從外部看，Systemd 也許很復雜，像野獸一般難以駕馭。因此在您開始擺弄它之前，有必要從宏觀的角度看看它是如何工作的。實際用來管理服務的命令非常簡單：

　　復制代碼

　　代碼如下:

　　systemctl stop cups.service

　　systemctl start cups.service

　　(若某個單元被禁用了，您可以先通過 systemctl enable 加上該單元名的方式將其使能。這種做法會為該單元創建一個符號鏈接，並將其放置在當前啟動目標的 .wants 目錄下，這些 .wants 目錄在/etc/systemd/system 文件夾中。)

　　還有兩個有用的命令是 systemctl restart 和 systemctl reload，後面接單元名。後者用於讓單元重新加載它的配置文件。Systemd 的絕大部分都有良好的文檔，因此您可以查看手冊 (man systemctl) 了解每條命令的細節。

　　定時器單元：取代 Cron

　　除了系統初始化和服務管理，Systemd 還染指了其他方面。在很大程度上，它能夠完成 cron 的工作，而且可以說是以更靈活的方式(並帶有更易讀的語法)。cron 是一個以規定時間間隔執行任務的程序——例如清除臨時文件，刷新緩存等。

　　如果您再次進入 /usr/lib/systemd/system 目錄，您會看到那兒有多個 .timer 文件。用 less 來查看這些文件，您會發現它們與 .service 和 .target 文件有著相似的結構，而區別在於 [Timer] 段。舉個例子：

　　復制代碼

　　代碼如下:

　　[Timer]

　　OnBootSec=1h

　　OnUnitActiveSec=1w

　　OnBootSec 選項告訴 Systemd 在系統啟動一小時後啟動這個單元。第二個選項的意思是：自那以後每周啟動這個單元一次。關於定時器有大量選項您可以設置，輸入 man systemd.time 查看完整列表。

　　Systemd 的時間精度默認為一分鐘。也就是說，它會在設定時刻的一分鐘內運行單元，但不一定精確到那一秒。這麼做是基於電源管理方面的原因，但如果您需要一個沒有任何延時且精確到毫秒的定時器，您可以添加以下一行：

　　復制代碼

　　代碼如下:

　　AccuracySec=1us

　　另外， WakeSystem 選項(可以被設置為 true 或 false)決定了定時器是否可以喚醒處於休眠狀態的機器。

　　日志文件：向 journald 問聲好

　　Systemd 的第二個主要部分是 journal 。這是個日志系統，類似於 syslog 但也有些顯著區別。如果您是個 Unix 日志管理模式的粉絲，准備好出離憤怒吧：這是個二進制日志，因此您不能使用常規的命令行文本處理工具來解析它。這個設計決定不出意料地在網上引起了激烈的爭論，但它的確有些優點。例如，日志可以被更系統地組織，帶有更多的元數據，因此可以更容易地根據可執行文件名和進程號等過濾出信息。

　　要查看整個 journal，輸入以下命令：

　　復制代碼

　　代碼如下:

　　journalctl

　　像許多其他的 Systemd 命令一樣，該命令將輸出通過管道的方式引向 less 程序，因此您可以使用空格鍵向下滾動，鍵入/(斜槓)查找，以及其他熟悉的快捷鍵。您也能在此看到少許顏色，像紅色的警告及錯誤信息。

　　以上命令會輸出很多信息。為了限制其只輸出本次啟動的消息，使用如下命令：

　　復制代碼

　　代碼如下:

　　journalctl -b

　　這就是 Systemd 大放異彩的地方!您想查看自上次啟動以來的全部消息嗎?試試 journalctl -b -1 吧。再上一次的?用 -2 替換 -1 吧。那自某個具體時間，例如2014年10月24日16:38以來的呢?

　　復制代碼

　　代碼如下:

　　journalctl -b --since=”2014-10-24 16:38”

　　即便您對二進制日志感到遺憾，那依然是個有用的特性，並且對許多系統管理員來說，構建類似的過濾器比起寫正則表達式而言容易多了。

　　我們已經可以根據特定的時間來准確查找日志了，那可以根據特定程序嗎?對單元而言，試試這個：

　　復制代碼

　　代碼如下:

　　journalctl -u gdm.service

　　(注意：這是個查看 X server 產生的日志的好辦法。)那根據特定的進程號?

　　復制代碼

　　代碼如下:

　　journalctl _PID=890

　　您甚至可以請求只看某個可執行文件產生的消息：

　　復制代碼

　　代碼如下:

　　journalctl /usr/bin/pulseaudio

　　若您想將輸出的消息限制在某個優先級，可以使用 -p 選項。該選項參數為 0 的話只會顯示緊急消息(也就是說，是時候向 $DEITY 祈求保佑了)(LCTT 譯注： $DEITY 是一個計算機方面的幽默，DEITY 是指廣義上的“神”，$前綴表示這是一個變量)，為 7 的話會顯示所有消息，包括調試消息。請查看手冊 (man journalctl) 獲取更多關於優先級的信息。

　　值得指出的是，您也可以將多個選項結合在一起，若想查看在當前啟動中由 GDM 服務輸出的優先級數小於等於 3 的消息，請使用下述命令：

　　復制代碼

　　代碼如下:

　　journalctl -u gdm.service -p 3 -b

　　最後，如果您僅僅想打開一個隨 journal 持續更新的終端窗口，就像在沒有 Systemd 時使用 tail 命令實現的那樣，輸入 journalctl -f 就好了。

　　沒有 Systemd 的生活?

　　如果您就是完全不能接受 Systemd，您仍然有一些主流發行版中的選擇。尤其是 Slackware，作為歷史最為悠久的發行版，目前還沒有做出改變，但它的主要開發者並沒有將其從未來規劃中移除。一些不出名的發行版也在堅持使用 SysVinit 。

　　但這又將持續多久呢?Gnome 正越來越依賴於 Systemd，其他的主流桌面環境也會步其後塵。這也是引起 BSD 社區一陣恐慌的原因：Systemd 與 Linux 內核緊密相連，導致在某種程度上，桌面環境正變得越來越不可移植。一種折衷的解決方案也許會以 Uselessd (http://uselessd.darknedgy.net) 的形式到來：一種裁剪版的 Systemd，純粹專注於啟動和監控進程，而不消耗整個基礎系統。