15 systemd 精靈 #

單位組態檔案包含有關以下項目的資訊：服務、通訊端、裝置、掛接點、自動掛接點、交換檔案或分割區、啟動目標、監控的檔案系統路徑、受 systemd 控制和監督的計時器、暫時系統狀態快照、資源管理片段，或一組外部建立的程序。

「單位檔案」是 systemd 用於表示下列項目的通用術語：

如需 systemd 單位檔案的詳細資訊，請參閱 http://www.freedesktop.org/software/systemd/man/systemd.unit.html

用於管理服務的子指令與透過 System V init 管理服務的子指令相同 (start、stop、...)。下面列出了服務管理指令的通用語法：

systemd 可讓您一次管理多個服務。它不是像 System V init 那樣依次執行 init 程序檔，而是執行類似如下的指令：

tux > sudo systemctl start MY_1ST_SERVICE MY_2ND_SERVICE

若要列出系統上所有可用的服務：

tux > sudo systemctl list-unit-files --type=service

下表列出了 systemd 和 System V init 最重要的服務管理指令：

start

start

stop

stop

restart

restart

try-restart

try-restart

reload

reload

reload-or-restart

n/a

reload-or-try-restart

n/a

status

status

is-active

status

上一節中提及的服務管理指令可讓您操作目前工作階段的服務。systemd 還可讓您永久啟用或停用服務，使之可以按要求自動啟動，或者始終無法使用。此操作可以透過 YaST 或在指令行上執行。

15.2.2.1 在指令行上啟用/停用服務 #

下表列出了 systemd 和 System V init 用於啟用和停用服務的指令：

重要：服務啟動

在指令行上啟用服務時，服務不會自動啟動。系統將其排定為下一次系統啟動或執行層級/目標變更時啟動。若要在啟用服務之後立即啟動它，請明確執行 systemctl start MY_SERVICE 或 rc MY_SERVICE start。

表格 15.2︰ 用於啟用和停用服務的指令 #

任務	systemd 指令	System V init 指令
啟用：	systemctl enable MY_SERVICE(S)	insserv MY_SERVICE(S)、chkconfig -a MY_SERVICE(S)
停用：	systemctl disable MY_SERVICE(S).service	insserv -r MY_SERVICE(S)、chkconfig -d MY_SERVICE(S)
檢查：  顯示是否已啟用某個服務。	systemctl is-enabled MY_SERVICE	chkconfig MY_SERVICE
重新啟用：  與重新啟動服務相似，此指令先停用服務，然後再啟用該服務。若要使用服務的預設值重新啟用服務，可使用此任務。	systemctl reenable MY_SERVICE	無
遮罩：  「 停用」某項服務之後，仍然可以手動啟動它。若要徹底停用服務，您需要予以遮罩。使用須謹慎。	systemctl mask MY_SERVICE	無
取消遮罩：  遮罩某項服務之後，惟有先將其取消遮罩，才能再次予以使用。	systemctl unmask MY_SERVICE	無

使用 System V init 時，系統將開機進入「 執行層級」。執行層級定義了系統的啟動方式，以及在所執行的系統中可以使用哪些服務。執行層級標有編號；最常見的執行層級是 0 (關閉系統)、3 (多重使用者，包含網路) 和 5 (多重使用者，包含網路及顯示管理員)。

systemd 使用所謂的「目標單位」引入新的概念。不過，它仍然與執行層級概念完全相容。目標單位是有名稱而不是有編號的，它有多個作用。例如，目標 local-fs.target 和 swap.target 掛接本地檔案系統和交換空間。

目標 graphical.target 提供包含網路和顯示管理員功能的多重使用者系統，與執行層級 5 相當。複雜的目標，例如 graphical.target 透過結合其他目標的子集用作「 中繼」目標。因為 systemd 能夠組合現有目標，便於建立自訂目標，因此提供了極大的靈活性。

下列清單顯示了最重要的 systemd 目標單位。如需完整清單，請參閱 man 7 systemd.special。

為了保持與 System V init 執行層級系統的相容，systemd 提供了名為 runlevelX.target 的特殊目標，對應於編號為 X 的相應執行層級。

如果您要知道目前的目標，請使用指令：systemctl get-default

重要：systemd 會忽略 /etc/inittab

