1. 概述

Systemd 是一系列工具的集合，其作用也遠遠不僅是啟動操作系統，它還接管了后臺服務、結束、狀態查詢，以及日志歸檔、設備管理、電源管理、定時任務等許多職責，并支持通過特定事件（如插入特定 USB 設備）和特定端口數據觸發的 On-demand（按需）任務。

Systemd 的后臺服務還有一個特殊的身份——它是系統中 PID 值為 1 的進程。

主要功能：支持并行化任務；同時采用 socket 式與 D-Bus 總線式激活服務；按需啟動守護進程（daemon）；利用 Linux 的 cgroups 監視進程；支持快照和系統恢復；維護掛載點和自動掛載點；各服務間基于依賴關系進行精密控制。systemd 支持 SysV 和 LSB 初始腳本，可以替代 sysvinit。除此之外，功能還包括日志進程、控制基礎系統配置，維護登陸用戶列表以及系統賬戶、運行時目錄和設置，可以運行容器和虛擬機，可以簡單的管理網絡配置、網絡時間同步、日志轉發和名稱解析等。

整體架構：

2. Unit

2.1 定義及類型

Systemd 可以管理所有系統資源，不同的資源統稱為Unit（單位）。在Systemd的生態圈中，Unit文件統一了過去各種不同系統資源配置格式，例如服務的啟/停、定時任務、設備自動掛載、網絡配置、虛擬內存配置等。而?Systemd 通過不同的文件后綴來區分這些配置文件。Unit 是 Systemd 管理系統資源的基本單元，可以認為每個系統資源就是一個 Unit，并使用一個 Unit 文件定義。在 Unit 文件中需要包含相應服務的描述、屬性以及需要運行的命令。Target 是 Systemd 中用于指定系統資源啟動組的方式，相當于 SysV-init 中的運行級別。簡單說，Target 就是一個 Unit 組，包含許多相關的 Unit 。啟動某個 Target 的時候，Systemd 就會啟動里面所有的 Unit。從這個意義上說，Target 這個概念類似于”狀態點”，啟動某個 Target 就好比啟動到某種狀態。

12 種 Unit 文件類型：

• .automount：用于控制自動掛載文件系統，相當于 SysV-init 的 autofs 服務
• .device：對于 /dev 目錄下的設備，主要用于定義設備之間的依賴關系
• .mount：定義系統結構層次中的一個掛載點，可以替代過去的 /etc/fstab 配置文件
• .path：用于監控指定目錄或文件的變化，并觸發其它 Unit 運行
• .scope：這種 Unit 文件不是用戶創建的，而是 Systemd 運行時產生的，描述一些系統服務的分組信息
• .service：封裝守護進程的啟動、停止、重啟和重載操作，是最常見的一種 Unit 文件
• .slice：用于表示一個 CGroup 的樹，通常用戶不會自己創建這樣的 Unit 文件
• .snapshot：用于表示一個由 systemctl snapshot 命令創建的 Systemd Units 運行狀態快照
• .socket：監控來自于系統或網絡的數據消息，用于實現基于數據自動觸發服務啟動
• .swap：定義一個用戶做虛擬內存的交換分區
• .target：用于對 Unit 文件進行邏輯分組，引導其它 Unit 的執行。它替代了 SysV-init 運行級別的作用，并提供更靈活的基于特定設備事件的啟動方式
• .timer：用于配置在特定時間觸發的任務，替代了 Crontab 的功能

2.2 Systemd 目錄

Unit 文件按照 Systemd 約定，應該被放置指定的三個系統目錄之一中。這三個目錄是有優先級的，如下所示，越靠上的優先級越高。因此，在三個目錄中有同名文件的時候，只有優先級最高的目錄里的那個文件會被使用。

• /etc/systemd/system：系統或用戶自定義的配置文件
• /run/systemd/system：軟件運行時生成的配置文件
• /usr/lib/systemd/system：系統或第三方軟件安裝時添加的配置文件

