systemd是一個(gè) Linux 系統(tǒng)基礎(chǔ)組件的集合，提供了一個(gè)系統(tǒng)和服務(wù)管理器，運(yùn)行為 PID 1 并負(fù)責(zé)啟動(dòng)其它程序。功能包括：支持并行化任務(wù)；同時(shí)采用 socket 式與 D-Bus 總線式激活服務(wù)；按需啟動(dòng)守護(hù)進(jìn)程（daemon）；利用 Linux 的 cgroups 監(jiān)視進(jìn)程；支持快照和系統(tǒng)恢復(fù)；維護(hù)掛載點(diǎn)和自動(dòng)掛載點(diǎn)；各服務(wù)間基于依賴關(guān)系進(jìn)行精密控制。systemd 支持 SysV 和 LSB 初始腳本，可以替代 sysvinit。除此之外，功能還包括日志進(jìn)程、控制基礎(chǔ)系統(tǒng)配置，維護(hù)登陸用戶列表以及系統(tǒng)賬戶、運(yùn)行時(shí)目錄和設(shè)置，可以運(yùn)行容器和虛擬機(jī)，可以簡(jiǎn)單的管理網(wǎng)絡(luò)配置、網(wǎng)絡(luò)時(shí)間同步、日志轉(zhuǎn)發(fā)和名稱解析等。

systemd 基本工具

監(jiān)視和控制systemd的主要命令是systemctl。該命令可用于查看系統(tǒng)狀態(tài)和管理系統(tǒng)及服務(wù)。詳見systemctl(1)。、

提示：

在 systemctl 參數(shù)中添加 -H <用戶名>@<主機(jī)名> 可以實(shí)現(xiàn)對(duì)其他機(jī)器的遠(yuǎn)程控制。該功能使用 SSH 連接。
Plasma用戶可以安裝 systemctl 圖形前端 systemd-kcmAUR。安裝后可以在 System administration 下找到。

分析系統(tǒng)狀態(tài)

顯示 系統(tǒng)狀態(tài)：
$ systemctl status
輸出激活的單元：
$ systemctl
以下命令等效：
$ systemctl list-units
輸出運(yùn)行失敗的單元：
$ systemctl --failed

所有可用的單元文件存放在 /usr/lib/systemd/system/ 和 /etc/systemd/system/ 目錄（后者優(yōu)先級(jí)更高）。查看所有已安裝服務(wù)：
$ systemctl list-unit-files

顯示 cgroup slice, 內(nèi)存和父 PID:
$ systemctl status pid

使用單元

一個(gè)單元配置文件可以描述如下內(nèi)容之一：系統(tǒng)服務(wù)（.service）、掛載點(diǎn)（.mount）、sockets（.sockets） 、系統(tǒng)設(shè)備（.device）、交換分區(qū)（.swap）、文件路徑（.path）、啟動(dòng)目標(biāo)（.target）、由 systemd 管理的計(jì)時(shí)器（.timer）。詳情參閱 systemd.unit(5)。

使用 systemctl 控制單元時(shí)，通常需要使用單元文件的全名，包括擴(kuò)展名（例如 sshd.service ）。但是有些單元可以在 systemctl 中使用簡(jiǎn)寫方式。

如果無擴(kuò)展名，systemctl 默認(rèn)把擴(kuò)展名當(dāng)作 .service 。例如 netcfg 和 netcfg.service 是等價(jià)的。

掛載點(diǎn)會(huì)自動(dòng)轉(zhuǎn)化為相應(yīng)的 .mount 單元。例如 /home 等價(jià)于 home.mount 。

設(shè)備會(huì)自動(dòng)轉(zhuǎn)化為相應(yīng)的 .device 單元，所以 /dev/sda2 等價(jià)于 dev-sda2.device 。

注意:有一些單元的名稱包含一個(gè) @ 標(biāo)記（例如： name@string.service ），這意味著它是模板單元 name@.service 的一個(gè) 實(shí)例。 string 被稱作實(shí)例標(biāo)識(shí)符，在 systemctl 調(diào)用模板單元時(shí)，會(huì)將其當(dāng)作一個(gè)參數(shù)傳給模板單元，模板單元會(huì)使用這個(gè)傳入的參數(shù)代替模板中的 %I 指示符。

