systemd 服務管理指令

Systemd 服務管理系統差異

Unix 為中心的各類版本 Linux 在 CentOS 7 之前的啟動系統服的管理方式被稱為 System V , 是由第一隻程式 init 一一喚起所有系統需要的服務.
在這 System V為主的狀況下, 許多老經驗的 Linux 管理者多也習慣應用啟動腳本管理服務, 這些使用 Shell Script 建立的腳, 一般共同都會放置在 /etc/init.d 目錄底下, 採用如下操作管理服務.
PS. 基本管理通常都會有以下幾個, 但也有某些服務追加一些協助項目, 如確認設定檔等.

狀態檢視	/etc/init.d/service status
啟動服務	/etc/init.d/service start
停止服務	/etc/init.d/service stop
重啟服務	/etc/init.d/service restart
重載服務	/etc/init.d/service reload

並且透過以下指令定義服務於啟動作業系統的同時, 判定是否同時進行啟動程序.

預設要啟動	chkconfig service on
預設不要啟動	chkconfig service off
確認服務預設狀態	chkconfig --list service

不過到 CentOS 7 以後, 不再沿用多年的 System V 開機啟動服務流程, 將原有的 init 啟動改為 systemd 這服務管理機制, 透過 systemd 有什麼好處理呢！

平行處理所有服務, 加速開機流程

由於現在的硬體規格不斷的提升, 並且已走向多核心架構, 過去可能是一項一項來進行程序, 所以也造成較花費時間開機程序, 可是在多核心的架構下, 未相依的服務已是可各別啟動的, 所以可以提高整體開機速度, 相信剛安裝完成 CentOS 的管理者, 應該可以明顯的感受到.

一經要求就回應的 on-demand 啟動模式

在過去 system V 裡需要透過不同的如 chkconfig, service 等指令管務,但 systemd 為常駐記憶體, 所以任何要求都是 on-demand 的狀態,可以隨時透過 systemd 中的 systemctl 指令來處理所以行為, 不需額外的指令來支援.

服務相依性的自我檢查

所以的服務往往可能會與某些服務一起運行, 才可算完整的服務, 例如服務需要基本的網路啟用, 但網路都未啟用下, 服務是無法啟用, 但透過 systemd 的管理下, 會自動回覆管理者, 是否有對應服務無正常啟用的訊息.

依 Daemon 功能分類

由於 systemd 可算是將所有務務一次管理的功能, 所以 systemd 先所有務為一個服單位(unit), 並將該 unit 歸類到不同的服務類型裡, 可區分為 service、socket、target、path、snapshot、timer 等, 使管理者方便分類與記憶.

將多個 Daemons 集合成為一個群組

runlevel 是在 system V 的系統裡, 定義服務於何等環境下執行的分類, 而 systemd 亦有雷同的集合為一個所謂的 target 項目, 這項目主要在設計操作環境的建置, 所以是集合了許多的 daemons，亦即是執行某個 target 就是執行好多個 Daemon 的意思.

向下相容舊有的 init 服務腳本

舊有的 init 啟動腳本也能透過 systemd 來管理, 只是更進階的 systemd 功能就沒有辦法支援.

雖然說 systemd 看似完美的改善 system V 一般, 但它還是無法完全的取代 init 的, 分別有以下幾個點.

• 在 runlevel 的對應上，大概僅有 runlevel 1, 3, 5 有對應到 systemd 的某些 target 類型而已，沒有全部對應
• 全部的 systemd 都用 systemctl 這個管理程式管理，而 systemctl 支援的語法有限制，不像 /etc/init.d/daemon 就是純腳本可以自訂參數，systemctl 不可自訂參數.
• 如果某個服務啟動是管理員自己手動執行啟動，而不是使用 systemctl 去啟動的 (例如你自己手動輸入 crond 以啟動 crond 服務)，那麼 systemd 將無法偵測到該服務，而無法進一步管理
• systemd 啟動過程中，無法與管理員透過 standard input 傳入訊息！因此，自行撰寫 systemd 的啟動設定時，務必要取消互動機制～(連透過啟動時傳進的標準輸入訊息也要避免！)

