目錄

一、Systemd概述

二、Systemd優勢

2.1兼容性

2.2啟動速度

2.3systemd 提供按需啟動能力

2.4采用 linux 的 cgroups 跟蹤和管理進程的生命周期

2.5啟動掛載點和自動掛載的管理

2.6實現事務性依賴關系管理

2.7日志服務

2.8 依賴關系

2.9systemd 事務

三、unit(單元)

四、systemd和systemctl

---

一、Systemd概述

---

? ? ? ?關于 systemd 的起源，首先要從 Linux 的 init 程序說起。Linux 系統在啟動過程中，內核完成初始化以后，由內核第一個啟動的程序便是 init 程序，路徑為 /sbin/init（為一個軟連接，鏈接到真實的 init 進程），其 PID 為1，它為系統里所有進程的“祖先”，Linux 中所有的進程都由 init 進程直接或間接進行創建并運行，init 進程以守護進程的方式存在，負責組織與運行系統的相關初始化工作，讓系統進入定義好的運行模式，如命令行模式或圖形界面模式。

init 程序的發展，大體上可分為三個階段：sysvinit->upstart->systemd，根據 init 進程的發展特性，可以簡單理解為如下：

sysvinit：init 系統通過 shell 腳本以串行的方式啟動系統服務，下一個進程必須等待上一個進程啟動完成后才能開始啟動，因此系統啟動的過程比較慢。

upstart：在 sysvinit 的基礎上，把一些沒有關聯的程序并行啟動，以提高啟動的速度，但是存在依賴關系的程序仍然為串行啟動。

systemd：通過套接字激活的機制，讓所有無論有無依賴關系的程序全部并行啟動，并且僅按照系統啟動的需要啟動相應的服務，最大化提高開機啟動速度。

? ? ? ? systemd 是 linux 系統中最新的初始化系統(init)，它主要的設計目標是克服 sysvinit 固有的缺點，提高系統的啟動速度。systemd 和 ubuntu 的 upstart 是競爭對手，但是時至今日 ubuntu 也采用了 systemd，所以 systemd 在競爭中勝出，大有一統天下的趨勢。目前主流的系統中，systemd 的守護進程主要分為系統態(system)與用戶態(user)，可以在 ps -ef 中看到 systemd 的守護進程，如下：

? ? ?PID 為1的進程/sbin/init 即是 system 態的 systemd，它為一個軟鏈接，指向真實的 systemd 路徑，在操作系統中一般放在/usr/lib/systemd/目錄：

? ? ? ?systemd 為進程服務集合的總稱，它包含許多的進程，負責控制、管理系統的資源，其中包括 systemd-login，負責用戶登錄相關信息的創建、修改與刪除；systemd-sleep 控制系統的休眠、睡眠狀態切換等等。在優麒麟操作系統下，它們主要集中在/usr/lib/systemd/文件目錄

---

二、Systemd優勢

---

2.1兼容性

systemd 提供了和 sysvinit 兼容的特性。系統中已經存在的服務和進程無需修改。這降低了系統向 systemd 遷移的成本，使得 systemd 替換現有初始化系統成為可能。

2.2啟動速度

systemd 提供了比 upstart 更激進的并行啟動能力，采用了 socket / D-Bus activation 等技術啟動服務。一個顯而易見的結果就是：更快的啟動速度。為了減少系統啟動時間，systemd 的目標是：

• 盡可能啟動更少的進程
• 盡可能將更多進程并行啟動

2.3systemd 提供按需啟動能力

當 sysvinit 系統初始化的時候，它會將所有可能用到的后臺服務進程全部啟動運行。并且系統必須等待所有的服務都啟動就緒之后，才允許用戶登錄。這種做法有兩個缺點：首先是啟動時間過長，其次是系統資源浪費。

某些服務很可能在很長一段時間內，甚至整個服務器運行期間都沒有被使用過。比如 CUPS，打印服務在多數服務器上很少被真正使用到。您可能沒有想到，在很多服務器上 SSHD 也是很少被真正訪問到的。花費在啟動這些服務上的時間是不必要的；同樣，花費在這些服務上的系統資源也是一種浪費。