System V init 系統中的執行層級在 /etc/inittab 中設定。systemd 不使用此組態。如需如何建立您自己的可開機目標的指示，請參閱第 15.5.4 節 「建立自訂目標」。

systemd 針對系統啟動過程提供了分析方法。您可以查看所有服務及其狀態的清單 (而不必剖析 /var/log/)。systemd 還允許您掃描啟動程序，以瞭解每項服務耗費多長時間啟動。

root # systemctl
UNIT                        LOAD   ACTIVE SUB       JOB DESCRIPTION
[...]
iscsi.service               loaded active exited    Login and scanning of iSC+
kmod-static-nodes.service   loaded active exited    Create list of required s+
libvirtd.service            loaded active running   Virtualization daemon
nscd.service                loaded active running   Name Service Cache Daemon
chronyd.service             loaded active running   NTP Server Daemon
polkit.service              loaded active running   Authorization Manager
postfix.service             loaded active running   Postfix Mail Transport Ag+
rc-local.service            loaded active exited    /etc/init.d/boot.local Co+
rsyslog.service             loaded active running   System Logging Service
[...]
LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.

161 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.

root # systemctl --failed
UNIT                   LOAD   ACTIVE SUB    JOB DESCRIPTION
apache2.service        loaded failed failed     apache
NetworkManager.service loaded failed failed     Network Manager
plymouth-start.service loaded failed failed     Show Plymouth Boot Screen

[...]

systemd.log_level=debug systemd.log_target=kmsg

tux > dmesg -T | less

Systemd 與 System V 相容，因此，您仍可以使用現有的 System V init 程序檔。但是，至少有一個已知問題會導致 System V init 程序檔不能立即與 systemd 配合使用：透過 init 程序檔中的 su 或 sudo 以其他使用者身分啟動服務會導致程序檔失敗，產生「拒絕存取」錯誤。

使用 su 或 sudo 變更使用者時，會啟動 PAM 工作階段。完成 init 程序檔後會終止此工作階段。因此，init 程序檔啟動的服務也會終止。若要解決此問題，請執行下列步驟：

建議使用 systemctl edit SERVICE 指令來自訂單位檔案。此指令會啟動預設的文字編輯器，並建立一個在 /etc/systemd/system/NAME.service.d/ 中包含 override.conf 檔案的目錄。該指令還確定會向正在執行的 systemd 程序通知這些變更。

或者，您可以透過執行 systemctl edit --full SERVICE 來開啟原始檔案的副本進行編輯，而不是開啟一個空白檔案。編輯檔案時，請確定未移除任何現有區段。

下面將練習如何變更系統等待 MariaDB 啟動的時間。以 root 身分執行 systemctl edit --full mariadb.service。開啟的檔案如下所示：

[Unit]
Description=MySQL server
Wants=basic.target
Conflicts=mariadb.target
After=basic.target network.target

[Install]
WantedBy=multi-user.target
Alias=mysql.service

[Service]
Restart=on-abort
Type=notify
ExecStartPre=/usr/lib/mysql/mysql-systemd-helper  install
ExecStartPre=/usr/lib/mysql/mysql-systemd-helper  upgrade
ExecStart=/usr/lib/mysql/mysql-systemd-helper     start

# Configures the time to wait for start-up/stop
TimeoutSec=300

# Prevent writes to /usr, /boot, and /etc
ProtectSystem=full

# Prevent accessing /home, /root and /run/user
ProtectHome=true

UMask=007

調整 TimeoutSec 值並儲存變更。若要啟用變更，請以 root 身分執行 systemctl daemon-reload。

如需詳細資訊，請參閱可使用 man 1 systemctl 指令呼叫的 man 頁面。

若要對組態檔案進行微小變更，請使用所謂的放入式檔案。放入式檔案可讓您延伸單位檔案的組態，而不必編輯或覆寫單位檔案本身。

例如，若要變更位於 /usr/lib/systemd/system/FOOBAR.SERVICE 中 FOOBAR 服務的單個值，請依照以下步驟操作：

注意：避免名稱衝突

為避免放入式檔案與 SUSE 隨附檔案之間出現名稱衝突，建議在所有放入式檔案名稱前加上一個兩位數和一個破折號：例如，80-override.conf。

以下範圍為保留值範圍：

