systemd詳解

systemd是一個 Linux 系統基礎組件的集合,提供了一個系統和服務管理器,運行爲 PID 1 並負責啓動其它程序。功能包括:支持並行化任務;同時採用 socket 式與 D-Bus 總線式激活服務;按需啓動守護進程(daemon);利用 Linux 的 cgroups 監視進程;支持快照和系統恢復;維護掛載點和自動掛載點;各服務間基於依賴關係進行精密控制。systemd 支持 SysV 和 LSB 初始腳本,可以替代 sysvinit。除此之外,功能還包括日誌進程、控制基礎系統配置,維護登陸用戶列表以及系統賬戶、運行時目錄和設置,可以運行容器和虛擬機,可以簡單的管理網絡配置、網絡時間同步、日誌轉發和名稱解析等。

systemd 基本工具

監視和控制systemd的主要命令是systemctl。該命令可用於查看系統狀態和管理系統及服務。詳見systemctl(1)。、

提示:

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

  • Plasma 用戶可以安裝 systemctl 圖形前端 systemd-kcmAUR。安裝後可以在 System administration 下找到。

分析系統狀態

顯示 系統狀態

$ systemctl status

輸出激活的單元:

$ systemctl

以下命令等效:

$ systemctl list-units

輸出運行失敗的單元:

$ systemctl --failed

所有可用的單元文件存放在 /usr/lib/systemd/system/ 和 /etc/systemd/system/ 目錄(後者優先級更高)。查看所有已安裝服務:

$ systemctl list-unit-files

顯示 cgroup slice, 內存和父 PID:

$ systemctl status pid

使用單元

一個單元配置文件可以描述如下內容之一:系統服務(.service)、掛載點(.mount)、sockets(.sockets) 、系統設備(.device)、交換分區(.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 ),這意味着它是模板單元 [email protected] 的一個 實例。 string 被稱作實例標識符,在 systemctl 調用模板單元時,會將其當作一個參數傳給模板單元,模板單元會使用這個傳入的參數代替模板中的 %I 指示符。

在實例化之前,systemd 會先檢查 [email protected] 文件是否存在(如果存在,就直接使用這個文件,而不是模板實例化)。大多數情況下,包含 @ 標記都意味着這個文件是模板。如果一個模板單元沒有實例化就調用,該調用會返回失敗,因爲模板單元中的 %I 指示符沒有被替換。

提示:

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

  • systemctl命令在enabledisablemask子命令中增加了--now選項,可以實現激活的同時啓動服務,取消激活的同時停止服務。

  • 一個軟件包可能會提供多個不同的單元。如果你已經安裝了軟件包,可以通過pacman -Qql package | grep systemd命令檢查這個軟件包提供了哪些單元。

立即激活單元:

# systemctl start <單元>

立即停止單元:

# systemctl stop <單元>

重啓單元:

# systemctl restart <單元>

重新加載配置:

# systemctl reload <單元>

輸出單元運行狀態:

$ systemctl status <單元>

檢查單元是否配置爲自動啓動:

$ systemctl is-enabled <單元>

開機自動激活單元:

# systemctl enable <單元>

設置單元爲自動啓動並立即啓動這個單元:

# systemctl enable --now unit

取消開機自動激活單元:

# systemctl disable <單元>

禁用一個單元(禁用後,間接啓動也是不可能的):

# systemctl mask <單元>

取消禁用一個單元:

# systemctl unmask <單元>

顯示單元的手冊頁(必須由單元文件提供):

# systemctl help <單元>

重新載入 systemd 系統配置,掃描單元文件的變動。注意這裏不會重新加載變更的單元文件。參考上面的 reload 示例。

# systemctl daemon-reload

電源管理

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

如果你正登錄在一個本地的 systemd-logind 用戶會話,且當前沒有其它活動的會話,那麼以下命令無需 root 權限即可執行。否則(例如,當前有另一個用戶登錄在某個 tty ), systemd 將會自動請求輸入root密碼。

重啓:

$ systemctl reboot

退出系統並關閉電源:

$ systemctl poweroff

待機:

$ systemctl suspend

休眠:

$ systemctl hibernate

混合休眠模式(同時休眠到硬盤並待機):