Systemd 默認從目錄 /etc/systemd/system/ 讀取配置文件。但是，里面存放的大部分文件都是符號鏈接，指向目錄 /usr/lib/systemd/system/，真正的配置文件存放在那個目錄。

systemd 單元名僅能包含 ASCII 字符，下劃線和點號和有特殊意義的字符(’@’, ‘-’)。其它字符需要用 C-style “\x2d” 替換。參閱 systemd.unit(5) 和 systemd-escape(1) 。單元文件的語法，可以參考系統已經安裝的單元，也可以參考 systemd.service(5) 中的EXAMPLES章節。（在終端中運行：man 5 systemd.unit，man 1 systemd-escape 等查看）

提示： 以 # 開頭的注釋可能也能用在 unit-files 中，但是只能在新行中使用。不要在 systemd 的參數后面使用行末注釋， 否則 unit 將會啟動失敗。

2.3 Unit文件結構

[Unit]
Description=Hello World
After=docker.service
Requires=docker.service
[Service]
TimeoutStartSec=0
ExecStartPre=-/usr/bin/docker kill busybox1
ExecStartPre=-/usr/bin/docker rm busybox1
ExecStartPre=/usr/bin/docker pull busybox
ExecStart=/usr/bin/docker run --name busybox1 busybox /bin/ sh -c "while true; do echo Hello World; sleep 1; done"
ExecStop="/usr/bin/docker stop busybox1"
ExecStopPost="/usr/bin/docker rm busybox1"
[Install]
WantedBy=multi-user.target

Systemd 服務的 Unit 文件可以分為三個配置區段：

• Unit 和 Install 段：所有 Unit 文件通用，用于配置服務（或其它系統資源）的描述、依賴和隨系統啟動的方式
• Service 段：服務（Service）類型的 Unit 文件（后綴為 .service）特有的，用于定義服務的具體管理和操作方法

1）Unit 段

• Description：描述這個 Unit 文件的信息
• Documentation：指定服務的文檔，可以是一個或多個文檔的 URL 路徑
• Requires：依賴的其它 Unit 列表，列在其中的 Unit 模板會在這個服務啟動時的同時被啟動。并且，如果其中任意一個服務啟動失敗，這個服務也會被終止
• Wants：與 Requires 相似，但只是在被配置的這個 Unit 啟動時，觸發啟動列出的每個 Unit 模塊，而不去考慮這些模板啟動是否成功
• After：與 Requires 相似，但是在后面列出的所有模塊全部啟動完成以后，才會啟動當前的服務
• Before：與 After 相反，在啟動指定的任務一個模塊之間，都會首先確證當前服務已經運行
• Binds To：與 Requires 相似，失敗時失敗，成功時成功，但是在這些模板中有任意一個出現意外結束或重啟時，這個服務也會跟著終止或重啟
• Part Of：一個 Bind To 作用的子集，僅在列出的任務模塊失敗或重啟時，終止或重啟當前服務，而不會隨列出模板的啟動而啟動
• OnFailure：當這個模板啟動失敗時，就會自動啟動列出的每個模塊
• Conflicts：與這個模塊有沖突的模塊，如果列出的模塊中有已經在運行的，這個服務就不能啟動，反之亦然

2）Install 段

這部分配置的目標模塊通常是特定運行目標的 .target 文件，用來使得服務在系統啟動時自動運行。這個區段可以包含三種啟動約束：

• WantedBy：和 Unit 段的 Wants 作用相似，只有后面列出的不是服務所依賴的模塊，而是依賴當前服務的模塊。它的值是一個或多個 Target，當前 Unit 激活時（enable）符號鏈接會放入 /etc/systemd/system 目錄下面以 <Target 名> + .wants 后綴構成的子目錄中，如 “/etc/systemd/system/multi-user.target.wants/“
• RequiredBy：和 Unit 段的 Wants 作用相似，只有后面列出的不是服務所依賴的模塊，而是依賴當前服務的模塊。它的值是一個或多個 Target，當前 Unit 激活時，符號鏈接會放入 /etc/systemd/system 目錄下面以 <Target 名> + .required 后綴構成的子目錄中
• Also：當前 Unit enable/disable 時，同時 enable/disable 的其他 Unit
• Alias：當前 Unit 可用于啟動的別名

