在現代 Linux 伺服器管理中，systemd 已取代傳統的 SysVinit 成為主流的系統與服務管理器。此一轉變不僅是技術上的更新，更代表著管理哲學的根本演進。過去以 /etc/inittab 與運行層級為核心的順序性啟動模式，被 systemd 所採用的目標單元（target units）與依賴性解析的並行化架構所取代。這種模組化的設計大幅提升了開機效率與系統管理彈性。本文將從系統啟動流程的演變談起，深入比較 SysVinit 與 systemd 在服務狀態監控、配置管理及日常操作上的具體差異。透過實務指令的對照，協助技術人員無縫接軌現代化的系統管理方法，並掌握其背後的設計邏輯與核心價值。
現代作業系統的啟動流程解析
在現代 Linux 系統架構中，系統的啟動過程已從傳統的 SysVinit 演進至更為高效且模組化的 systemd。過去，我們透過 /etc/inittab 文件來定義系統的運行層級（runlevel）與開機時啟動的程序。然而，隨著 systemd 的普及，這種機制被轉換為「目標單元」（target units）的概念。例如，傳統的 runlevel3.target 在 systemd 中被對應為 multi-user.target，而系統的預設啟動目標通常會透過軟連結 /etc/systemd/system/default.target 指向具體的目標單元，如 /lib/systemd/system/runlevel3.target。
傳統的 init 或 telinit 命令在 systemd 環境下，實際上會被轉譯成 systemctl isolate 指令，用以切換至指定的目標單元。例如，執行 init 3 等同於執行 systemctl isolate multi-user.target。雖然 runlevel 指令仍可查詢當前的傳統運行層級，但其使用已不被推薦，取而代之的是透過 systemctl status 或 systemctl list-units 等指令來檢視系統目標單元的狀態。
傳統 init 系統中負責啟動終端機登入程序的 getty 或 mingetty，在 systemd 中則由 getty.target 單元來管理。這個 getty.target 單元本身又被定義為依賴於 multi-user.target，這表示當系統進入多使用者模式時，終端機登入服務便會被啟用。
系統啟動目標單元關聯圖
@startuml
!define DISABLE_LINK
!define PLANTUML_FORMAT svg
!theme _none_
skinparam dpi auto
skinparam shadowing false
skinparam linetype ortho
skinparam roundcorner 5
skinparam defaultFontName "Microsoft JhengHei UI"
skinparam defaultFontSize 16
skinparam minClassWidth 100
entity "System Boot" as Boot
entity "Default Target" as DefaultTarget << (T,orange) Target >>
entity "Multi-User Target" as MultiUserTarget << (T,orange) Target >>
entity "Getty Target" as GettyTarget << (T,orange) Target >>
entity "Login Prompt" as LoginPrompt
Boot --> DefaultTarget : Determines
DefaultTarget --> MultiUserTarget : Isolate to
MultiUserTarget --> GettyTarget : Requires
GettyTarget --> LoginPrompt : Activates
note left of DefaultTarget
Represents the default system state upon boot.
Often linked to multi-user.target or graphical.target.
end note
note right of GettyTarget
Manages the spawning of terminal login processes (getty).
end note
@enduml
看圖說話：
此圖示描繪了現代 Linux 系統啟動時，目標單元（Target Units）之間的 logique 關聯。系統啟動（System Boot）的過程，最終會導向一個預設的啟動目標（Default Target），這個目標通常會被設定為 multi-user.target，代表系統已準備好提供多使用者服務。而 multi-user.target 的啟動，又會進一步觸發 getty.target 的啟用。getty.target 的核心職責是啟動終端機登入程序（getty），從而為使用者提供登入介面（Login Prompt），讓使用者能夠與系統互動。這個流程清晰地展示了 systemd 如何透過模組化的目標單元來管理系統的啟動過程，確保各項服務能夠依序且正確地啟動。
服務狀態的監控與管理
作為系統管理員，持續監控伺服器上運行的服務狀態至關重要。這不僅是為了確保系統的正常運作，更是為了及早發現潛在的安全威脅，例如未經授權或不再需要的服務。透過定期檢查，我們可以及時停用或移除這些不必要的服務，從而提升系統的安全性與效能。
傳統 SysVinit 系統的服務檢視
在仍使用傳統 SysVinit 機制的系統上，chkconfig --list 指令是檢視所有可用服務及其在不同運行層級（runlevel 0 至 6）下啟動狀態（on/off）的常用工具。透過此指令的輸出，我們可以一覽例如 ConsoleKit、NetworkManager、crond、cups、sshd 等服務在各運行層級的啟用情況。例如，sshd 服務通常會在運行層級 2 到 5 啟動，確保遠端 SSH 存取功能可用。
然而，chkconfig 指令僅能顯示服務的配置狀態，無法直接告知該服務當前是否正在運行。
現代 systemd 系統的服務狀態查詢
對於採用 systemd 的系統，systemctl 指令提供了更為強大且全面的服務管理功能。若要查看某個特定服務的詳細資訊，包括其是否正在運行、依賴關係等，可以使用 systemctl status <service_name>。例如，systemctl status sshd.service 會顯示 SSH 守護程式的當前狀態。
若要列出所有正在運行的服務單元，可以使用 systemctl list-units --type=service --state=running。這個指令能夠精確地篩選出目前處於運行狀態的服務，對於故障排除和效能分析非常有幫助。
服務運行狀態的綜合檢視
為了更全面地了解哪些服務正在運行，可以結合使用 service --status-all（在部分系統上仍可用）和 grep 指令。將 service --status-all 的輸出透過管道傳遞給 grep running，可以過濾出所有標記為「running」的服務及其進程 ID（PID）。
例如，執行 # service --status-all | grep running 可能會得到類似以下的輸出：
[ + ] anacron
[ + ] atd
[ + ] auditd
[ + ] automount
[ + ] console-kit-daemon
[ + ] crond
[ + ] cupsd
...
[ + ] sshd
[ + ] syslogd
[ + ] xfs
[ + ] yum-updatesd
這裡的 [ + ] 表示服務正在運行。
服務配置與運行狀態的關聯性分析
理解服務的配置狀態（例如，是否設定為開機啟動）與其實際運行狀態之間的差異，是系統管理員必須掌握的關鍵技能。一個服務可能被設定為在特定運行層級啟動，但由於其他原因（例如配置錯誤、依賴服務未啟動），它可能實際上並未運行。反之，一個未被設定為開機啟動的服務，也可能在系統運行期間被手動啟動。
例如，我們可以同時檢視 cups 服務的配置與運行狀態。首先，使用 chkconfig --list cups（適用於 SysVinit 系統）或 systemctl list-unit-files | grep cups（適用於 systemd 系統）來確認其開機啟動的配置。接著，使用 service cups status 或 systemctl status cups.service 來確認它目前是否正在運行。這種對比分析有助於我們全面掌握服務的生命週期管理。
服務管理架構演進圖
@startuml
!define DISABLE_LINK
!define PLANTUML_FORMAT svg
!theme _none_
skinparam dpi auto
skinparam shadowing false
skinparam linetype ortho
skinparam roundcorner 5
skinparam defaultFontName "Microsoft JhengHei UI"
skinparam defaultFontSize 16
skinparam minClassWidth 100
package "Traditional SysVinit" {
entity "init Daemon" as SysVinit
entity "/etc/inittab" as Inittab
entity "Runlevels (0-6)" as Runlevels
entity "chkconfig Command" as Chkconfig
entity "service Command" as ServiceSysV
}
package "Modern systemd" {
entity "systemd Daemon" as Systemd
entity "Target Units" as Targets
entity "systemctl Command" as Systemctl
entity "journalctl Command" as Journalctl
}
SysVinit ..> Inittab : Configures
SysVinit ..> Runlevels : Manages
Runlevels ..> Chkconfig : Lists Status
Runlevels ..> ServiceSysV : Checks Running Status
Systemd ..> Targets : Manages
Targets ..> Systemctl : Controls Activation
Systemctl ..> Systemd : Interacts with
Systemctl ..> Journalctl : Accesses Logs
SysVinit ..> ServiceSysV : Checks Running Status
Systemd ..> Systemctl : Checks Running Status
note left of Chkconfig
Shows configured status
across runlevels.
end note
note right of Systemctl
Comprehensive control
over units, including
status, start, stop,
enable, disable.
end note
@enduml
看圖說話：
此圖示對比了傳統 SysVinit 和現代 systemd 在服務管理機制上的演進。在傳統 SysVinit 時代，init 守護進程負責管理系統的運行層級，其配置主要依賴於 /etc/inittab 文件。chkconfig 指令用於檢視服務在各運行層級的配置狀態，而 service 指令則用於檢查服務是否實際運行。
進入 systemd 時代後，系統管理的核心轉向了「目標單元」（Target Units）的概念。systemd 守護進程成為了系統啟動和服務管理的中心。systemctl 指令取代了大部分傳統工具的功能，提供了對服務單元（包括目標單元、服務單元等）的啟動、停止、啟用、禁用以及狀態查詢等全面控制。此外，journalctl 指令則用於存取 systemd 統一的日誌系統，這對於診斷問題至關重要。整體而言，systemd 的架構更加模組化、並行化，並提供了更精細的控制能力。
!theme none !define DISABLE_LINK !define PLANTUML_FORMAT svg
系統啟動機制演進與服務管理實務
現代作業系統的啟動流程解析
在現代 Linux 系統架構中，系統的啟動過程已從傳統的 SysVinit 演進至更為高效且模組化的 systemd。過去，我們透過 /etc/inittab 文件來定義系統的運行層級（runlevel）與開機時啟動的程序。然而，隨著 systemd 的普及，這種機制被轉換為「目標單元」（target units）的概念。例如，傳統的 runlevel3.target 在 systemd 中被對應為 multi-user.target，而系統的預設啟動目標通常會透過軟連結 /etc/systemd/system/default.target 指向具體的目標單元，如 /lib/systemd/system/runlevel3.target。
傳統的 init 或 telinit 命令在 systemd 環境下，實際上會被轉譯成 systemctl isolate 指令，用以切換至指定的目標單元。例如，執行 init 3 等同於執行 systemctl isolate multi-user.target。雖然 runlevel 指令仍可查詢當前的傳統運行層級，但其使用已不被推薦，取而代之的是透過 systemctl status 或 systemctl list-units 等指令來檢視系統目標單元的狀態。
傳統 init 系統中負責啟動終端機登入程序的 getty 或 mingetty，在 systemd 中則由 getty.target 單元來管理。這個 getty.target 單元本身又被定義為依賴於 multi-user.target，這表示當系統進入多使用者模式時，終端機登入服務便會被啟用。
系統啟動目標單元關聯圖
@startuml
!define DISABLE_LINK
!define PLANTUML_FORMAT svg
!theme _none_
skinparam dpi auto
skinparam shadowing false
skinparam linetype ortho
skinparam roundcorner 5
skinparam defaultFontName "Microsoft JhengHei UI"
skinparam defaultFontSize 16
skinparam minClassWidth 100
entity "System Boot" as Boot
entity "Default Target" as DefaultTarget << (T,orange) Target >>
entity "Multi-User Target" as MultiUserTarget << (T,orange) Target >>
entity "Getty Target" as GettyTarget << (T,orange) Target >>
entity "Login Prompt" as LoginPrompt
Boot --> DefaultTarget : Determines
DefaultTarget --> MultiUserTarget : Isolate to
MultiUserTarget --> GettyTarget : Requires
GettyTarget --> LoginPrompt : Activates
note left of DefaultTarget
Represents the default system state upon boot.
Often linked to multi-user.target or graphical.target.
end note
note right of GettyTarget
Manages the spawning of terminal login processes (getty).
end note
@enduml
看圖說話：
此圖示描繪了現代 Linux 系統啟動時，目標單元（Target Units）之間的邏輯關聯。系統啟動（System Boot）的過程，最終會導向一個預設的啟動目標（Default Target），這個目標通常會被設定為 multi-user.target，代表系統已準備好提供多使用者服務。而 multi-user.target 的啟動，又會進一步觸發 getty.target 的啟用。getty.target 的核心職責是啟動終端機登入程序（getty），從而為使用者提供登入介面（Login Prompt），讓使用者能夠與系統互動。這個流程清晰地展示了 systemd 如何透過模組化的目標單元來管理系統的啟動過程，確保各項服務能夠依序且正確地啟動。
服務狀態的監控與管理
作為系統管理員，持續監控伺服器上運行的服務狀態至關重要。這不僅是為了確保系統的正常運作，更是為了及早發現潛在的安全威脅，例如未經授權或不再需要的服務。透過定期檢查，我們可以及時停用或移除這些不必要的服務，從而提升系統的安全性與效能。
傳統 SysVinit 系統的服務檢視
在仍使用傳統 SysVinit 機制的系統上，chkconfig --list 指令是檢視所有可用服務及其在不同運行層級（runlevel 0 至 6）下啟動狀態（on/off）的常用工具。透過此指令的輸出，我們可以一覽例如 ConsoleKit、NetworkManager、crond、cups、sshd 等服務在各運行層級的啟用情況。例如，sshd 服務通常會在運行層級 2 到 5 啟動，確保遠端 SSH 存取功能可用。
然而，chkconfig 指令僅能顯示服務的配置狀態，無法直接告知該服務當前是否正在運行。
現代 systemd 系統的服務狀態查詢
對於採用 systemd 的系統，systemctl 指令提供了更為強大且全面的服務管理功能。若要查看某個特定服務的詳細資訊，包括其是否正在運行、依賴關係等，可以使用 systemctl status <service_name>。例如，systemctl status sshd.service 會顯示 SSH 守護程式的當前狀態。
若要列出所有正在運行的服務單元，可以使用 systemctl list-units --type=service --state=running。這個指令能夠精確地篩選出目前處於運行狀態的服務，對於故障排除和效能分析非常有幫助。
服務運行狀態的綜合檢視
為了更全面地了解哪些服務正在運行，可以結合使用 service --status-all（在部分系統上仍可用）和 grep 指令。將 service --status-all 的輸出透過管道傳遞給 grep running，可以過濾出所有標記為「running」的服務及其進程 ID（PID）。
例如，執行 # service --status-all | grep running 可能會得到類似以下的輸出：
[ + ] anacron
[ + ] atd
[ + ] auditd
[ + ] automount
[ + ] console-kit-daemon
[ + ] crond
[ + ] cupsd
...
[ + ] sshd
[ + ] syslogd
[ + ] xfs
[ + ] yum-updatesd
這裡的 [ + ] 表示服務正在運行。
服務配置與運行狀態的關聯性分析
理解服務的配置狀態（例如，是否設定為開機啟動）與其實際運行狀態之間的差異，是系統管理員必須掌握的關鍵技能。一個服務可能被設定為在特定運行層級啟動，但由於其他原因（例如配置錯誤、依賴服務未啟動），它可能實際上並未運行。反之，一個未被設定為開機啟動的服務，也可能在系統運行期間被手動啟動。
例如，我們可以同時檢視 cups 服務的配置與運行狀態。首先，使用 chkconfig --list cups（適用於 SysVinit 系統）或 systemctl list-unit-files | grep cups（適用於 systemd 系統）來確認其開機啟動的配置。接著，使用 service cups status 或 systemctl status cups.service 來確認它目前是否正在運行。這種對比分析有助於我們全面掌握服務的生命週期管理。
服務管理架構演進圖
@startuml
!define DISABLE_LINK
!define PLANTUML_FORMAT svg
!theme _none_
skinparam dpi auto
skinparam shadowing false
skinparam linetype ortho
skinparam roundcorner 5
skinparam defaultFontName "Microsoft JhengHei UI"
skinparam defaultFontSize 16
skinparam minClassWidth 100
package "Traditional SysVinit" {
entity "init Daemon" as SysVinit
entity "/etc/inittab" as Inittab
entity "Runlevels (0-6)" as Runlevels
entity "chkconfig Command" as Chkconfig
entity "service Command" as ServiceSysV
}
package "Modern systemd" {
entity "systemd Daemon" as Systemd
entity "Target Units" as Targets
entity "systemctl Command" as Systemctl
entity "journalctl Command" as Journalctl
}
SysVinit ..> Inittab : Configures
SysVinit ..> Runlevels : Manages
Runlevels ..> Chkconfig : Lists Status
Runlevels ..> ServiceSysV : Checks Running Status
Systemd ..> Targets : Manages
Targets ..> Systemctl : Controls Activation
Systemctl ..> Systemd : Interacts with
Systemctl ..> Journalctl : Accesses Logs
SysVinit ..> ServiceSysV : Checks Running Status
Systemd ..> Systemctl : Checks Running Status
note left of Chkconfig
Shows configured status
across runlevels.
end note
note right of Systemctl
Comprehensive control
over units, including
status, start, stop,
enable, disable.
end note
@enduml
看圖說話：
此圖示對比了傳統 SysVinit 和現代 systemd 在服務管理機制上的演進。在傳統 SysVinit 時代，init 守護進程負責管理系統的運行層級，其配置主要依賴於 /etc/inittab 文件。chkconfig 指令用於檢視服務在各運行層級的配置狀態，而 service 指令則用於檢查服務是否實際運行。
進入 systemd 時代後，系統管理的核心轉向了「目標單元」（Target Units）的概念。systemd 守護進程成為了系統啟動和服務管理的中心。systemctl 指令取代了大部分傳統工具的功能，提供了對服務單元（包括目標單元、服務單元等）的啟動、停止、啟用、禁用以及狀態查詢等全面控制。此外，journalctl 指令則用於存取 systemd 統一的日誌系統，這對於診斷問題至關重要。整體而言，systemd 的架構更加模組化、並行化，並提供了更精細的控制能力。
!theme none !define DISABLE_LINK !define PLANTUML_FORMAT svg
綜合評估後，從 SysVinit 到 systemd 的演進不僅是技術工具的更迭，更深層次地反映了系統管理哲學的深刻變革。這套方法雖在初期為熟悉傳統腳本的管理者帶來了學習曲線與適應挑戰，但其以依賴關係為核心的宣告式管理模型，相較於 SysVinit 的程序化思維，展現了顯著的優越性。透過 systemctl 的精準控制與 journalctl 的整合式診斷能力，systemd 將分散的管理指令整合成一個高內聚、可觀測性強的框架，大幅提升了故障排除效率與系統穩定性。
展望未來，systemd 所倡導的模組化、並行化與狀態管理理念，其影響力已超越作業系統本身，並為當代雲原生技術，如容器化與 Kubernetes 等大規模編排平台的發展，奠定了堅實的哲學基礎。
玄貓認為，對高階管理者而言，引導技術團隊洞悉此一演進背後的架構思維，遠比僅僅掌握指令操作更為重要。這代表著從被動解決問題到主動設計系統韌性（Resilience）的關鍵轉型，是現代化 IT 治理不可或缺的一環。