$ systemctl hybrid-sleep

編寫單元文件

systemd 單元文件的語法來源於 XDG 桌面項配置文件.desktop文件,最初的源頭則是Microsoft Windows的.ini文件。單元文件可以從多個地方加載,systemctl show --property=UnitPath 可以按優先級從低到高顯示加載目錄:

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

  • /etc/systemd/system/ :系統管理員安裝的單元

注意:

  • 當 systemd 運行在用戶模式下時,使用的加載路徑是完全不同的。

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

單元文件的語法,可以參考系統已經安裝的單元,也可以參考 systemd.service(5) 中的EXAMPLES章節

提示: 以 # 開頭的註釋可能也能用在 unit-files 中,但是只能在新行中使用。不要在 systemd 的參數後面使用行末註釋, 否則 unit 將會啓動失敗。

處理依賴關係

使用 systemd 時,可通過正確編寫單元配置文件來解決其依賴關係。典型的情況是,單元 A 要求單元 B 在 A 啓動之前運行。在此情況下,向單元 A 配置文件中的 [Unit] 段添加 Requires=B 和 After=B 即可。若此依賴關係是可選的,可添加 Wants=B 和 After=B 。請注意 Wants= 和 Requires= 並不意味着 After= ,即如果 After= 選項沒有制定,這兩個單元將被並行啓動。

依賴關係通常被用在服務(service)而不是目標(target)上。例如, network.target 一般會被某個配置網絡接口的服務引入,所以,將自定義的單元排在該服務之後即可,因爲 network.target 已經啓動。

服務類型

編寫自定義的 service 文件時,可以選擇幾種不同的服務啓動方式。啓動方式可通過配置文件 [Service] 段中的 Type= 參數進行設置。

  • Type=simple :(默認值) systemd認爲該服務將立即啓動。服務進程不會 fork 。如果該服務要啓動其他服務,不要使用此類型啓動,除非該服務是socket 激活型。

  • Type=forking :systemd認爲當該服務進程fork,且父進程退出後服務啓動成功。對於常規的守護進程(daemon),除非你確定此啓動方式無法滿足需求,使用此類型啓動即可。使用此啓動類型應同時指定 PIDFile=,以便 systemd 能夠跟蹤服務的主進程。

  • Type=oneshot :這一選項適用於只執行一項任務、隨後立即退出的服務。可能需要同時設置 RemainAfterExit=yes 使得 systemd 在服務進程退出之後仍然認爲服務處於激活狀態。

  • Type=notify :與 Type=simple 相同,但約定服務會在就緒後向 systemd 發送一個信號。這一通知的實現由 libsystemd-daemon.so 提供。

  • Type=dbus :若以此方式啓動,當指定的 BusName 出現在DBus系統總線上時,systemd認爲服務就緒。

  • Type=idle :systemd會等待所有任務處理完成後,纔開始執行 idle 類型的單元。其他行爲與 Type=simple 類似。

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

修改現存單元文件

爲了避免和 pacman 衝突,不應該直接編輯軟件包提供的文件。有兩種方法可以不改動原始文件就做到修改單元文件:創建一個優先級更高的本地單元文件或創建一個片段,應用到原始單元文件之上。兩種方法都需要在修改後重新加載單元,用 systemctl edit 編輯單元(會自動重載單元)或通過下面命令重新加載單元:

# systemctl daemon-reload

提示:

  • systemd-delta 命令用來查看哪些單元文件被覆蓋、哪些被修改。系統維護的時候需要及時瞭解哪些單元已經有了更新。

  • 使用 systemctl cat unit 可以查看單元的內容和所有相關的片段.

替換單元文件

要替換 /usr/lib/systemd/system/unit, 創建文件 /etc/systemd/system/unit 並重新啓用單元以更新鏈接:

# systemctl reenable unit

或者運行:

# systemctl edit --full unit

這將會在記事本中打開 /etc/systemd/system/unit,如果文件不存在,可以將安裝的版本複製到這裏,在編輯完成之後,會自動加載新版本。

注意: 即使 Pacman 更新了新的單元文件,軟件包中的版本也不會被使用,所以這個方式會增加系統維護的難度,推薦使用下面一種方法。