3）Service 段

用來 Service 的配置，只有 Service 類型的 Unit 才有這個區塊。它的主要字段分為服務生命周期和服務上下文配置兩個方面。

（1）服務生命周期控制相關

• Type：定義啟動時的進程行為，它有以下幾種值：

? ? ? ? Type=simple：默認值，執行ExecStart指定的命令，啟動主進程
? ? ? ? Type=forking：以 fork 方式從父進程創建子進程，創建后父進程會立即退出
? ? ? ? Type=oneshot：一次性進程，Systemd 會等當前服務退出，再繼續往下執行
? ? ? ? Type=dbus：當前服務通過D-Bus啟動
? ? ? ? Type=notify：當前服務啟動完畢，會通知Systemd，再繼續往下執行
? ? ? ? Type=idle：若有其他任務執行完畢，當前服務才會運行

• RemainAfterExit：值為 true 或 false（默認）。當配置為 true 時，Systemd 只會負責啟動服務進程，之后即便服務進程退出了，Systemd 也仍然會認為這個服務還在運行中。這個配置主要是提供給一些并非常駐內存，而是啟動注冊后立即退出，然后等待消息按需啟動的特殊類型服務使用的。
• ExecStart：啟動當前服務的命令
• ExecStartPre：啟動當前服務之前執行的命令
• ExecStartPos：啟動當前服務之后執行的命令
• ExecReload：重啟當前服務時執行的命令
• ExecStop：停止當前服務時執行的命令
• ExecStopPost：停止當其服務之后執行的命令
• RestartSec：自動重啟當前服務間隔的秒數
• Restart：定義何種情況 Systemd 會自動重啟當前服務，可能的值包括 always（總是重啟）、on-success、on-failure、on-abnormal、on-abort、on-watchdog
• TimeoutStartSec：啟動服務時等待的秒數，這一配置對于使用 Docker 容器而言顯得尤為重要，因其第一次運行時可能需要下載鏡像，嚴重延時會容易被 Systemd 誤判為啟動失敗殺死。通常，對于這種服務，將此值指定為 0，從而關閉超時檢測
• TimeoutStopSec：停止服務時的等待秒數，如果超過這個時間仍然沒有停止，Systemd 會使用 SIGKILL 信號強行殺死服務的進程

（2）服務上下文配置相關

• Environment：為服務指定環境變量
• EnvironmentFile：指定加載一個包含服務所需的環境變量的列表的文件，文件中的每一行都是一個環境變量的定義
• Nice：服務的進程優先級，值越小優先級越高，默認為 0。其中 -20 為最高優先級，19 為最低優先級
• WorkingDirectory：指定服務的工作目錄
• RootDirectory：指定服務進程的根目錄（/ 目錄）。如果配置了這個參數，服務將無法訪問指定目錄以外的任何文件
• User：指定運行服務的用戶
• Group：指定運行服務的用戶組
• MountFlags：服務的 Mount Namespace 配置，會影響進程上下文中掛載點的信息，即服務是否會繼承主機上已有掛載點，以及如果服務運行執行了掛載或卸載設備的操作，是否會真實地在主機上產生效果。可選值為 shared、slaved 或 private。

? ? ? ? shared：服務與主機共用一個 Mount Namespace，繼承主機掛載點，且服務掛載或卸載設備會真實地反映到主機上
? ? ? ? slave：服務使用獨立的 Mount Namespace，它會繼承主機掛載點，但服務對掛載點的操作只有在自己的 Namespace 內生效，不會反映到主機上
? ? ? ? private：服務使用獨立的 Mount Namespace，它在啟動時沒有任何任何掛載點，服務對掛載點的操作也不會反映到主機上