systemd 可以提供按需啟動的能力，只有在某個服務被真正請求的時候才啟動它。當該服務結束，systemd 可以關閉它，等待下次需要時再次啟動它。
這有點類似于以前系統中的 inetd，并且有很多文章介紹如何把過去 inetd 管理的服務遷移到 systemd。

2.4采用 linux 的 cgroups 跟蹤和管理進程的生命周期

systemd 利用了 Linux 內核的特性即 cgroups 來完成跟蹤的任務。當停止服務時，通過查詢 cgroups ，systemd 可以確保找到所有的相關進程，從而干凈地停止服務。
cgroups 已經出現了很久，它主要用來實現系統資源配額管理。cgroups 提供了類似文件系統的接口，使用方便。當進程創建子進程時，子進程會繼承父進程的 cgroups 。因此無論服務如何啟動新的子進程，所有的這些相關進程都會屬于同一個 cgroups ，systemd 只需要簡單地遍歷指定的 cgroups 即可正確地找到所有的相關進程，將它們一一停止即可。

2.5啟動掛載點和自動掛載的管理

傳統的 linux 系統中，用戶可以用 /etc/fstab 文件來維護固定的文件系統掛載點。這些掛載點在系統啟動過程中被自動掛載，一旦啟動過程結束，這些掛載點就會確保存在。這些掛載點都是對系統運行至關重要的文件系統，比如 HOME 目錄。和 sysvinit 一樣，Systemd 管理這些掛載點，以便能夠在系統啟動時自動掛載它們。systemd 還兼容 /etc/fstab 文件，您可以繼續使用該文件管理掛載點。

有時候用戶還需要動態掛載點，比如打算訪問 DVD 或者 NFS 共享的內容時，才臨時執行掛載以便訪問其中的內容，而不訪問光盤時該掛載點被取消(umount)，以便節約資源。傳統地，人們依賴 autofs 服務來實現這種功能。
systemd 內建了自動掛載服務，無需另外安裝 autofs 服務，可以直接使用 systemd 提供的自動掛載管理能力來實現 autofs 的功能。

2.6實現事務性依賴關系管理

系統啟動過程是由很多的獨立工作共同組成的，這些工作之間可能存在依賴關系，比如掛載一個 NFS 文件系統必須依賴網絡能夠正常工作。systemd 雖然能夠最大限度地并發執行很多有依賴關系的工作，但是類似"掛載 NFS"和"啟動網絡"這樣的工作還是存在天生的先后依賴關系，無法并發執行。對于這些任務，systemd 維護一個"事務一致性"的概念，保證所有相關的服務都可以正常啟動而不會出現互相依賴，以至于死鎖的情況。

2.7日志服務

systemd 自帶日志服務 journald，該日志服務的設計初衷是克服現有的 syslog 服務的缺點。比如：

• syslog 不安全，消息的內容無法驗證。每一個本地進程都可以聲稱自己是 Apache PID 4711，而 syslog 也就相信并保存到磁盤上。
• 數據沒有嚴格的格式，非常隨意。自動化的日志分析器需要分析人類語言字符串來識別消息。一方面此類分析困難低效；此外日志格式的變化會導致分析代碼需要更新甚至重寫。

systemd journal 用二進制格式保存所有日志信息，用戶使用 journalctl 命令來查看日志信息。無需自己編寫復雜脆弱的字符串分析處理程序。

systemd journal 的優點如下：
簡單性：代碼少，依賴少，抽象開銷最小。
零維護：日志是除錯和監控系統的核心功能，因此它自己不能再產生問題。舉例說，自動管理磁盤空間，避免由于日志的不斷產生而將磁盤空間耗盡。
移植性：日志文件應該在所有類型的 Linux 系統上可用，無論它使用的何種 CPU 或者字節序。
性能：添加和瀏覽日志非?？?。
最小資源占用：日志數據文件需要較小。
統一化：各種不同的日志存儲技術應該統一起來，將所有的可記錄事件保存在同一個數據存儲中。所以日志內容的全局上下文都會被保存并且可供日后查詢。例如一條固件記錄后通常會跟隨一條內核記錄，最終還會有一條用戶態記錄。重要的是當保存到硬盤上時這三者之間的關系不會丟失。syslog 將不同的信息保存到不同的文件中，分析的時候很難確定哪些條目是相關的。
擴展性：日志的適用范圍很廣，從嵌入式設備到超級計算機集群都可以滿足需求。
安全性：日志文件是可以驗證的，讓無法檢測的修改不再可能。

