systemd详解
systemd是一個 Linux 系統(tǒng)基礎組件的集合，提供了一個系統(tǒng)和服務管理器，運行為 PID 1 并負責啟動其它程序。功能包括：支持并行化任務；同時采用 socket 式與 D-Bus 總線式激活服務；按需啟動守護進程（daemon）；利用 Linux 的 cgroups 監(jiān)視進程；支持快照和系統(tǒng)恢復；維護掛載點和自動掛載點；各服務間基于依賴關系進行精密控制。systemd 支持 SysV 和 LSB 初始腳本，可以替代 sysvinit。除此之外，功能還包括日志進程、控制基礎系統(tǒng)配置，維護登陸用戶列表以及系統(tǒng)賬戶、運行時目錄和設置，可以運行容器和虛擬機，可以簡單的管理網(wǎng)絡配置、網(wǎng)絡時間同步、日志轉發(fā)和名稱解析等。
systemd 基本工具
監(jiān)視和控制systemd的主要命令是systemctl。該命令可用于查看系統(tǒng)狀態(tài)和管理系統(tǒng)及服務。詳見systemctl(1)。、
提示：
在 systemctl 參數(shù)中添加 -H <用戶名>@<主機名> 可以實現(xiàn)對其他機器的遠程控制。該功能使用 SSH 連接。
Plasma 用戶可以安裝 systemctl 圖形前端 systemd-kcmAUR。安裝后可以在 System administration 下找到。
分析系統(tǒng)狀態(tài)
顯示 系統(tǒng)狀態(tài)：
$ systemctl status
輸出激活的單元：
$ systemctl
以下命令等效：
$ systemctl list-units
輸出運行失敗的單元：
$ systemctl --failed
所有可用的單元文件存放在 /usr/lib/systemd/system/ 和 /etc/systemd/system/ 目錄（后者優(yōu)先級更高）。查看所有已安裝服務：
$ systemctl list-unit-files
顯示 cgroup slice, 內存和父 PID:
$ systemctl status pid
使用單元
一個單元配置文件可以描述如下內容之一：系統(tǒng)服務（.service）、掛載點（.mount）、sockets（.sockets） 、系統(tǒng)設備（.device）、交換分區(qū)（.swap）、文件路徑（.path）、啟動目標（.target）、由 systemd 管理的計時器（.timer）。詳情參閱 systemd.unit(5)。
使用 systemctl 控制單元時，通常需要使用單元文件的全名，包括擴展名（例如 sshd.service ）。但是有些單元可以在 systemctl 中使用簡寫方式。
如果無擴展名，systemctl 默認把擴展名當作 .service 。例如 netcfg 和 netcfg.service 是等價的。
掛載點會自動轉化為相應的 .mount 單元。例如 /home 等價于 home.mount 。
設備會自動轉化為相應的 .device 單元，所以 /dev/sda2 等價于 dev-sda2.device 。
注意: 有一些單元的名稱包含一個 @ 標記（例如： name@string.service ），這意味著它是模板單元 name@.service 的一個 實例。 string 被稱作實例標識符，在 systemctl 調用模板單元時，會將其當作一個參數(shù)傳給模板單元，模板單元會使用這個傳入的參數(shù)代替模板中的 %I 指示符。
在實例化之前，systemd 會先檢查 name@string.suffix 文件是否存在（如果存在，就直接使用這個文件，而不是模板實例化）。大多數(shù)情況下，包含 @ 標記都意味著這個文件是模板。如果一個模板單元沒有實例化就調用，該調用會返回失敗，因為模板單元中的 %I 指示符沒有被替換。
提示：
-
下面的大部分命令都可以跟多個單元名, 詳細信息參見 systemctl(1)。
-
systemctl命令在enable、disable和mask子命令中增加了–now選項，可以實現(xiàn)激活的同時啟動服務，取消激活的同時停止服務。
-
一個軟件包可能會提供多個不同的單元。如果你已經安裝了軟件包，可以通過pacman -Qql package | grep
systemd命令檢查這個軟件包提供了哪些單元。
立即激活單元：
# systemctl start <單元>
立即停止單元:
# systemctl stop <單元>
重啟單元：
# systemctl restart <單元>
重新加載配置：
# systemctl reload <單元>
輸出單元運行狀態(tài)：
$ systemctl status <單元>
檢查單元是否配置為自動啟動：
$ systemctl is-enabled <單元>
開機自動激活單元：
# systemctl enable <單元>
設置單元為自動啟動并立即啟動這個單元:
# systemctl enable --now unit
取消開機自動激活單元：
# systemctl disable <單元>
禁用一個單元（禁用后，間接啟動也是不可能的）：
systemctl mask <單元>
取消禁用一個單元：
systemctl unmask <單元>
顯示單元的手冊頁（必須由單元文件提供）：
systemctl help <單元>
重新載入 systemd 系統(tǒng)配置，掃描單元文件的變動。注意這里不會重新加載變更的單元文件。參考上面的 reload 示例。
systemctl daemon-reload
電源管理
安裝 polkit 后才能以普通用戶身份使用電源管理。
如果你正登錄在一個本地的 systemd-logind 用戶會話，且當前沒有其它活動的會話，那么以下命令無需 root 權限即可執(zhí)行。否則（例如，當前有另一個用戶登錄在某個 tty ）， systemd 將會自動請求輸入root密碼。
重啟：
$ systemctl reboot
退出系統(tǒng)并關閉電源：
$ systemctl poweroff
待機：
$ systemctl suspend
休眠：
$ systemctl hibernate
混合休眠模式（同時休眠到硬盤并待機）：
$ systemctl hybrid-sleep
編寫單元文件
systemd 單元文件的語法來源于 XDG 桌面項配置文件.desktop文件，最初的源頭則是Microsoft Windows的.ini文件。單元文件可以從多個地方加載，systemctl show --property=UnitPath 可以按優(yōu)先級從低到高顯示加載目錄：
/usr/lib/systemd/system/ ：軟件包安裝的單元
/etc/systemd/system/ ：系統(tǒng)管理員安裝的單元
注意:
當 systemd 運行在用戶模式下時，使用的加載路徑是完全不同的。
systemd 單元名僅能包含 ASCII 字符，下劃線和點號和有特殊意義的字符(’@’, ‘-’)。其它字符需要用 C-style “\x2d” 替換。參閱 systemd.unit(5) 和 systemd-escape(1) 。
單元文件的語法，可以參考系統(tǒng)已經安裝的單元，也可以參考 systemd.service(5) 中的EXAMPLES章節(jié)。
提示： 以 # 開頭的注釋可能也能用在 unit-files 中，但是只能在新行中使用。不要在 systemd 的參數(shù)后面使用行末注釋， 否則 unit 將會啟動失敗。
處理依賴關系
使用 systemd 時，可通過正確編寫單元配置文件來解決其依賴關系。典型的情況是，單元 A 要求單元 B 在 A 啟動之前運行。在此情況下，向單元 A 配置文件中的 [Unit] 段添加 Requires=B 和 After=B 即可。若此依賴關系是可選的，可添加 Wants=B 和 After=B 。請注意 Wants= 和 Requires= 并不意味著 After= ，即如果 After= 選項沒有制定，這兩個單元將被并行啟動。
依賴關系通常被用在服務（service）而不是目標（target）上。例如， network.target 一般會被某個配置網(wǎng)絡接口的服務引入，所以，將自定義的單元排在該服務之后即可，因為 network.target 已經啟動。
服務類型
編寫自定義的 service 文件時，可以選擇幾種不同的服務啟動方式。啟動方式可通過配置文件 [Service] 段中的 Type= 參數(shù)進行設置。
- Type=simple ：（默認值） systemd認為該服務將立即啟動。服務進程不會 fork 。如果該服務要啟動其他服務，不要使用此類型啟動，除非該服務是socket 激活型。
- Type=forking ：systemd認為當該服務進程fork，且父進程退出后服務啟動成功。對于常規(guī)的守護進程（daemon），除非你確定此啟動方式無法滿足需求，使用此類型啟動即可。使用此啟動類型應同時指定 PIDFile=，以便 systemd 能夠跟蹤服務的主進程。
- Type=oneshot ：這一選項適用于只執(zhí)行一項任務、隨后立即退出的服務。可能需要同時設置 RemainAfterExit=yes 使得 systemd 在服務進程退出之后仍然認為服務處于激活狀態(tài)。
- Type=notify ：與 Type=simple 相同，但約定服務會在就緒后向 systemd 發(fā)送一個信號。這一通知的實現(xiàn)由 libsystemd-daemon.so 提供。
- Type=dbus ：若以此方式啟動，當指定的 BusName 出現(xiàn)在DBus系統(tǒng)總線上時，systemd認為服務就緒。
- Type=idle ：systemd會等待所有任務處理完成后，才開始執(zhí)行 idle 類型的單元。其他行為與 Type=simple 類似。
type 的更多解釋可以參考 systemd.service(5)。
修改現(xiàn)存單元文件
為了避免和 pacman 沖突，不應該直接編輯軟件包提供的文件。有兩種方法可以不改動原始文件就做到修改單元文件：創(chuàng)建一個優(yōu)先級更高的本地單元文件或創(chuàng)建一個片段，應用到原始單元文件之上。兩種方法都需要在修改后重新加載單元，用 systemctl edit 編輯單元(會自動重載單元)或通過下面命令重新加載單元：
# systemctl daemon-reload提示：
- systemd-delta 命令用來查看哪些單元文件被覆蓋、哪些被修改。系統(tǒng)維護的時候需要及時了解哪些單元已經有了更新。
- 使用 systemctl cat *unit* 可以查看單元的內容和所有相關的片段.
替換單元文件
要替換 /usr/lib/systemd/system/*unit*, 創(chuàng)建文件 /etc/systemd/system/*unit* 并重新啟用單元以更新鏈接：
# systemctl reenable unit或者運行：
# systemctl edit --full unit這將會在記事本中打開 /etc/systemd/system/*unit*，如果文件不存在，可以將安裝的版本復制到這里，在編輯完成之后，會自動加載新版本。
注意: 即使 Pacman 更新了新的單元文件，軟件包中的版本也不會被使用，所以這個方式會增加系統(tǒng)維護的難度，推薦使用下面一種方法。
附加配置片段
要附加配置片段，先創(chuàng)建名為 /etc/systemd/system/<單元名>.d/ 的目錄，然后放入 *.conf 文件，其中可以添加或重置參數(shù)。這里設置的參數(shù)優(yōu)先級高于原來的單元文件。下面的更新方式比較簡單：
# systemctl edit unit這將會在編輯器中打開文件 /etc/systemd/system/*unit*.d/override.conf，編輯完成之后自動加載。
Note: 并不是所有參數(shù)都會被子配置文件覆蓋。例如要修改 Conflicts= 就必須 替換原始文件。
重置到軟件包版本
要回退單元的變更，使用 systemctl edit 并執(zhí)行:
# systemctl revert unit示例
例如，如果想添加一個額外的依賴，創(chuàng)建如下文件即可：
/etc/systemd/system/<unit>.d/customdependency.conf [Unit] Requires=<新依賴> After=<新依賴>要修改一個非 oneshot 單元的 ExecStart 命令，創(chuàng)建下面文件:
/etc/systemd/system/unit.d/customexec.conf [Service] ExecStart= ExecStart=new command修改 ExecStart 前必須將其置空，參見 ([1] 。所有可能多次賦值的變量都需要這個操作，例如定時器的 OnCalendar 。
下面是自動重啟服務的一個例子：
/etc/systemd/system/unit.d/restart.conf [Service] Restart=always RestartSec=30目標（target）
運行級別（runlevel）是一個舊的概念。現(xiàn)在，systemd 引入了一個和運行級別功能相似又不同的概念——目標（target）。不像數(shù)字表示的啟動級別，每個目標都有名字和獨特的功能，并且能同時啟用多個。一些目標繼承其他目標的服務，并啟動新服務。systemd 提供了一些模仿 sysvinit 運行級別的目標，仍可以使用舊的 telinit 運行級別 命令切換。
獲取當前目標
不要使用 runlevel 命令了：
$ systemctl list-units --type=target創(chuàng)建自定義目標
在 sysvinit 中有明確定義的運行級別（如：0、1、3、5、6）與 systemd 中特定的 目標 存在一一對應的關系。然而，對于用戶自定義運行級別（2、4）卻沒有。如需要同樣功能，建議你以原有運行級別所對應的 systemd 目標為基礎，新建一個/etc/systemd/system/*<目標名>.target*（可參考/usr/lib/systemd/system/graphical.target）, 然后創(chuàng)建目錄/etc/systemd/system/<目標名>.wants，并向其中加入需啟用的服務鏈接（指向/ur/lib/systemd/system/）。
“SysV 運行級別” 與 “systemd 目標” 對照表
| 0 | runlevel0.target, poweroff.target | 中斷系統(tǒng)（halt） |
| 1, s, single | runlevel1.target, rescue.target | 單用戶模式 |
| 2, 4 | runlevel2.target, runlevel4.target, multi-user.target | 用戶自定義運行級別，通常識別為級別3。 |
| 3 | runlevel3.target, multi-user.target | 多用戶，無圖形界面。用戶可以通過終端或網(wǎng)絡登錄。 |
| 5 | runlevel5.target, graphical.target | 多用戶，圖形界面。繼承級別3的服務，并啟動圖形界面服務。 |
| 6 | runlevel6.target, reboot.target | 重啟 |
| emergency | emergency.target | 急救模式（Emergency shell） |
切換當前運行目標
systemd中，運行目標通過“目標單元”訪問。通過如下命令切換：
# systemctl isolate graphical.target該命令僅更改當前運行目標，對下次啟動無影響。這等價于sysvinit中的 telinit 3 或 telinit 5 命令。
更改開機默認啟動目標
開機啟動的目標是 default.target，默認鏈接到 graphical.target （大致相當于原來的運行級別5）。
用 systemctl 檢查當前的默認啟動目標：
# systemctl get-default用 systemctl 修改default.target以變更開機默認啟動目標：
$ 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添加內核參數(shù)：
- systemd.unit=multi-user.target （大致相當于運行級別3）
- systemd.unit=rescue.target （大致相當于運行級別1）
默認目標順序
Systemd 根據(jù)下面順序選擇 default.target：
臨時文件
/usr/lib/tmpfiles.d/ 和 /etc/tmpfiles.d/ 中的文件描述了 systemd-tmpfiles 如何創(chuàng)建、清理、刪除臨時文件和目錄，這些文件和目錄通常存放在 /run 和 /tmp 中。配置文件名稱為 /etc/tmpfiles.d/<program>.conf。此處的配置能覆蓋 /usr/lib/tmpfiles.d/ 目錄中的同名配置。
臨時文件通常和服務文件同時提供，以生成守護進程需要的文件和目錄。例如 Samba 服務需要目錄 /run/samba 存在并設置正確的權限位，就象這樣：
/usr/lib/tmpfiles.d/samba.conf D /run/samba 0755 root root此外，臨時文件還可以用來在開機時向特定文件寫入某些內容。比如，要禁止系統(tǒng)從USB設備喚醒，利用舊的 /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ù)，因為 systemd-tmpfiles-setup 有可能在相關模塊加載前運行。這種情況下，需要首先通過 modinfo <模塊名> 確認需要的參數(shù)，然后在 /etc/modprobe.d 目錄下的配置文件中修改配置參數(shù)。另外，還可以使用 udev 規(guī)則，在設備就緒時設置相應屬性。
定時器
一個定時器是一個以 .timer 為結尾的單元配置文件并包含由 systemd 控制和監(jiān)督的信息。systemd/Timers (簡體中文)
注意: 定時器很大程度上可取代 cron。systemd/Timers (簡體中文)#替代 cron
掛載
因為 systemd 也負責按 /etc/fstab 掛載目錄。在系統(tǒng)啟動和重新加載系統(tǒng)管理器時，systemd-fstab-generator(8) 會將 /etc/fstab 中的配置轉化為 systemd 單元。
systemd 擴展了 fstab 的傳統(tǒng)功能，提供了額外的掛載選項。例如可以確保一個掛載僅在網(wǎng)絡已經連接時進行，或者僅當另外一個分區(qū)已掛載時再掛載。這些選項通常以 x-systemd. 開頭，systemd.mount(5) 中包含了完整說明。
automounting 也是一個例子，可以在使用時，而不是啟動時掛載分區(qū)，詳情請參考 fstab#Automount with systemd。
GPT 分區(qū)自動掛載
在 GPT 分區(qū)磁盤系統(tǒng)上，systemd-gpt-auto-generator(8) 會按照 可探測分區(qū)規(guī)范 進行掛載。可以在 fstab 中忽略。
要禁用自動掛載，請修改分區(qū)的 類型 GUID 或設置分區(qū)屬性 63 位 “不自動掛載”，詳情參考 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 .service file:
/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.target properly reflects the network status.
- For the ones using NetworkManager, enable NetworkManager-wait-online.service.
- If using systemd-networkd, systemd-networkd-wait-online.service is by default enabled automatically whenever systemd-networkd.service has 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 (簡體中文)#)
Arch Linux ships with /usr/lib/systemd/system-preset/99-default.preset containing disable *. This causes systemctl preset to 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.preset to /dev/null in order to override the configuration file. This will cause systemctl preset to 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.preset for more information.
Note: Enabling all units by default may cause problems with packages that contain two or more mutually exclusive units. systemctl preset is 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:
- CapabilityBoundingSet defines a whitelisted set of allowed capabilities, but may also be used to blacklist a specific capability for a unit.
- The CAP_SYS_ADM capability, for example, which should be one of the goals of a secure sandbox: CapabilityBoundingSet=~ CAP_SYS_ADM
疑難解答
尋找錯誤
這個例子中的失敗的服務是 systemd-modules-load :
1. 通過 systemd 尋找啟動失敗的服務:
$ systemctl --state=failed systemd-modules-load.service loaded failed failed Load Kernel Modules或者使用 systemd 消息:
$ journalctl -fp err2. 我們發(fā)現(xiàn)了啟動失敗的 systemd-modules-load 服務. 我們想知道更多信息:
$ systemctl status systemd-modules-load systemd-modules-load.service - Load Kernel ModulesLoaded: 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 agoDocs: 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 重新啟動失敗的服務 ( 例如 systemctl restart systemd-modules-load )
3. 現(xiàn)在得到了 PID ,你就可以進一步探查錯誤的詳細信息了.通過下列的命令收集日志,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)有些內核模塊的配置文件不正確,因此在 /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. 錯誤消息 Failed to find module 'blacklist usblp' 也許和 blacklist.conf 相關. 讓我們注釋掉第三步發(fā)現(xiàn)的錯誤的選項:
/etc/modules-load.d/blacklist.conf # blacklist usblp# install usblp /bin/false6. 最后重新啟動 systemd-modules-load 服務:
# systemctl start systemd-modules-load如果服務成功啟動,不會有任何輸出.如果你還是遇到了錯誤,回到步驟三,獲得新的 PID 來跟蹤日志并解決錯誤.
可以像這樣確認服務成功啟動:
$ systemctl status systemd-modules-load systemd-modules-load.service - Load Kernel ModulesLoaded: loaded (/usr/lib/systemd/system/systemd-modules-load.service; static)Active: active (exited) since So 2013-08-25 12:22:31 CEST; 34s agoDocs: 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.診斷啟動問題
使用如下內核參數(shù)引導： systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M
更多有關調試的信息，參見該文。
診斷一個服務
如果某個 systemd 服務的工作狀況不合預期,希望調試的話,設置 SYSTEMD_LOG_LEVEL 環(huán)境變量 為 debug . 例如以調試模式運行 systemd-networkd 服務:
在此服務的配置文件片段中加入：
[Service] Environment=SYSTEMD_LOG_LEVEL=debug或者等價的,臨時編輯系統(tǒng)單元文件,例如:
重啟 systemd-networkd 服務，用 --follow 選項檢查日志。
關機/重啟十分緩慢
如果關機特別慢（甚至跟死機了一樣），很可能是某個拒不退出的服務在作怪。systemd 會等待一段時間，然后再嘗試殺死它。請閱讀這篇文章，確認你是否是該問題受害者。
短時進程無日志記錄
若 journalctl -u foounit.service 沒有顯示某個短時進程的任何輸出，那么改用 PID 試試。例如，若 systemd-modules-load.service 執(zhí)行失敗，那么先用 systemctl status systemd-modules-load 查詢其 PID（比如是123），然后檢索該 PID 相關的日志 journalctl -b _PID=123。運行時進程的日志元數(shù)據(jù)（諸如 _SYSTEMD_UNIT 和 _COMM）被亂序收集在 /proc 目錄。要修復該問題，必須修改內核，使其通過套接字連接來提供上述數(shù)據(jù)，該過程類似于 SCM_CREDENTIALS。
禁止在程序崩潰時轉儲內存
要使用老的內核轉儲，創(chuàng)建下面文件:
/etc/sysctl.d/49-coredump.conf kernel.core_pattern = core kernel.core_uses_pid = 0然后運行：
# /usr/lib/systemd/systemd-sysctl同樣可能需要執(zhí)行“unlimit”設置文件大小：
$ ulimit -c unlimited更多信息請參閱 sysctl.d 和 /proc/sys/kernel 文檔。
啟動的時間太長
不少用戶用了 systemd-analyze 命令以后報告啟動的時間比預計的要長,通常會說 systemd-analyze 分析結果表示 NetworkManager 占據(jù)了太多的啟動的時間.
有些用戶的問題是 /var/log/journal 文件夾似乎過大.這也許也會對像systemctl status 或 journalctl 的命令有影響.一種解決方案是刪除其中的文件 (但最好將它們備份到某處) 然后限制日志文件的大小.
systemd-tmpfiles-setup.service 在啟動時啟動失敗
從 systemd 219 開始, /usr/lib/tmpfiles.d/systemd.conf 指定 /var/log/journal 的 ACL 屬性和目錄, 因此日志所在的文件系統(tǒng)上要啟用ACL.
參閱 Access Control Lists#Enabling ACL 獲得如何包含 /var/log/journal 啟動 ACL 的詳細信息.
啟動時顯示的 systemd 版本和安裝版本不一致
需要 重新生成 initramfs。
提示： 可以使用 pacman 鉤子在更新 systemd時重新生成 initramfs。參考 這個帖子 和 Pacman#Hooks.
禁用遠程機器的 emergency 模式
如果遠程機器位于云主機，emergency 模式會導致系統(tǒng)無法遠程連接，可以通過下面方式禁用緊急模式：
# systemctl mask emergency.service # systemctl mask emergency.target轉載于:https://blog.51cto.com/19910312/2379860
相關資源：linux中systemd的源代碼(從ubuntu16.4.4獲取)_systemd源碼分析…
總結
- 上一篇： 操作系统语言包在c盘哪里,win10系统
- 下一篇： 谈一谈url实现文件下载