• LimitCPU / LimitSTACK / LimitNOFILE / LimitNPROC 等：限制特定服務的系統資源量，例如 CPU、程序堆棧、文件句柄數量、子進程數量等

注意：如果在 ExecStart、ExecStop 等屬性中使用了 Linux 命令，則必須要寫出完整的絕對路徑。對于 ExecStartPre 和 ExecStartPost 輔助命令，若前面有個 “-” 符號，表示忽略這些命令的出錯。因為有些 “輔助” 命令本來就不一定成功，比如嘗試清空一個文件，但文件可能不存在。

2.4 Unit 文件占位符

在 Unit 文件中，有時會需要使用到一些與運行環境有關的信息，例如節點 ID、運行服務的用戶等。這些信息可以使用占位符來表示，然后在實際運行被動態地替換實際的值。

• %n：完整的 Unit 文件名字，包括 .service 后綴名
• %p：Unit 模板文件名中 @ 符號之前的部分，不包括 @ 符號
• %i：Unit 模板文件名中 @ 符號之后的部分，不包括 @ 符號和 .service 后綴名
• %t：存放系統運行文件的目錄，通常是 “run”
• %u：運行服務的用戶，如果 Unit 文件中沒有指定，則默認為 root
• %U：運行服務的用戶 ID
• %h：運行服務的用戶 Home 目錄，即 %{HOME} 環境變量的值
• %s：運行服務的用戶默認 Shell 類型，即 %{SHELL} 環境變量的值
• %m：實際運行節點的 Machine ID，對于運行位置每個的服務比較有用
• %b：Boot ID，這是一個隨機數，每個節點各不相同，并且每次節點重啟時都會改變
• %H：實際運行節點的主機名
• %v：內核版本，即 “uname -r” 命令輸出的內容
• %%：在 Unit 模板文件中表示一個普通的百分號

2.5 Unit 模板

在現實中，往往有一些應用需要被復制多份運行。例如，用于同一個負載均衡器分流的多個服務實例，或者為每個 SSH 連接建立一個獨立的 sshd 服務進程。

Unit 模板文件的寫法與普通的服務 Unit 文件基本相同，不過 Unit 模板的文件名是以 @ 符號結尾的。通過模板啟動服務實例時，需要在其文件名的 @ 字符后面附加一個參數字符串。

樣例：apache@.service

• apache@.service 模板

[Unit]
Description=My Advanced Service Template
After=etcd.service docker.service
[Service]
TimeoutStartSec=0
ExecStartPre=-/usr/bin/docker kill apache%i
ExecStartPre=-/usr/bin/docker rm apache%i
ExecStartPre=/usr/bin/docker pull coreos/apache
ExecStart=/usr/bin/docker run --name apache%i -p %i:80 coreos/apache /usr/sbin/apache2ctl -D FOREGROUND
ExecStartPost=/usr/bin/etcdctl set /domains/example.com/%H:%i running
ExecStop=/usr/bin/docker stop apache1
ExecStopPost=/usr/bin/docker rm apache1
ExecStopPost=/usr/bin/etcdctl rm /domains/example.com/%H:%i
[Install]
WantedBy=multi-user.target

• 啟動 Unit 模板的服務實例

在服務啟動時需要在 @ 后面放置一個用于區分服務實例的附加字符參數，通常這個參數用于監控的端口號或控制臺 TTY 編譯號。

systemctl start apache@8080.service

Systemd 在運行服務時，總是會先嘗試找到一個完整匹配的 Unit 文件，如果沒有找到，才會嘗試選擇匹配模板。例如上面的命令，System 首先會在約定的目錄下尋找名為 apache@8080.service 的文件，如果沒有找到，而文件名中包含 @ 字符，它就會嘗試去掉后綴參數匹配模板文件。對于 apache@8080.service，systemd 會找到 apache@.service 模板文件，并通過這個模板文件將服務實例化。

3. 命令工具