• 0-19，為 systemd 上游保留

• 20-25，為 SUSE 隨附的 systemd 保留

• 26-29，為 SUSE 套件 (systemd 除外) 保留

• 50，為使用 systemctl set-property 建立的放入式檔案保留

請使用大於此範圍的兩位數，以確定 SUSE 隨附的任何放入式檔案都不會覆寫您自己的放入式檔案。

您可以使用 systemctl cat $UNIT 來列出並驗證考慮將哪些檔案納入單位組態。

從 SUSE Linux Enterprise Server 15 版本開始，移除了 xinetd 基礎架構。本節概述如何將現有的自訂 xinetd 服務檔案轉換為 systemd 通訊端。

對於每個 xinetd 服務檔案，您至少需要兩個 systemd 單位檔案：通訊端檔案 (*.socket) 和關聯的服務檔案 (*.service)。通訊端檔案告訴 systemd 要建立哪個通訊端，服務檔案告訴 systemd 要啟動哪個可執行檔。

以下面的 xinetd 服務檔案為例：

root # cat /etc/xinetd.d/example
service example
{
  socket_type = stream
  protocol = tcp
  port = 10085
  wait = no
  user = user
  group = users
  groups = yes
  server = /usr/libexec/example/exampled
  server_args = -auth=bsdtcp exampledump
  disable = no
}

若要將它轉換為 systemd，需要下面兩個相配的檔案：

root # cat /usr/lib/systemd/system/example.socket
[Socket]
ListenStream=0.0.0.0:10085
Accept=false

[Install]
WantedBy=sockets.target

root # cat /usr/lib/systemd/system/example.service
[Unit]
Description=example

[Service]
ExecStart=/usr/libexec/example/exampled -auth=bsdtcp exampledump
User=user
Group=users
StandardInput=socket

如需 systemd 的「通訊端」和「服務」檔案選項的完整清單，請參閱 systemd.socket 和 systemd.service 手冊頁 (man 5 systemd.socket、man 5 systemd.service)。

在 System V init SUSE 系統上並未使用執行層級 4，便於管理員自行建立執行層級組態。systemd 可讓您建立任意個自訂目標。建議您在開始時先在 graphical.target 等現有的目標上調整。