在實(shí)例化之前，systemd 會(huì)先檢查 name@string.suffix 文件是否存在（如果存在，就直接使用這個(gè)文件，而不是模板實(shí)例化）。大多數(shù)情況下，包含 @ 標(biāo)記都意味著這個(gè)文件是模板。如果一個(gè)模板單元沒有實(shí)例化就調(diào)用，該調(diào)用會(huì)返回失敗，因?yàn)槟０鍐卧械?%I 指示符沒有被替換。

提示：

• 下面的大部分命令都可以跟多個(gè)單元名, 詳細(xì)信息參見 systemctl(1)。

• systemctl命令在enable、disable和mask子命令中增加了–now選項(xiàng)，可以實(shí)現(xiàn)激活的同時(shí)啟動(dòng)服務(wù)，取消激活的同時(shí)停止服務(wù)。

• 一個(gè)軟件包可能會(huì)提供多個(gè)不同的單元。如果你已經(jīng)安裝了軟件包，可以通過pacman -Qql package | grep
  systemd命令檢查這個(gè)軟件包提供了哪些單元。

立即激活單元：
# systemctl start <單元>

立即停止單元:
# systemctl stop <單元>

重啟單元：
# systemctl restart <單元>
重新加載配置：
# systemctl reload <單元>

輸出單元運(yùn)行狀態(tài)：
$ systemctl status <單元>
檢查單元是否配置為自動(dòng)啟動(dòng)：
$ systemctl is-enabled <單元>
開機(jī)自動(dòng)激活單元：
# systemctl enable <單元>
設(shè)置單元為自動(dòng)啟動(dòng)并立即啟動(dòng)這個(gè)單元:
# systemctl enable --now unit
取消開機(jī)自動(dòng)激活單元：
# systemctl disable <單元>
禁用一個(gè)單元（禁用后，間接啟動(dòng)也是不可能的）：
systemctl mask <單元>
取消禁用一個(gè)單元：
systemctl unmask <單元>
顯示單元的手冊(cè)頁（必須由單元文件提供）：
systemctl help <單元>
重新載入 systemd 系統(tǒng)配置，掃描單元文件的變動(dòng)。注意這里不會(huì)重新加載變更的單元文件。參考上面的 reload 示例。
systemctl daemon-reload

電源管理

安裝 polkit 后才能以普通用戶身份使用電源管理。

如果你正登錄在一個(gè)本地的 systemd-logind 用戶會(huì)話，且當(dāng)前沒有其它活動(dòng)的會(huì)話，那么以下命令無需 root 權(quán)限即可執(zhí)行。否則（例如，當(dāng)前有另一個(gè)用戶登錄在某個(gè) tty ）， systemd 將會(huì)自動(dòng)請(qǐng)求輸入root密碼。

重啟：

$ systemctl reboot
退出系統(tǒng)并關(guān)閉電源：

$ systemctl poweroff
待機(jī)：

$ systemctl suspend
休眠：

$ systemctl hibernate
混合休眠模式（同時(shí)休眠到硬盤并待機(jī)）：

$ systemctl hybrid-sleep

編寫單元文件

systemd 單元文件的語法來源于 XDG 桌面項(xiàng)配置文件.desktop文件，最初的源頭則是Microsoft Windows的.ini文件。單元文件可以從多個(gè)地方加載，systemctl show --property=UnitPath 可以按優(yōu)先級(jí)從低到高顯示加載目錄：

/usr/lib/systemd/system/ ：軟件包安裝的單元

/etc/systemd/system/ ：系統(tǒng)管理員安裝的單元

注意:

當(dāng) systemd 運(yùn)行在用戶模式下時(shí)，使用的加載路徑是完全不同的。