3.1 systemctl

systemctl是?Systemd 的主命令，用于管理系統。systemctl命令主要有兩大功能：控制systemd系統和管理系統上運行的服務。

通過?systemctl --help?可以查看到所有相關信息。

在?systemctl 參數中添加 -H <用戶名>@<主機名> 可以實現對其他機器的遠程控制。該功能使用 SSH 連接。

1）常用指令

# 列出正在運行的 Unit
$ systemctl list-units# 列出所有Unit，包括沒有找到配置文件的或者啟動失敗的
$ systemctl list-units --all# 列出所有沒有運行的 Unit
$ systemctl list-units --all --state=inactive# 列出所有加載失敗的 Unit
$ systemctl list-units --failed# 列出所有正在運行的、類型為 service 的 Unit
$ systemctl list-units --type=service# 查看 Unit 配置文件的內容
$ systemctl cat docker.service

查看unit狀態：

• enabled：已建立啟動鏈接
• disabled：沒建立啟動鏈接
• static：該配置文件沒有 [Install] 部分（無法執行），只能作為其他配置文件的依賴
• masked：該配置文件被禁止建立啟動鏈接

# 顯示系統狀態
$ systemctl status# 顯示單個 Unit 的狀態
$ ystemctl status bluetooth.service# 顯示遠程主機的某個 Unit 的狀態
$ systemctl -H root@rhel7.example.com status httpd.service

unit管理：

# 立即啟動一個服務
$ sudo systemctl start apache.service# 立即停止一個服務
$ sudo systemctl stop apache.service# 重啟一個服務
$ sudo systemctl restart apache.service# 殺死一個服務的所有子進程
$ sudo systemctl kill apache.service# 重新加載一個服務的配置文件
$ sudo systemctl reload apache.service# 重載所有修改過的配置文件
$ sudo systemctl daemon-reload# 顯示某個 Unit 的所有底層參數
$ systemctl show httpd.service# 顯示某個 Unit 的指定屬性的值
$ systemctl show -p CPUShares httpd.service# 設置某個 Unit 的指定屬性
$ sudo systemctl set-property httpd.service CPUShares=500

查看 Unit 的依賴關系：

# 列出一個 Unit 的所有依賴，默認不會列出 target 類型
$ systemctl list-dependencies nginx.service# 列出一個 Unit 的所有依賴，包括 target 類型
$ systemctl list-dependencies --all nginx.service

3.2 服務的生命周期

當一個新的 Unit 文件被放入 /etc/systemd/system/ 或 /usr/lib/systemd/system/ 目錄中時，它是不會被自識識別的。

1）服務的激活

systemctl enable：在 /etc/systemd/system/ 建立服務的符號鏈接，指向 /usr/lib/systemd/system/ 中

systemctl start：依次啟動定義在 Unit 文件中的 ExecStartPre、ExecStart 和 ExecStartPost 命令

2）服務的啟動和停止

systemctl start：依次啟動定義在 Unit 文件中的 ExecStartPre、ExecStart 和 ExecStartPost 命令

systemctl stop：依次停止定義在 Unit 文件中的 ExecStopPre、ExecStop 和 ExecStopPost 命令

systemctl restart：重啟服務

systemctl kill：立即殺死服務

3）服務的開機啟動和取消

systemctl enable：除了激活服務以外，也可以置服務為開機啟動

systemctl disable：取消服務的開機啟動

4）服務的修改和移除

systemctl daemon-reload：Systemd 會將 Unit 文件的內容寫到緩存中，因此當 Unit 文件被更新時，需要告訴 Systemd 重新讀取所有的 Unit 文件

systemctl reset-failed：移除標記為丟失的 Unit 文件。在刪除 Unit 文件后，由于緩存的關系，即使通過 daemon-reload 更新了緩存，在 list-units 中依然會顯示標記為 not-found 的 Unit。

3.3 Target 管理

Target 就是一個 Unit 組，包含許多相關的 Unit 。啟動某個 Target 的時候，Systemd 就會啟動里面所有的 Unit。