systemd 支援定期清理暫存目錄。將會自動移轉並啟用前一系統版本中的組態。tmpfiles.d (負責管理暫存檔案) 將從 /etc/tmpfiles.d/*.conf、/run/tmpfiles.d/*.conf 和 /usr/lib/tmpfiles.d/*.conf 檔案中讀取其組態。/etc/tmpfiles.d/*.conf 中的組態將會覆寫其他兩個目錄中的相關組態 (/usr/lib/tmpfiles.d/*.conf 是套件將其組態檔案儲存到的位置)。

組態格式為每個路徑一行，該行包含動作與路徑、(選擇性) 模式、擁有權、期限和引數欄位，具體視動作而定。以下範例將取消連結 X11 鎖定檔案：

Type Path               Mode UID  GID  Age Argument
r    /tmp/.X[0-9]*-lock

若要取得 tmpfile 計時器的狀態：

tux > sudo systemctl status systemd-tmpfiles-clean.timer
systemd-tmpfiles-clean.timer - Daily Cleanup of Temporary Directories
 Loaded: loaded (/usr/lib/systemd/system/systemd-tmpfiles-clean.timer; static)
 Active: active (waiting) since Tue 2018-04-09 15:30:36 CEST; 1 weeks 6 days ago
   Docs: man:tmpfiles.d(5)
         man:systemd-tmpfiles(8)

Apr 09 15:30:36 jupiter systemd[1]: Starting Daily Cleanup of Temporary Directories.
Apr 09 15:30:36 jupiter systemd[1]: Started Daily Cleanup of Temporary Directories.

如需處理暫存檔案的詳細資訊，請參閱 man 5 tmpfiles.d。

第 15.6.9 節 「服務除錯」說明如何檢視給定服務的記錄訊息。然而，記錄的訊息顯示並不局限為服務記錄。您還可以存取和查詢 systemd 寫入的完整記錄訊息 — 亦即「日誌」。使用 journalctl 指令可顯示從最舊項目開始的完整記錄訊息。如需套用過濾器或變更輸出格式等選項的資訊，請參閱 man 1 journalctl。

您可以使用 isolate 子指令將 systemd 的目前狀態儲存到指定的快照，日後可以回復到該狀態。此功能在測試服務或自訂目標時非常有用，因為它允許您隨時回到定義的狀態。快照僅在目前工作階段中可用，重新開機時將自動刪除。快照名稱必須以 .snapshot 結尾。

使用 systemd，可透過 /etc/modules-load.d 中的組態檔案，在開機時自動載入核心模組。該檔案應命名為 MODULE.conf 並包含以下內容：

# load module MODULE at boot time
MODULE

如果某個套件安裝了用於載入核心模組的組態檔案，該檔案將安裝到 /usr/lib/modules-load.d。如果存在兩個同名的組態檔案，將優先使用 /etc/modules-load.d 中的組態檔案。

如需詳細資訊，請參閱 modules-load.d(5) 線上文件。

使用 System V 時，需要在載入服務之前執行的 init 動作必須在 /etc/init.d/before.local 中指定。systemd 不再支援此程序。如果您需要在啟動服務之前執行動作，請執行以下步驟：

在傳統 System V init 系統上不一定能將程序明確指派給繁衍它的服務。有些服務 (例如 Apache) 會繁衍許多協力廠商程序 (例如 CGI 或 Java 程序)，這些程序本身又會繁衍許多程序。這導致您很難明確指派，甚至根本無法明確指派。另外，服務在不當終止後，可能殘留部分子項保持活動狀態。

systemd 將每個服務放入它自己的 cgroup 中，從而解決此問題。cgroup 是一項核心功能，允許將程序及其所有子程序聚合至分層組織的群組中。systemd 根據相應的服務為每個 cgroup 命名。由於程序未經特許不得「離開」其 cgroup，因此這樣可以有效地使用服務名稱標記該服務繁衍的所有程序。

若要列出屬於服務的所有程序，請使用指令 systemd-cgls。結果類似於以下範例 (已縮短)：

root # systemd-cgls --no-pager
├─1 /usr/lib/systemd/systemd --switched-root --system --deserialize 20
├─user.slice
│ └─user-1000.slice
│   ├─session-102.scope
│   │ ├─12426 gdm-session-worker [pam/gdm-password]
│   │ ├─15831 gdm-session-worker [pam/gdm-password]
│   │ ├─15839 gdm-session-worker [pam/gdm-password]
│   │ ├─15858 /usr/lib/gnome-terminal-server

[...]

└─system.slice
  ├─systemd-hostnamed.service
  │ └─17616 /usr/lib/systemd/systemd-hostnamed
  ├─cron.service
  │ └─1689 /usr/sbin/cron -n
  ├─postfix.service
  │ ├─ 1676 /usr/lib/postfix/master -w
  │ ├─ 1679 qmgr -l -t fifo -u
  │ └─15590 pickup -l -t fifo -u
  ├─sshd.service
  │ └─1436 /usr/sbin/sshd -D

[...]

如需 cgroup 的詳細資訊，請參閱Chapter 9, Kernel control groups。

如第 15.6.6 節 「核心控制群組 (cgroup)」中所述，在 System V init 系統中不一定能將程序指派給其父服務，導致難以終止服務及其所有子項。未終止的子程序將保留為廢止程序。

systemd 的概念是將每個服務限制在某個 cgroup 中，從而可以明確識別一個服務的所有子程序，因此可讓您將訊號傳送給這些程序中的每個程序。可使用 systemctl kill 將信號傳送給服務。如需可用信號清單，請參閱 man 7 signals。

D-Bus 服務是 systemd 用戶端與做為 pid 1 執行的 systemd 管理員之間進行通訊的訊息匯流排。雖然 dbus 是個獨立的精靈，但它也是 init 基礎架構的組成部分。

在執行中的系統中終止或重新啟動 dbus 的效果類似於嘗試終止或重新啟動 pid 1。此操作將中斷 systemd 用戶端與伺服器間的通訊，並使大部分 systemd 功能不可用。

因此，不建議也不支援終止或重新啟動 dbus。

更新 dbus 或與 dbus 有關的套件需要重新開機。如果不確定是否需要重新開機，請執行 sudo zypper ps -s。如果 dbus 顯示在所列服務之中，則表明您需要將系統重新開機。

請記住，即使自動更新設定為跳過需要重新開機的套件，dbus 仍會更新。

依預設，systemd 的輸出不會太詳細。如果服務啟動成功，則不會產生任何輸出。如果啟動失敗，則會顯示簡短的錯誤訊息。不過，systemctl status 可讓您以不同方式對服務的啟動和作業進行除錯。

systemd 隨附自己的記錄機製 (「日誌」)，可以記錄系統訊息，便於您一併顯示服務訊息與狀態訊息。status 指令的工作方式與 tail 相似，也可以採用不同的格式顯示記錄訊息，因此成為功能強大的除錯工具。

計時器單位可以使用單純計時器和即時計時器。

每個計時器單位都必須有一個其所控制的相應 systemd 單位檔案。也就是說，將由 .timer 檔案啟用並管理相應的 .service 檔案。使用計時器時，.service 檔案不需要 [Install] 區段，因為服務將由計時器管理。

為了理解 systemd 計時器單位的基本知識，我們設定了一個觸發 foo.sh 外圍程序程序檔的計時器。

第一步是建立用於控制外圍程序程序檔的 systemd 服務單位。為此，請開啟一個新的文字檔案進行編輯，並新增以下服務單位定義：

[Unit]
Description="Foo shell script"

[Service]
ExecStart=/usr/local/bin/foo.sh

將檔案以名稱 foo.service 儲存到目錄 /etc/systemd/system/ 中。

接下來，開啟一個新的文字檔案進行編輯，並新增以下計時器定義：

[Unit]
Description="Run foo shell script"

[Timer]
OnBootSec=5min
OnUnitActiveSec=24h
Unit=foo.service

[Install]
WantedBy=multi-user.target

上述範例中的 [Timer] 區段指定了要觸發的服務 (foo.service) 以及觸發時間。在此範例中，選項 OnBootSec 指定了一個在系統開機後五分鐘觸發服務的單純計時器，而選項 OnUnitActiveSec 會在服務被啟用後 24 小時觸發服務 (即計時器將每天觸發一次服務)。最後，選項 WantedBy 指定應在系統達到多使用者目標時啟動計時器。

您也可以不指定單純計時器，而是使用選項 OnCalendar 指定即時計時器。下面的即時計時器定義從星期一 12:00 開始，每週觸發一次相關服務單位。

[Timer]
OnCalendar=weekly
Persistent=true

選項 Persistent=true 表示如果計時器錯過了上一次啟動時間 (例如，由於系統關閉)，則會在計時器啟用後立即觸發服務。

選項 OnCalendar 還可以用於使用以下格式來定義觸發服務的具體日期和時間：DayOfWeek Year-Month-Day Hour:Minute:Second。下面的範例會在每天早上 5 點觸發服務：

OnCalendar=*-*-* 5:00:00

您可以使用星號指定任何值，使用逗號列出可能的值。使用由 .. 分隔的兩個值可表示一個連續的範圍。下面的範例會在每個月的星期五下午 6 點觸發服務：

OnCalendar=Fri *-*-1..7 18:00:00

若要在不同的時間觸發服務，您可以指定多個 OnCalendar 項目：

OnCalendar=Mon..Fri 10:00
OnCalendar=Sat,Sun 22:00

在上面的範例中，會在工作日的上午 10 點和週末的晚上 10 點觸發服務。

編輯好計時器單位檔案後，使用名稱 foo.timer 將其儲存到 /etc/systemd/system/ 目錄中。若要檢查所建立的單位檔案是否正確，請執行以下指令：

tux > sudo  systemd-analyze verify /etc/systemd/system/foo.*

如果指令未傳回任何輸出，則表示檔案成功通過驗證。

若要啟動計時器，請使用指令 sudo systemctl start foo.timer。若要在開機時啟用計時器，請執行指令 sudo systemctl enable foo.timer。

由於計時器被視為一般 systemd 單位，因此您可以使用 systemctl 來管理它們。您可以使用 systemctl start 啟動計時器，使用 systemctl enable 啟用計時器，依此類推。除此之外，您還可以使用指令 systemctl list-timers 列出所有作用中計時器。若要列出包括非作用中計時器在內的所有計時器，請執行指令 systemctl list-timers --all。