systemd 單元名僅能包含 ASCII 字符，下劃線和點(diǎn)號(hào)和有特殊意義的字符(’@’, '-’)。其它字符需要用 C-style “\x2d” 替換。參閱 systemd.unit(5) 和 systemd-escape(1) 。

單元文件的語法，可以參考系統(tǒng)已經(jīng)安裝的單元，也可以參考 systemd.service(5) 中的EXAMPLES章節(jié)。

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

處理依賴關(guān)系

使用 systemd 時(shí)，可通過正確編寫單元配置文件來解決其依賴關(guān)系。典型的情況是，單元 A 要求單元 B 在 A 啟動(dòng)之前運(yùn)行。在此情況下，向單元 A 配置文件中的 [Unit] 段添加 Requires=B 和 After=B 即可。若此依賴關(guān)系是可選的，可添加 Wants=B 和 After=B 。請(qǐng)注意 Wants= 和 Requires= 并不意味著 After= ，即如果 After= 選項(xiàng)沒有制定，這兩個(gè)單元將被并行啟動(dòng)。

依賴關(guān)系通常被用在服務(wù)（service）而不是目標(biāo)（target）上。例如， network.target 一般會(huì)被某個(gè)配置網(wǎng)絡(luò)接口的服務(wù)引入，所以，將自定義的單元排在該服務(wù)之后即可，因?yàn)?network.target 已經(jīng)啟動(dòng)。

服務(wù)類型

編寫自定義的 service 文件時(shí)，可以選擇幾種不同的服務(wù)啟動(dòng)方式。啟動(dòng)方式可通過配置文件 [Service]段中的 Type=參數(shù)進(jìn)行設(shè)置。

• Type=simple：（默認(rèn)值） systemd認(rèn)為該服務(wù)將立即啟動(dòng)。服務(wù)進(jìn)程不會(huì) fork 。如果該服務(wù)要啟動(dòng)其他服務(wù)，不要使用此類型啟動(dòng)，除非該服務(wù)是socket 激活型。

• Type=forking：systemd認(rèn)為當(dāng)該服務(wù)進(jìn)程fork，且父進(jìn)程退出后服務(wù)啟動(dòng)成功。對(duì)于常規(guī)的守護(hù)進(jìn)程（daemon），除非你確定此啟動(dòng)方式無法滿足需求，使用此類型啟動(dòng)即可。使用此啟動(dòng)類型應(yīng)同時(shí)指定 PIDFile=，以便 systemd 能夠跟蹤服務(wù)的主進(jìn)程。

• Type=oneshot：這一選項(xiàng)適用于只執(zhí)行一項(xiàng)任務(wù)、隨后立即退出的服務(wù)?？赡苄枰瑫r(shí)設(shè)置 RemainAfterExit=yes使得 systemd 在服務(wù)進(jìn)程退出之后仍然認(rèn)為服務(wù)處于激活狀態(tài)。

• Type=notify：與 Type=simple相同，但約定服務(wù)會(huì)在就緒后向 systemd 發(fā)送一個(gè)信號(hào)。這一通知的實(shí)現(xiàn)由 libsystemd-daemon.so提供。

• Type=dbus：若以此方式啟動(dòng)，當(dāng)指定的 BusName出現(xiàn)在DBus系統(tǒng)總線上時(shí)，systemd認(rèn)為服務(wù)就緒。

• Type=idle：systemd會(huì)等待所有任務(wù)處理完成后，才開始執(zhí)行 idle類型的單元。其他行為與 Type=simple類似。

type的更多解釋可以參考 systemd.service(5)。

修改現(xiàn)存單元文件

為了避免和 pacman 沖突，不應(yīng)該直接編輯軟件包提供的文件。有兩種方法可以不改動(dòng)原始文件就做到修改單元文件：創(chuàng)建一個(gè)優(yōu)先級(jí)更高的本地單元文件或創(chuàng)建一個(gè)片段，應(yīng)用到原始單元文件之上。兩種方法都需要在修改后重新加載單元，用 systemctl edit編輯單元(會(huì)自動(dòng)重載單元)或通過下面命令重新加載單元：

# systemctl daemon-reload

提示：

• systemd-delta命令用來查看哪些單元文件被覆蓋、哪些被修改。系統(tǒng)維護(hù)的時(shí)候需要及時(shí)了解哪些單元已經(jīng)有了更新。