附加配置片段

要附加配置片段,先創建名爲 /etc/systemd/system/<單元名>.d/ 的目錄,然後放入 *.conf 文件,其中可以添加或重置參數。這裏設置的參數優先級高於原來的單元文件。下面的更新方式比較簡單:

# systemctl edit unit

這將會在編輯器中打開文件 /etc/systemd/system/unit.d/override.conf,編輯完成之後自動加載。

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

重置到軟件包版本

要回退單元的變更,使用 systemctl edit 並執行:

# systemctl revert unit

示例

例如,如果想添加一個額外的依賴,創建如下文件即可:

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

要修改一個非 oneshot 單元的 ExecStart 命令,創建下面文件:

/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)是一箇舊的概念。現在,systemd 引入了一個和運行級別功能相似又不同的概念——目標(target)。不像數字表示的啓動級別,每個目標都有名字和獨特的功能,並且能同時啓用多個。一些目標繼承其他目標的服務,並啓動新服務。systemd 提供了一些模仿 sysvinit 運行級別的目標,仍可以使用舊的 telinit 運行級別 命令切換。

獲取當前目標

不要使用 runlevel 命令了:

$ systemctl list-units --type=target

創建自定義目標

在 sysvinit 中有明確定義的運行級別(如:0、1、3、5、6)與 systemd 中特定的 目標 存在一一對應的關係。然而,對於用戶自定義運行級別(2、4)卻沒有。如需要同樣功能,建議你以原有運行級別所對應的 systemd 目標爲基礎,新建一個/etc/systemd/system/<目標名>.target(可參考/usr/lib/systemd/system/graphical.target), 然後創建目錄/etc/systemd/system/<目標名>.wants,並向其中加入需啓用的服務鏈接(指向/ur/lib/systemd/system/)。

"SysV 運行級別" 與 "systemd 目標" 對照表

SysV 運行級別Systemd 目標註釋
0runlevel0.target, poweroff.target中斷系統(halt)
1, s, singlerunlevel1.target, rescue.target單用戶模式
2, 4runlevel2.target, runlevel4.target, multi-user.target用戶自定義運行級別,通常識別爲級別3。
3runlevel3.target, multi-user.target多用戶,無圖形界面。用戶可以通過終端或網絡登錄。
5runlevel5.target, graphical.target多用戶,圖形界面。繼承級別3的服務,並啓動圖形界面服務。
6runlevel6.target, reboot.target重啓
emergencyemergency.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添加內核參數

  • systemd.unit=multi-user.target (大致相當於運行級別3)

  • systemd.unit=rescue.target (大致相當於運行級別1)

默認目標順序

Systemd 根據下面順序選擇 default.target

  1. 上面的內核參數

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

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

臨時文件

/usr/lib/tmpfiles.d/ 和 /etc/tmpfiles.d/ 中的文件描述了 systemd-tmpfiles 如何創建、清理、刪除臨時文件和目錄,這些文件和目錄通常存放在 /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

此外,臨時文件還可以用來在開機時向特定文件寫入某些內容。比如,要禁止系統從USB設備喚醒,利用舊的 /etc/rc.local 可以用 echo USBE > /proc/acpi/wakeup,而現在可以這麼做:

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

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

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

定時器

一個定時器是一個以 .timer 爲結尾的單元配置文件幷包含由 systemd 控制和監督的信息。systemd/Timers (簡體中文)

注意: 定時器很大程度上可取代 cronsystemd/Timers (簡體中文)#替代 cron

掛載

因爲 systemd 也負責按 /etc/fstab 掛載目錄。在系統啓動和重新加載系統管理器時,systemd-fstab-generator(8) 會將 /etc/fstab 中的配置轉化爲 systemd 單元。

systemd 擴展了 fstab 的傳統功能,提供了額外的掛載選項。例如可以確保一個掛載僅在網絡已經連接時進行,或者僅當另外一個分區已掛載時再掛載。這些選項通常以 x-systemd. 開頭,systemd.mount(5) 中包含了完整說明。

automounting 也是一個例子,可以在使用時,而不是啓動時掛載分區,詳情請參考 fstab#Automount with systemd

GPT 分區自動掛載