systemd 的設定檔放置目錄

基本上， systemd 將過去所謂的 daemon 執行腳本通通稱為一個服務單位 (unit)，而每種服務單位依據功能來區分時，就分類為不同的類型 (type)。 基本的類型有包括系統服務、資料監聽與交換的插槽檔服務 (socket)、儲存系統狀態的快照類型、提供不同類似執行等級分類的操作環境 (target) 等等。

/usr/lib/systemd/system/

每個服務最主要的啟動腳本設定，有點類似以前的 /etc/init.d 底下的檔案

/run/systemd/system/

系統執行過程中所產生的服務腳本，這些腳本的優先序要比 /usr/lib/systemd/system/ 優先

/etc/systemd/system/

管理員依據主機系統的需求所建立的執行腳本，其實這個目錄有點像以前 /etc/rc.d/rc5.d/Sxx 之類的功能！執行優先序又比 /run/systemd/system/ 優先

到底系統開機會不會執行某些服務其實是看 /etc/systemd/system/ 底下的設定，所以該目錄底下就是一大堆連結檔。而實際執行的 systemd 啟動腳本設定檔， 其實都是放置在 /usr/lib/systemd/system/ 底下！因此如果想要修改某個服務啟動的設定，應該需要至 /usr/lib/systemd/system/ 底下修改！ /etc/systemd/system/ 僅是連結到正確的執行腳本設定檔。所以想要看執行腳本設定，應該就得要到 /usr/lib/systemd/system/ 底下去查閱！

systemd 的 unit 分類說明

基本上 unit 類型分類, 只要可以透過副檔名進行辨識, 分別依據以下表格說明分類：

副檔名	類型說明
.service	一般服務類型 (service unit)：主要是系統服務，包括伺服器本身所需要的本機服務以及網路服務都是！比較經常被使用到的服務大多是這種類型！ 所以，這也是最常見的類型了！
.socket	內部程序資料交換的插槽服務 (socket unit)：主要是 IPC (Inter-process communication) 的傳輸訊息插槽檔 (socket file) 功能。 這種類型的服務通常在監控訊息傳遞的插槽檔，當有透過此插槽檔傳遞訊息來說要連結服務時，就依據當時的狀態將該用戶的要求傳送到對應的 daemon， 若 daemon 尚未啟動，則啟動該 daemon 後再傳送用戶的要求。 使用 socket 類型的服務一般是比較不會被用到的服務，因此在開機時通常會稍微延遲啟動的時間 (因為比較沒有這麼常用嘛！)。一般用於本機服務比較多，例如我們的圖形界面很多的軟體都是透過 socket 來進行本機程序資料交換的行為。 (這與早期的 xinetd 這個 super daemon 有部份的相似喔！)
.target	執行環境類型 (target unit)：其實是一群 unit 的集合，例如上面表格中談到的 multi-user.target 其實就是一堆服務的集合～也就是說， 選擇執行 multi-user.target 就是執行一堆其他 .service 或/及 .socket 之類的服務就是了！
.mount .automount	檔案系統掛載相關的服務 (automount unit / mount unit)：例如來自網路的自動掛載、NFS 檔案系統掛載等與檔案系統相關性較高的程序管理。
.path	偵測特定檔案或目錄類型 (path unit)：某些服務需要偵測某些特定的目錄來提供佇列服務，例如最常見的列印服務，就是透過偵測列印佇列目錄來啟動列印功能！ 這時就得要 .path 的服務類型支援了！
.timer	循環執行的服務 (timer unit)：這個東西有點類似 anacrontab 喔！不過是由 systemd 主動提供的，比 anacrontab 更加有彈性！