在了解了 systemd 的種種優勢之后讓我們開始認識它的一些基本概念。

2.8 依賴關系

雖然 systemd 將大量的啟動工作解除了依賴，使得它們可以并發啟動。但還是存在有些任務，它們之間存在天生的依賴，不能用"套接字激活"(socket activation)、D-Bus activation 和 autofs 三大方法來解除依賴。比如：掛載必須等待掛載點在文件系統中被創建；掛載也必須等待相應的物理設備就緒。為了解決這類依賴問題，systemd 的配置單元之間可以彼此定義依賴關系。Systemd 用配置單元定義文件中的關鍵字來描述配置單元之間的依賴關系。比如：unit A 依賴 unit B，可以在 unit B 的定義中用"require A"來表示。這樣 systemd 就會保證先啟動 A 再啟動 B。

2.9systemd 事務

systemd 能保證事務完整性。Systemd 的事務概念和數據庫中的有所不同，主要是為了保證多個依賴的配置單元之間沒有環形引用。比如存在 unit A、B、C，假如它們的依賴關系如下(此圖來自互聯網)：

存在循環依賴，那么 systemd 將無法啟動任意一個服務。此時 systemd 將會嘗試解決這個問題，因為配置單元之間的依賴關系有兩種：required 是強依賴；want 則是弱依賴，systemd 將去掉 wants 關鍵字指定的依賴看看是否能打破循環。如果無法修復，systemd 會報錯。systemd 能夠自動檢測和修復這類配置錯誤，從而極大地減輕了管理員的排錯負擔。

---

三、unit(單元)

---

系統初始化需要做的事情非常多。需要啟動后臺服務，比如啟動 ssh 服務；需要做配置工作，比如掛載文件系統。這個過程中的每一步都被 systemd 抽象為一個配置單元，即 unit。可以認為一個服務是一個配置單元，一個掛載點是一個配置單元，一個交換分區的配置是一個配置單元等等。systemd 將配置單元歸納為以下一些不同的類型。然而，systemd 正在快速發展，新功能不斷增加。所以配置單元類型可能在不久的將來繼續增加。下面是一些常見的 unit 類型：

? ? ? ?service ：代表一個后臺服務進程，比如 MySQLd。這是最常用的一類。
? ? ? ?socket ：此類配置單元封裝系統和互聯網中的一個套接字 。當下，systemd 支持流式、數據報和 連續包的 AF_INET、AF_INET6、AF_UNIX socket 。每一個套接字配置單元都有一個相應的服務配置單元 。相應的服務在第一個"連接"進入套接字時就會啟動(例如：nscd.socket 在有新連接后便啟動 nscd.service)。
? ? ? ?device ：此類配置單元封裝一個存在于 Linux 設備樹中的設備。每一個使用 udev 規則標記的設備都將會在 systemd 中作為一個設備配置單元出現。
? ? ? ?mount ：此類配置單元封裝文件系統結構層次中的一個掛載點。Systemd 將對這個掛載點進行監控和管理。比如可以在啟動時自動將其掛載；可以在某些條件下自動卸載。Systemd 會將? /etc/fstab 中的條目都轉換為掛載點，并在開機時處理。
? ? ? ?automount ：此類配置單元封裝系統結構層次中的一個自掛載點。每一個自掛載配置單元對應一個掛載配置單元 ，當該自動掛載點被訪問時，systemd 執行掛載點中定義的掛載行為。