在 GPT 分區磁盤系統上,systemd-gpt-auto-generator(8) 會按照 可探測分區規範 進行掛載。可以在 fstab 中忽略。

要禁用自動掛載,請修改分區的 類型 GUID 或設置分區屬性 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 NetworkManagerenable NetworkManager-wait-online.service.

  • If using systemd-networkdsystemd-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 stracestderr 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 sandboxCapabilityBoundingSet=~ CAP_SYS_ADM

疑難解答

尋找錯誤

這個例子中的失敗的服務是 systemd-modules-load :

1. 通過 systemd 尋找啓動失敗的服務:

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

或者使用 systemd 消息:

$ journalctl -fp err

2. 我們發現了啓動失敗的 systemd-modules-load 服務. 我們想知道更多信息:

$ 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 重新啓動失敗的服務 ( 例如 systemctl restart systemd-modules-load )

3. 現在得到了 PID ,你就可以進一步探查錯誤的詳細信息了.通過下列的命令收集日誌,PID 參數是你剛剛得到的 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. 我們發現有些內核模塊的配置文件不正確,因此在 /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 相關. 讓我們註釋掉第三步發現的錯誤的選項:

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

6. 最後重新啓動 systemd-modules-load 服務:

# systemctl start systemd-modules-load

如果服務成功啓動,不會有任何輸出.如果你還是遇到了錯誤,回到步驟三,獲得新的 PID 來跟蹤日誌並解決錯誤.

可以像這樣確認服務成功啓動:

$ 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.

診斷啓動問題

使用如下內核參數引導: systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M

更多有關調試的信息,參見該文

診斷一個服務

如果某個 systemd 服務的工作狀況不合預期,希望調試的話,設置 SYSTEMD_LOG_LEVEL 環境變量 爲 debug . 例如以調試模式運行 systemd-networkd 服務:

在此服務的配置文件片段中加入:

[Service]
Environment=SYSTEMD_LOG_LEVEL=debug

或者等價的,臨時編輯系統單元文件,例如:

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

重啓 systemd-networkd 服務,用 --follow 選項檢查日誌。

關機/重啓十分緩慢

如果關機特別慢(甚至跟死機了一樣),很可能是某個拒不退出的服務在作怪。systemd 會等待一段時間,然後再嘗試殺死它。請閱讀這篇文章,確認你是否是該問題受害者。

短時進程無日誌記錄

若 journalctl -u foounit.service 沒有顯示某個短時進程的任何輸出,那麼改用 PID 試試。例如,若 systemd-modules-load.service 執行失敗,那麼先用 systemctl status systemd-modules-load 查詢其 PID(比如是123),然後檢索該 PID 相關的日誌 journalctl -b _PID=123。運行時進程的日誌元數據(諸如 _SYSTEMD_UNIT 和 _COMM)被亂序收集在 /proc 目錄。要修復該問題,必須修改內核,使其通過套接字連接來提供上述數據,該過程類似於 SCM_CREDENTIALS。

禁止在程序崩潰時轉儲內存

要使用老的內核轉儲,創建下面文件:

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

然後運行:

# /usr/lib/systemd/systemd-sysctl

同樣可能需要執行“unlimit”設置文件大小:

$ ulimit -c unlimited

更多信息請參閱 sysctl.d 和 /proc/sys/kernel 文檔

啓動的時間太長

不少用戶用了 systemd-analyze 命令以後報告啓動的時間比預計的要長,通常會說 systemd-analyze 分析結果表示 NetworkManager 佔據了太多的啓動的時間.

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

systemd-tmpfiles-setup.service 在啓動時啓動失敗

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

參閱 Access Control Lists#Enabling ACL 獲得如何包含 /var/log/journal 啓動 ACL 的詳細信息.

啓動時顯示的 systemd 版本和安裝版本不一致

需要 重新生成 initramfs

提示: 可以使用 pacman 鉤子在更新 systemd時重新生成 initramfs。參考 這個帖子 和 Pacman#Hooks.

禁用遠程機器的 emergency 模式

如果遠程機器位於雲主機,emergency 模式會導致系統無法遠程連接,可以通過下面方式禁用緊急模式:

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


發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章