在傳統的 SysV-init 啟動模式里面，有 RunLevel 的概念，跟 Target 的作用很類似。不同的是，RunLevel 是互斥的，不可能多個 RunLevel 同時啟動，但是多個 Target 可以同時啟動。

# 查看當前系統的所有 Target
$ systemctl list-unit-files --type=target# 查看一個 Target 包含的所有 Unit
$ systemctl list-dependencies multi-user.target# 查看啟動時的默認 Target
$ systemctl get-default# 設置啟動時的默認 Target
$ sudo systemctl set-default multi-user.target# 切換 Target 時，默認不關閉前一個 Target 啟動的進程，systemctl isolate 命令改變這種行為，關閉前一個 Target 里面所有不屬于后一個 Target 的進程
$ sudo systemctl isolate multi-user.target

Target 與 SysV-init 進程的主要區別：

• 默認的 RunLevel（在 /etc/inittab 文件設置）現在被默認的 Target 取代，位置是 /etc/systemd/system/default.target，通常符號鏈接到graphical.target（圖形界面）或者multi-user.target（多用戶命令行）。
• 啟動腳本的位置，以前是 /etc/init.d 目錄，符號鏈接到不同的 RunLevel 目錄 （比如 /etc/rc3.d、/etc/rc5.d 等），現在則存放在 /lib/systemd/system 和 /etc/systemd/system 目錄。
• 配置文件的位置，以前 init 進程的配置文件是 /etc/inittab，各種服務的配置文件存放在 /etc/sysconfig 目錄。現在的配置文件主要存放在 /lib/systemd 目錄，在 /etc/systemd 目錄里面的修改可以覆蓋原始設置。

3.4 日志管理

Systemd 通過其標準日志服務 Journald 提供的配套程序?journalctl?將其管理的所有后臺進程打印到 std:out（即控制臺）的輸出重定向到了日志文件。

Systemd 的日志文件是二進制格式的，必須使用 Journald 提供的 journalctl 來查看，默認不帶任何參數時會輸出系統和所有后臺進程的混合日志。

默認日志最大限制為所在文件系統容量的 10%，可以修改 /etc/systemd/journald.conf 中的 SystemMaxUse 來指定該最大限制。

# 查看所有日志（默認情況下 ，只保存本次啟動的日志）
$ sudo journalctl# 查看內核日志（不顯示應用日志）：--dmesg 或 -k
$ sudo journalctl -k# 查看系統本次啟動的日志（其中包括了內核日志和各類系統服務的控制臺輸出）：--system 或 -b
$ sudo journalctl -b
$ sudo journalctl -b -0# 查看上一次啟動的日志（需更改設置）
$ sudo journalctl -b -1# 查看指定服務的日志：--unit 或 -u
$ sudo journalctl -u docker.servcie# 查看指定服務的日志
$ sudo journalctl /usr/lib/systemd/systemd# 實時滾動顯示最新日志
$ sudo journalctl -f# 查看指定時間的日志
$ sudo journalctl --since="2012-10-30 18:17:16"
$ sudo journalctl --since "20 min ago"
$ sudo journalctl --since yesterday
$ sudo journalctl --since "2015-01-10" --until "2015-01-11 03:00"
$ sudo journalctl --since 09:00 --until "1 hour ago"# 顯示尾部的最新 10 行日志：--lines 或 -n
$ sudo journalctl -n# 顯示尾部指定行數的日志
$ sudo journalctl -n 20# 將最新的日志顯示在前面
$ sudo journalctl -r -u docker.service# 改變輸出的格式：--output 或 -o
$ sudo journalctl -r -u docker.service -o json-pretty# 查看指定進程的日志
$ sudo journalctl _PID=1# 查看某個路徑的腳本的日志
$ sudo journalctl /usr/bin/bash# 查看指定用戶的日志
$ sudo journalctl _UID=33 --since today# 查看某個 Unit 的日志
$ sudo journalctl -u nginx.service
$ sudo journalctl -u nginx.service --since today# 實時滾動顯示某個 Unit 的最新日志
$ sudo journalctl -u nginx.service -f# 合并顯示多個 Unit 的日志
$ journalctl -u nginx.service -u php-fpm.service --since today# 查看指定優先級（及其以上級別）的日志，共有 8 級
# 0: emerg
# 1: alert
# 2: crit
# 3: err
# 4: warning
# 5: notice
# 6: info
# 7: debug
$ sudo journalctl -p err -b# 日志默認分頁輸出，--no-pager 改為正常的標準輸出
$ sudo journalctl --no-pager# 以 JSON 格式（單行）輸出
$ sudo journalctl -b -u nginx.service -o json# 以 JSON 格式（多行）輸出，可讀性更好
$ sudo journalctl -b -u nginx.serviceqq-o json-pretty# 顯示日志占據的硬盤空間
$ sudo journalctl --disk-usage# 指定日志文件占據的最大空間
$ sudo journalctl --vacuum-size=1G# 指定日志文件保存多久
$ sudo journalctl --vacuum-time=1years