• 使用 systemctl cat *unit*可以查看單元的內(nèi)容和所有相關(guān)的片段.

替換單元文件

要替換 /usr/lib/systemd/system/*unit*, 創(chuàng)建文件 /etc/systemd/system/*unit*并重新啟用單元以更新鏈接：

# systemctl reenable unit

或者運(yùn)行：

# systemctl edit --full unit

這將會(huì)在記事本中打開 /etc/systemd/system/*unit*，如果文件不存在，可以將安裝的版本復(fù)制到這里，在編輯完成之后，會(huì)自動(dòng)加載新版本。

注意:即使 Pacman 更新了新的單元文件，軟件包中的版本也不會(huì)被使用，所以這個(gè)方式會(huì)增加系統(tǒng)維護(hù)的難度，推薦使用下面一種方法。

附加配置片段

要附加配置片段，先創(chuàng)建名為 /etc/systemd/system/<單元名>.d/的目錄，然后放入 *.conf文件，其中可以添加或重置參數(shù)。這里設(shè)置的參數(shù)優(yōu)先級(jí)高于原來的單元文件。下面的更新方式比較簡(jiǎn)單：

# systemctl edit unit

這將會(huì)在編輯器中打開文件 /etc/systemd/system/*unit*.d/override.conf，編輯完成之后自動(dòng)加載。

Note:并不是所有參數(shù)都會(huì)被子配置文件覆蓋。例如要修改 Conflicts=就必須 替換原始文件。

重置到軟件包版本

要回退單元的變更，使用 systemctl edit并執(zhí)行:

# systemctl revert unit

示例

例如，如果想添加一個(gè)額外的依賴，創(chuàng)建如下文件即可：

/etc/systemd/system/<unit>.d/customdependency.conf
[Unit]
Requires=<新依賴>
After=<新依賴>

要修改一個(gè)非 oneshot單元的 ExecStart命令，創(chuàng)建下面文件:

/etc/systemd/system/unit.d/customexec.conf
[Service]
ExecStart=
ExecStart=new command

修改 ExecStart前必須將其置空，參見 ([1] 。所有可能多次賦值的變量都需要這個(gè)操作，例如定時(shí)器的 OnCalendar。

下面是自動(dòng)重啟服務(wù)的一個(gè)例子：

/etc/systemd/system/unit.d/restart.conf
[Service]
Restart=always
RestartSec=30

目標(biāo)（target）

運(yùn)行級(jí)別（runlevel）是一個(gè)舊的概念?，F(xiàn)在，systemd 引入了一個(gè)和運(yùn)行級(jí)別功能相似又不同的概念——目標(biāo)（target）。不像數(shù)字表示的啟動(dòng)級(jí)別，每個(gè)目標(biāo)都有名字和獨(dú)特的功能，并且能同時(shí)啟用多個(gè)。一些目標(biāo)繼承其他目標(biāo)的服務(wù)，并啟動(dòng)新服務(wù)。systemd 提供了一些模仿 sysvinit 運(yùn)行級(jí)別的目標(biāo)，仍可以使用舊的 telinit 運(yùn)行級(jí)別命令切換。

獲取當(dāng)前目標(biāo)

不要使用 runlevel命令了：

$ systemctl list-units --type=target

創(chuàng)建自定義目標(biāo)

在 sysvinit中有明確定義的運(yùn)行級(jí)別（如：0、1、3、5、6）與 systemd中特定的 目標(biāo)存在一一對(duì)應(yīng)的關(guān)系。然而，對(duì)于用戶自定義運(yùn)行級(jí)別（2、4）卻沒有。如需要同樣功能，建議你以原有運(yùn)行級(jí)別所對(duì)應(yīng)的 systemd 目標(biāo)為基礎(chǔ)，新建一個(gè)/etc/systemd/system/*<目標(biāo)名>.target*（可參考/usr/lib/systemd/system/graphical.target）, 然后創(chuàng)建目錄/etc/systemd/system/<目標(biāo)名>.wants，并向其中加入需啟用的服務(wù)鏈接（指向/ur/lib/systemd/system/）。

“SysV 運(yùn)行級(jí)別” 與 “systemd 目標(biāo)” 對(duì)照表

切換當(dāng)前運(yùn)行目標(biāo)

systemd中，運(yùn)行目標(biāo)通過“目標(biāo)單元”訪問。通過如下命令切換：

# systemctl isolate graphical.target

該命令僅更改當(dāng)前運(yùn)行目標(biāo)，對(duì)下次啟動(dòng)無影響。這等價(jià)于sysvinit中的 telinit 3或 telinit 5命令。

更改開機(jī)默認(rèn)啟動(dòng)目標(biāo)

開機(jī)啟動(dòng)的目標(biāo)是 default.target，默認(rèn)鏈接到 graphical.target（大致相當(dāng)于原來的運(yùn)行級(jí)別5）。

用 systemctl檢查當(dāng)前的默認(rèn)啟動(dòng)目標(biāo)：

# systemctl get-default

用 systemctl修改default.target以變更開機(jī)默認(rèn)啟動(dòng)目標(biāo)：

$ systemctl set-default multi-user.target
Removed /etc/systemd/system/default.target.
Created symlink /etc/systemd/system/default.target -> /usr/lib/systemd/system/graphical.target.

另一方法是向bootloader添加內(nèi)核參數(shù)：

• systemd.unit=multi-user.target（大致相當(dāng)于運(yùn)行級(jí)別3）

• systemd.unit=rescue.target（大致相當(dāng)于運(yùn)行級(jí)別1）

默認(rèn)目標(biāo)順序

Systemd 根據(jù)下面順序選擇 default.target：

1. 上面的內(nèi)核參數(shù)

2. /etc/systemd/system/default.target軟鏈接

3. /usr/lib/systemd/system/default.target軟鏈接

臨時(shí)文件

/usr/lib/tmpfiles.d/和 /etc/tmpfiles.d/中的文件描述了 systemd-tmpfiles 如何創(chuàng)建、清理、刪除臨時(shí)文件和目錄，這些文件和目錄通常存放在 /run和 /tmp中。配置文件名稱為 /etc/tmpfiles.d/<program>.conf。此處的配置能覆蓋 /usr/lib/tmpfiles.d/目錄中的同名配置。

臨時(shí)文件通常和服務(wù)文件同時(shí)提供，以生成守護(hù)進(jìn)程需要的文件和目錄。例如 Samba 服務(wù)需要目錄 /run/samba存在并設(shè)置正確的權(quán)限位，就象這樣：

/usr/lib/tmpfiles.d/samba.conf
D /run/samba 0755 root root

此外，臨時(shí)文件還可以用來在開機(jī)時(shí)向特定文件寫入某些內(nèi)容。比如，要禁止系統(tǒng)從USB設(shè)備喚醒，利用舊的 /etc/rc.local可以用 echo USBE > /proc/acpi/wakeup，而現(xiàn)在可以這么做：

/etc/tmpfiles.d/disable-usb-wake.conf
w /proc/acpi/wakeup - - - - USBE

詳情參見systemd-tmpfiles(8)和 tmpfiles.d(5)。

注意:該方法不能向 /sys中的配置文件添加參數(shù)，因?yàn)?systemd-tmpfiles-setup有可能在相關(guān)模塊加載前運(yùn)行。這種情況下，需要首先通過 modinfo <模塊名>確認(rèn)需要的參數(shù)，然后在 /etc/modprobe.d目錄下的配置文件中修改配置參數(shù)。另外，還可以使用 udev 規(guī)則，在設(shè)備就緒時(shí)設(shè)置相應(yīng)屬性。

定時(shí)器

一個(gè)定時(shí)器是一個(gè)以 .timer為結(jié)尾的單元配置文件并包含由 systemd控制和監(jiān)督的信息。systemd/Timers (簡(jiǎn)體中文)

注意:定時(shí)器很大程度上可取代 cron。systemd/Timers (簡(jiǎn)體中文)#替代 cron

掛載

因?yàn)?systemd 也負(fù)責(zé)按 /etc/fstab掛載目錄。在系統(tǒng)啟動(dòng)和重新加載系統(tǒng)管理器時(shí)，systemd-fstab-generator(8) 會(huì)將 /etc/fstab中的配置轉(zhuǎn)化為 systemd 單元。

systemd擴(kuò)展了 fstab 的傳統(tǒng)功能，提供了額外的掛載選項(xiàng)。例如可以確保一個(gè)掛載僅在網(wǎng)絡(luò)已經(jīng)連接時(shí)進(jìn)行，或者僅當(dāng)另外一個(gè)分區(qū)已掛載時(shí)再掛載。這些選項(xiàng)通常以 x-systemd.開頭，systemd.mount(5) 中包含了完整說明。

automounting也是一個(gè)例子，可以在使用時(shí)，而不是啟動(dòng)時(shí)掛載分區(qū)，詳情請(qǐng)參考 fstab#Automount with systemd。

GPT 分區(qū)自動(dòng)掛載

在 GPT 分區(qū)磁盤系統(tǒng)上，systemd-gpt-auto-generator(8) 會(huì)按照 可探測(cè)分區(qū)規(guī)范 進(jìn)行掛載?？梢栽?fstab中忽略。

要禁用自動(dòng)掛載，請(qǐng)修改分區(qū)的 類型 GUID 或設(shè)置分區(qū)屬性 63 位 “不自動(dòng)掛載”，詳情參考 gdisk#Prevent GPT partition automounting。

Tips and tricks

Running services after the network is up

To delay a service after the network is up, include the following dependencies in the .servicefile:

/etc/systemd/system/foo.service
[Unit]	
...Wants=network-online.targetAfter=network-online.target	...

The network wait service of the particular application that manages the network, must also be enabled so that network-online.targetproperly reflects the network status.

• For the ones using NetworkManager, enable NetworkManager-wait-online.service.

• If using systemd-networkd, systemd-networkd-wait-online.serviceis by default enabled automatically whenever systemd-networkd.servicehas been enabled; check this is the case with systemctl is-enabled systemd-networkd-wait-online.service, there is no other action needed.

For more detailed explanations see Running services after the network is up in the systemd wiki.

Enable installed units by default

**
This article or section needs expansion.**

Reason:How does it work with instantiated units? (Discuss in Talk:Systemd (簡(jiǎn)體中文)#)

Arch Linux ships with /usr/lib/systemd/system-preset/99-default.presetcontaining disable *. This causes systemctl presetto disable all units by default, such that when a new package is installed, the user must manually enable the unit.

If this behavior is not desired, simply create a symlink from /etc/systemd/system-preset/99-default.presetto /dev/nullin order to override the configuration file. This will cause systemctl presetto enable all units that get installed—regardless of unit type—unless specified in another file in one *systemctl preset’*s configuration directories. User units are not affected. See the manpage for systemd.presetfor more information.

Note:Enabling all units by default may cause problems with packages that contain two or more mutually exclusive units. systemctl presetis designed to be used by distributions and spins or system administrators. In the case where two conflicting units would be enabled, you should explicitly specify which one is to be disabled in a preset configuration file as specified in the manpage for systemd.preset.

Sandboxing application environments

A unit file can be created as a sandbox to isolate applications and their processes within a hardened virtual environment. systemd leverages namespaces, white-/blacklisting of Capabilities, and control groups to container processes through an extensive execution environment configuration.

The enhancement of an existing systemd unit file with application sandboxing typically requires trial-and-error tests accompanied by the generous use of strace, stderr and journalctl error logging and output facilities. You may want to first search upstream documentation for already done tests to base trials on.

Some examples on how sandboxing with systemd can be deployed:

• CapabilityBoundingSetdefines a whitelisted set of allowed capabilities, but may also be used to blacklist a specific capability for a unit.

• The CAP_SYS_ADMcapability, for example, which should be one of the goals of a secure sandbox: CapabilityBoundingSet=~ CAP_SYS_ADM

疑難解答

尋找錯(cuò)誤

這個(gè)例子中的失敗的服務(wù)是 systemd-modules-load:

1.通過 systemd尋找啟動(dòng)失敗的服務(wù):

$ systemctl --state=failed
systemd-modules-load.service   loaded failed failed  Load Kernel Modules

或者使用 systemd消息:

$ journalctl -fp err

2.我們發(fā)現(xiàn)了啟動(dòng)失敗的 systemd-modules-load服務(wù). 我們想知道更多信息:

$ systemctl status systemd-modules-load
systemd-modules-load.service - Load Kernel Modules
   Loaded: loaded (/usr/lib/systemd/system/systemd-modules-load.service; static)
   Active: failed (Result: exit-code) since So 2013-08-25 11:48:13 CEST; 32s ago
     Docs: man:systemd-modules-load.service(8).
           man:modules-load.d(5)
  Process: 15630 ExecStart=/usr/lib/systemd/systemd-modules-load (code=exited, status=1/FAILURE)

如果沒列出 Process ID, 通過 systemctl重新啟動(dòng)失敗的服務(wù) ( 例如 systemctl restart systemd-modules-load)

3.現(xiàn)在得到了 PID ,你就可以進(jìn)一步探查錯(cuò)誤的詳細(xì)信息了.通過下列的命令收集日志,PID 參數(shù)是你剛剛得到的 Process ID(例如 15630):

$ journalctl -b _PID=15630
-- Logs begin at Sa 2013-05-25 10:31:12 CEST, end at So 2013-08-25 11:51:17 CEST. --
Aug 25 11:48:13 mypc systemd-modules-load[15630]: Failed to find module 'blacklist usblp'Aug 25 11:48:13 mypc systemd-modules-load[15630]: Failed to find module 'install usblp /bin/false'

4.我們發(fā)現(xiàn)有些內(nèi)核模塊的配置文件不正確,因此在 /etc/modules-load.d/中檢查一下:

$ ls -Al /etc/modules-load.d/
...
-rw-r--r--   1 root root    79  1. Dez 2012  blacklist.conf
-rw-r--r--   1 root root     1  2. M?r 14:30 encrypt.conf
-rw-r--r--   1 root root     3  5. Dez 2012  printing.conf
-rw-r--r--   1 root root     6 14. Jul 11:01 realtek.conf
-rw-r--r--   1 root root    65  2. Jun 23:01 virtualbox.conf
...

5.錯(cuò)誤消息 Failed to find module 'blacklist usblp'也許和 blacklist.conf相關(guān). 讓我們注釋掉第三步發(fā)現(xiàn)的錯(cuò)誤的選項(xiàng):

/etc/modules-load.d/blacklist.conf
# blacklist usblp# install usblp /bin/false

6.最后重新啟動(dòng) systemd-modules-load服務(wù):

# systemctl start systemd-modules-load

如果服務(wù)成功啟動(dòng),不會(huì)有任何輸出.如果你還是遇到了錯(cuò)誤,回到步驟三,獲得新的 PID 來跟蹤日志并解決錯(cuò)誤.

可以像這樣確認(rèn)服務(wù)成功啟動(dòng):

$ systemctl status systemd-modules-load
systemd-modules-load.service - Load Kernel Modules
   Loaded: loaded (/usr/lib/systemd/system/systemd-modules-load.service; static)
   Active: active (exited) since So 2013-08-25 12:22:31 CEST; 34s ago
     Docs: man:systemd-modules-load.service(8)
           man:modules-load.d(5)
 Process: 19005 ExecStart=/usr/lib/systemd/systemd-modules-load (code=exited, status=0/SUCCESS)
Aug 25 12:22:31 mypc systemd[1]: Started Load Kernel Modules.

診斷啟動(dòng)問題

使用如下內(nèi)核參數(shù)引導(dǎo)： systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M

更多有關(guān)調(diào)試的信息，參見該文。

診斷一個(gè)服務(wù)

如果某個(gè) systemd服務(wù)的工作狀況不合預(yù)期,希望調(diào)試的話,設(shè)置 SYSTEMD_LOG_LEVEL環(huán)境變量 為 debug. 例如以調(diào)試模式運(yùn)行 systemd-networkd服務(wù):

在此服務(wù)的配置文件片段中加入：

[Service]
Environment=SYSTEMD_LOG_LEVEL=debug

或者等價(jià)的,臨時(shí)編輯系統(tǒng)單元文件,例如:

1. SYSTEMD_LOG_LEVEL=debug /lib/systemd/systemd-networkd

重啟 systemd-networkd服務(wù)，用 --follow選項(xiàng)檢查日志。

關(guān)機(jī)/重啟十分緩慢

如果關(guān)機(jī)特別慢（甚至跟死機(jī)了一樣），很可能是某個(gè)拒不退出的服務(wù)在作怪。systemd 會(huì)等待一段時(shí)間，然后再嘗試殺死它。請(qǐng)閱讀這篇文章，確認(rèn)你是否是該問題受害者。

短時(shí)進(jìn)程無日志記錄

若 journalctl -u foounit.service沒有顯示某個(gè)短時(shí)進(jìn)程的任何輸出，那么改用 PID 試試。例如，若 systemd-modules-load.service執(zhí)行失敗，那么先用 systemctl status systemd-modules-load查詢其 PID（比如是123），然后檢索該 PID 相關(guān)的日志 journalctl -b _PID=123。運(yùn)行時(shí)進(jìn)程的日志元數(shù)據(jù)（諸如 _SYSTEMD_UNIT 和 _COMM）被亂序收集在 /proc目錄。要修復(fù)該問題，必須修改內(nèi)核，使其通過套接字連接來提供上述數(shù)據(jù)，該過程類似于 SCM_CREDENTIALS。

禁止在程序崩潰時(shí)轉(zhuǎn)儲(chǔ)內(nèi)存

要使用老的內(nèi)核轉(zhuǎn)儲(chǔ)，創(chuàng)建下面文件:

/etc/sysctl.d/49-coredump.conf
kernel.core_pattern = core
kernel.core_uses_pid = 0

然后運(yùn)行：

# /usr/lib/systemd/systemd-sysctl

同樣可能需要執(zhí)行“unlimit”設(shè)置文件大?。?/p>

$ ulimit -c unlimited

更多信息請(qǐng)參閱 sysctl.d 和 /proc/sys/kernel 文檔。

啟動(dòng)的時(shí)間太長(zhǎng)

不少用戶用了 systemd-analyze命令以后報(bào)告啟動(dòng)的時(shí)間比預(yù)計(jì)的要長(zhǎng),通常會(huì)說 systemd-analyze分析結(jié)果表示 NetworkManager 占據(jù)了太多的啟動(dòng)的時(shí)間.

有些用戶的問題是 /var/log/journal文件夾似乎過大.這也許也會(huì)對(duì)像systemctl status或 journalctl的命令有影響.一種解決方案是刪除其中的文件 (但最好將它們備份到某處) 然后限制日志文件的大小.

systemd-tmpfiles-setup.service 在啟動(dòng)時(shí)啟動(dòng)失敗

從 systemd 219 開始, /usr/lib/tmpfiles.d/systemd.conf指定 /var/log/journal的 ACL 屬性和目錄, 因此日志所在的文件系統(tǒng)上要啟用ACL.

參閱 Access Control Lists#Enabling ACL 獲得如何包含 /var/log/journal啟動(dòng) ACL 的詳細(xì)信息.

啟動(dòng)時(shí)顯示的 systemd 版本和安裝版本不一致

需要 重新生成 initramfs。

提示：可以使用 pacman 鉤子在更新 systemd時(shí)重新生成 initramfs。參考 這個(gè)帖子 和 Pacman#Hooks.

禁用遠(yuǎn)程機(jī)器的 emergency 模式

如果遠(yuǎn)程機(jī)器位于云主機(jī)，emergency 模式會(huì)導(dǎo)致系統(tǒng)無法遠(yuǎn)程連接，可以通過下面方式禁用緊急模式：

# systemctl mask emergency.service
# systemctl mask emergency.target

轉(zhuǎn)載于:https://blog.51cto.com/19910312/2379860