? ? ? swap：和掛載配置單元類似，交換配置單元用來管理交換分區。用戶可以用交換配置單元來定義系統中的交換分區，可以讓這些交換分區在啟動時被激活。
? ? ? target ：此類配置單元為其他配置單元進行邏輯分組。它們本身實際上并不做什么，只是引用其他配置單元而已。這樣便可以對配置單元做一個統一的控制。這樣就可以實現大家都已經非常熟悉的運行級別概念。比如想讓系統進入圖形化模式，需要運行許多服務和配置命令，這些操作都由一個個的配置單元表示，將所有這些配置單元組合為一個目標(target)，就表示需要將這些配置單元全部執行一遍以便進入目標所代表的系統運行狀態。 (例如：multi-user.target 相當于在傳統使用 SysV 的系統中運行級別 5)
? ? ? ? timer：定時器配置單元用來定時觸發用戶定義的操作，這類配置單元取代了 atd、crond 等傳統的定時服務。
? ? ? ?snapshot ：與 target 配置單元相似，快照是一組配置單元。它保存了系統當前的運行狀態。
path：文件系統中的一個文件或目錄。
scope：用于 cgroups，表示從 systemd 外部創建的進程。
slice：用于 cgroups，表示一組按層級排列的單位。slice 并不包含進程，但會組建一個層級，并將 scope 和 service 都放置其中。

? ? ? ? 每個配置單元都有一個對應的配置文件，系統管理員的任務就是編寫和維護這些不同的配置文件，比如一個 MySQL 服務對應一個 mysql.service 文件。這種配置文件的語法非常簡單，用戶不需要再編寫和維護復雜的系統腳本了。

下面是 docker.service

[root@k8s-master ~]# cat /usr/lib/systemd/system/docker.service [Unit] Description=Docker Application Container Engine Documentation=https://docs.docker.com BindsTo=containerd.service After=network-online.target firewalld.service containerd.service Wants=network-online.target Requires=docker.socket[Service] Type=notify # the default is not to use systemd for cgroups because the delegate issues still # exists and systemd currently does not support the cgroup feature set required # for containers run by docker ExecStart=/usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock ExecReload=/bin/kill -s HUP $MAINPID TimeoutSec=0 RestartSec=2 Restart=always# Note that StartLimit* options were moved from "Service" to "Unit" in systemd 229. # Both the old, and new location are accepted by systemd 229 and up, so using the old location # to make them work for either version of systemd. StartLimitBurst=3# Note that StartLimitInterval was renamed to StartLimitIntervalSec in systemd 230. # Both the old, and new name are accepted by systemd 230 and up, so using the old name to make # this option work for either version of systemd. StartLimitInterval=60s# Having non-zero Limit*s causes performance problems due to accounting overhead # in the kernel. We recommend using cgroups to do container-local accounting. LimitNOFILE=infinity LimitNPROC=infinity LimitCORE=infinity# Comment TasksMax if your systemd version does not supports it. # Only systemd 226 and above support this option. TasksMax=infinity# set delegate yes so that systemd does not reset the cgroups of docker containers Delegate=yes# kill only the docker process, not all processes in the cgroup KillMode=process[Install] WantedBy=multi-user.target

• Unit 段：此部分所有 Unit 文件通用，用來定義 Unit 的元數據、配置以及與其他 Unit 的關系，Description 描述 Unit 文件信息，Documentation 表示指定服務的文檔，Condition 表示服務啟動的條件，有些 Unit 還包含 wants、before、after、require 字段，這些表示服務的一個依賴關系。
• Install 段：此部分所有 Unit 文件通用，通常指定運行目標的 target，使得服務在系統啟動時自動運行。Wantedby、RequiredBy 與 Unit 段 Wants 字段類似，表示依賴關系，Alias 字段表示啟動運行時使用的別名。
• service 段：服務（Service）類型的 Unit 文件特有的字段，用于定義服務的具體管理和執行動作。其中包括 Type 字段，定義進程的行為，例如使用 fork()啟動，使用 dbus 啟動等等；ExecStart、ExecStartPre、ExecStartPos、ExecReload、ExecStop 分別表示啟動當前服務執行的命令、啟動當前服務之前執行的命令、啟動當前服務之后啟動的命令、重啟當前服務時執行的命令、停止當前服務時執行的命令。以上圖為例，啟動藍牙服務所需要執行的命令為/usr/lib/bluetooth/bluetoothd。

對于systemd的所有詳細啟動順序情況，我們可以使用systemd本身自帶的systemd-anlyze，它是一個分析啟動性能的工具，