4. Systemd工具集

• systemctl：用于檢查和控制各種系統服務和資源的狀態
• bootctl：用于查看和管理系統啟動分區
• hostnamectl：用于查看和修改系統的主機名和主機信息
• journalctl：用于查看系統日志和各類應用服務日志
• localectl：用于查看和管理系統的地區信息
• loginctl：用于管理系統已登錄用戶和 Session 的信息
• machinectl：用于操作 Systemd 容器
• timedatectl：用于查看和管理系統的時間和時區信息
• systemd-analyze 顯示此次系統啟動時運行每個服務所消耗的時間，可以用于分析系統啟動過程中的性能瓶頸
• systemd-ask-password：輔助性工具，用星號屏蔽用戶的任意輸入，然后返回實際輸入的內容
• systemd-cat：用于將其他命令的輸出重定向到系統日志
• systemd-cgls：遞歸地顯示指定 CGroup 的繼承鏈
• systemd-cgtop：顯示系統當前最耗資源的 CGroup 單元
• systemd-escape：輔助性工具，用于去除指定字符串中不能作為 Unit 文件名的字符
• systemd-hwdb：Systemd 的內部工具，用于更新硬件數據庫
• systemd-delta：對比當前系統配置與默認系統配置的差異
• systemd-detect-virt：顯示主機的虛擬化類型
• systemd-inhibit：用于強制延遲或禁止系統的關閉、睡眠和待機事件
• systemd-machine-id-setup：Systemd 的內部工具，用于給 Systemd 容器生成 ID
• systemd-notify：Systemd 的內部工具，用于通知服務的狀態變化
• systemd-nspawn：用于創建 Systemd 容器
• systemd-path：Systemd 的內部工具，用于顯示系統上下文中的各種路徑配置
• systemd-run：用于將任意指定的命令包裝成一個臨時的后臺服務運行
• systemd-stdio- bridge：Systemd 的內部 工具，用于將程序的標準輸入輸出重定向到系統總線
• systemd-tmpfiles：Systemd 的內部工具，用于創建和管理臨時文件目錄
• systemd-tty-ask-password-agent：用于響應后臺服務進程發出的輸入密碼請求

具體每個工具的使用，請通過 --help 查看。

5. 應用示例

1）自啟動后臺服務

[Unit]
Description=The HTTP and reverse proxy server
After=network.target remote-fs.target nss-lookup.target
Wants=network.target[Service]
Type=simple
ExecStart=/usr/local/xxxx/xxxx -c /usr/local/xxxx/xxx.ini
Restart=on-failure
RestartSec=15
KillSignal=SIGQUIT
TimeoutStopSec=5
KillMode=process
PrivateTmp=true
StandardOutput=syslog
StandardError=inherit[Install]
WantedBy=multi-user.target

（持續更新）