[root@k8s-master1 ~]# systemd-analyze --help systemd-analyze [OPTIONS...] {COMMAND} ...Profile systemd, show unit dependencies, check unit files.-h --help Show this help--version Show package version--no-pager Do not pipe output into a pager--system Operate on system systemd instance-H --host=[USER@]HOST Operate on remote host-M --machine=CONTAINER Operate on local container--order Show only order in the graph--require Show only requirement in the graph--from-pattern=GLOB Show only origins in the graph--to-pattern=GLOB Show only destinations in the graph--fuzz=SECONDS Also print also services which finished SECONDSearlier than the latest in the branch--man[=BOOL] Do [not] check for existence of man pagesCommands:time Print time spent in the kernelblame Print list of running units ordered by time to initcritical-chain Print a tree of the time critical chain of unitsplot Output SVG graphic showing service initializationdot Output dependency graph in dot(1) formatset-log-level LEVEL Set logging threshold for systemddump Output state serialization of service managerverify FILE... Check unit files for correctness

系統啟動時間

[root@k8s-master ~]# systemd-analyze Startup finished in 3.099s (kernel) + 3.536s (initrd) + 18.010s (userspace) = 24.646s [root@k8s-master ~]#

打印上次開機時的所有服務,并顯示服務耗時

給出的樹形關鍵路徑就是該unit的最長耗時路徑.

?systemd-analyze plot > boot.svg

詳細的systemd啟動流程,直到graphical.target. 將boot.svg拖入瀏覽器顯示如下

?

---

四、systemd和systemctl

---

? ? ? ?提到systemctl就一定需要知道systemd，因為Linux 服務管理有兩種方式service和systemctl。而systemd是Linux系統最新的初始化系統(init)，作用是提高系統的啟動速度，盡可能啟動較少的進程，盡可能更多進程并發啟動，systemd對應的進程管理命令就是systemctl。值得一提的是，systemctl命令兼容了service哦。

這里咱們梳理一下systemd這個啟動服務管理機制有哪些好處（也就是使用systemctl相關命令的好處啦）。

? ? ? ? 平行處理所有服務，加速開機流程：舊的init啟動腳本（System V的那個）是“一項一項任務依序啟動”的模式，因此不相依的服務也是得要一個一個的等待。而systemd可以讓所有的服務同時啟動，畢竟目前我們的硬件主機系統與操作系統幾乎都支持多核心架構，因此你會發現到，系統啟動的速度變快了；
? ? ? ?一經請求就響應的on-demand啟動方式：systemd僅有一只systemd服務搭配systemctl指令進行處理，無須其他額外的指令來支持。不像systemV還要init，chkconfig，service...等等指令。此外，systemd由于常駐內存，因此任何請求（on-demand）都可以立即處理后續的daemon啟動的任務；
? ? ? 服務關聯性的自我檢查：由于systemd可以自行進行服務關聯性的檢查，因此如果B服務的啟動前提是A服務，那當你在沒有啟動A服務的情況下僅手動啟動B服務時，systemd會自動幫你啟動A服務；
? ? ? ?根據daemon功能分類：systemd旗下管理的服務非常多，為了理清所有服務的功能，因此，首先systemd先定義所有的服務為一個服務單位（這里單位叫“unit”，挺重要的，后面詳細說），并將該unit分類到不同的服務類型（type）中。systemd將服務單位（unit）區分為service，socket，target，path，snapshot，timer等多種不同的類型（type）；
? ? ? 將多個daemons集合成為一個群組：systemd將許多的功能集合成為一個所謂的target項目，這個項目主要用于設計操作環境的創建，所以集合了許多的daemons（執行某個target就是執行多個daemon）；
? ? ? ?向下兼容容舊有的init服務腳本：基本上，systemd是可以兼容init的啟動腳本，因此，舊的init啟動腳本也能夠通過systemd來管理，當然了，這里僅限于不使用systemd的某些高級功能；
————————————————

reference:

干貨分享 | Systemd 技術原理&實踐（上） - 知乎

關于 systemd 的初步理解_Linux教程_Linux公社-Linux系統門戶網站???????

?

總結

以上是生活随笔為你收集整理的Linux-Systemd的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。