## 17.1 什么是 daemon 與服務 （service） 我們在[第十六章](../Text/index.html#the_daemon)就曾經談過“服務”這東西！ 當時的說明是“常駐在記體體中的程序，且可以提供一些系統或網絡功能，那就是服務”。而服務一般的英文說法是“ service ”。 但如果你常常上網去查看一些數據的話，尤其是 Unix-Like 的相關操作系統，應該常常看到“請啟動某某 daemon 來提供某某功能”，唔！那么 daemon 與 service 有關啰？否則為什么都能夠提供某些系統或網絡功能？此外，這個 daemon 是什么東西呀？ daemon 的字面上的意思就是“守護神、惡魔？”還真是有點奇怪呦！^_^""！ 簡單的說，系統為了某些功能必須要提供一些服務 （不論是系統本身還是網絡方面），這個服務就稱為 service 。 但是 service 的提供總是需要程序的運行吧！否則如何執行呢？所以達成這個 service 的程序我們就稱呼他為 daemon 啰！ 舉例來說，達成循環型例行性工作調度服務 （service） 的程序為 crond 這個 daemon 啦！這樣說比較容易理解了吧！  **Tips** 你不必去區分什么是 daemon 與 service ！事實上，你可以將這兩者視為相同！因為達成某個服務是需要一支 daemon 在背景中運行， 沒有這支 daemon 就不會有 service ！所以不需要分的太清楚啦！ 一般來說，當我們以文字模式或圖形模式 （非單人維護模式） 完整開機進入 Linux 主機后， 系統已經提供我們很多的服務了！包括打印服務、工作調度服務、郵件管理服務等等； 那么這些服務是如何被啟動的？他們的工作型態如何？下面我們就來談一談啰！  **Tips** daemon 既然是一只程序執行后的程序，那么 daemon 所處的那個原本的程序通常是如何命名的呢 （daemon 程序的命名方式）。 每一個服務的開發者，當初在開發他們的服務時，都有特別的故事啦！不過，無論如何，這些服務的名稱被創建之后，被掛上 Linux 使用時，通常在服務的名稱之后會加上一個 d ，例如例行性命令的創建的 at, 與 cron 這兩個服務， 他的程序文件名會被取為 atd 與 crond，這個 d 代表的就是 daemon 的意思。所以，在[第十六章](../Text/index.html)中，我們使用了 ps 與 top 來觀察程序時，都會發現到很多的 {xxx}d 的程序，呵呵！通常那就是一些 daemon 的程序啰！ ### 17.1.1 早期 System V 的 init 管理行為中 daemon 的主要分類 （Optional） 還記得我們在[第一章](../Text/index.html)談到過 Unix 的 system V 版本吧？那個很純種的 Unix 版本～ 在那種年代下面，我們啟動系統服務的管理方式被稱為 SysV 的 init 腳本程序的處理方式！亦即系統核心第一支調用的程序是 init ， 然后 init 去喚起所有的系統所需要的服務，不論是本機服務還是網絡服務就是了。 基本上 init 的管理機制有幾個特色如下： * 服務的啟動、關閉與觀察等方式： 所有的服務啟動腳本通通放置于 /etc/init.d/ 下面，基本上都是使用 bash shell script 所寫成的腳本程序，需要啟動、關閉、重新啟動、觀察狀態時， 可以通過如下的方式來處理： * 啟動：/etc/init.d/daemon start * 關閉：/etc/init.d/daemon stop * 重新啟動：/etc/init.d/daemon restart * 狀態觀察：/etc/init.d/daemon status * 服務啟動的分類： init 服務的分類中，依據服務是獨立啟動或被一只總管程序管理而分為兩大類： * 獨立啟動模式 （stand alone）：服務獨立啟動，該服務直接常駐于內存中，提供本機或用戶的服務行為，反應速度快。 * 總管程序 （super daemon）：由特殊的 xinetd 或 inetd 這兩個總管程序提供 socket 對應或 port 對應的管理。當沒有用戶要求某 socket 或 port 時， 所需要的服務是不會被啟動的。若有用戶要求時， xinetd 總管才會去喚醒相對應的服務程序。當該要求結束時，這個服務也會被結束掉～ 因為通過 xinetd 所總管，因此這個家伙就被稱為 super daemon。好處是可以通過 super daemon 來進行服務的時程、連線需求等的控制，缺點是喚醒服務需要一點時間的延遲。 * 服務的相依性問題： 服務是可能會有相依性的～例如，你要啟動網絡服務，但是系統沒有網絡， 那怎么可能可以喚醒網絡服務呢？如果你需要連線到外部取得認證服務器的連線，但該連線需要另一個A服務的需求，問題是，A服務沒有啟動， 因此，你的認證服務就不可能會成功啟動的！這就是所謂的服務相依性問題。init 在管理員自己手動處理這些服務時，是沒有辦法協助相依服務的喚醒的！ * 執行等級的分類： 上面說到 init 是開機后核心主動調用的， 然后 init 可以根據使用者自訂的執行等級 （runlevel） 來喚醒不同的服務，以進入不同的操作界面。基本上 Linux 提供 7 個執行等級，分別是 0, 1, 2...6 ， 比較重要的是 1）單人維護模式、3）純文本模式、5）文字加圖形界面。而各個執行等級的啟動腳本是通過 /etc/rc.d/rc[0-6]/SXXdaemon 鏈接到 /etc/init.d/daemon ， 鏈接文件名 （SXXdaemon） 的功能為： S為啟動該服務，XX是數字，為啟動的順序。由于有 SXX 的設置，因此在開機時可以“依序執行”所有需要的服務， 同時也能解決相依服務的問題。這點與管理員自己手動處理不太一樣就是了。 * 制定執行等級默認要啟動的服務： 若要創建如上提到的 SXXdaemon 的話，不需要管理員手動創建鏈接文件， 通過如下的指令可以來處理默認啟動、默認不啟動、觀察默認啟動否的行為： * 默認要啟動： chkconfig daemon on * 默認不啟動： chkconfig daemon off * 觀察默認為啟動否： chkconfig --list daemon * 執行等級的切換行為： 當你要從純命令行 （runlevel 3） 切換到圖形界面 （runlevel 5）， 不需要手動啟動、關閉該執行等級的相關服務，只要“ init 5 ”即可切換，init 這小子會主動去分析 /etc/rc.d/rc[35].d/ 這兩個目錄內的腳本， 然后啟動轉換 runlevel 中需要的服務～就完成整體的 runlevel 切換。 基本上 init 主要的功能都寫在上頭了，重要的指令包括 daemon 本身自己的腳本 （/etc/init.d/daemon） 、xinetd 這個特殊的總管程序 （super daemon）、設置默認開機啟動的 chkconfig， 以及會影響到執行等級的 init N 等。雖然 CentOS 7 已經不使用 init 來管理服務了，不過因為考慮到某些腳本沒有辦法直接塞入 systemd 的處理，因此這些腳本還是被保留下來， 所以，我們在這里還是稍微介紹了一下。更多更詳細的數據就請自己查詢舊版本啰！如下就是一個可以參考的版本： * [http://linux.vbird.org/linux_basic/0560daemons/0560daemons-centos5.php](http://linux.vbird.org/linux_basic/0560daemons//0560daemons-centos5.php) ### 17.1.2 systemd 使用的 unit 分類 從 CentOS 7.x 以后，Red Hat 系列的 distribution 放棄沿用多年的 System V 開機啟動服務的流程，就是前一小節提到的 init 啟動腳本的方法， 改用 systemd 這個啟動服務管理機制～那么 systemd 有什么好處呢？ * 平行處理所有服務，加速開機流程： 舊的 init 啟動腳本是“一項一項任務依序啟動”的模式，因此不相依的服務也是得要一個一個的等待。但目前我們的硬件主機系統與操作系統幾乎都支持多核心架構了， 沒道理未相依的服務不能同時啟動啊！systemd 就是可以讓所有的服務同時啟動，因此你會發現到，系統啟動的速度變快了！ * 一經要求就回應的 on-demand 啟動方式： systemd 全部就是僅有一只 systemd 服務搭配 systemctl 指令來處理，無須其他額外的指令來支持。不像 systemV 還要 init, chkconfig, service... 等等指令。 此外， systemd 由于常駐內存，因此任何要求 （on-demand） 都可以立即處理后續的 daemon 啟動的任務。 * 服務相依性的自我檢查： 由于 systemd 可以自訂服務相依性的檢查，因此如果 B 服務是架構在 A 服務上面啟動的，那當你在沒有啟動 A 服務的情況下僅手動啟動 B 服務時， systemd 會自動幫你啟動 A 服務喔！這樣就可以免去管理員得要一項一項服務去分析的麻煩～（如果讀者不是新手，應該會有印象，當你沒有啟動網絡， 但卻啟動 NIS/NFS 時，那個開機時的 timeout 甚至可達到 10~30 分鐘...） * 依 daemon 功能分類： systemd 旗下管理的服務非常多，包山包海啦～為了厘清所有服務的功能，因此，首先 systemd 先定義所有的服務為一個服務單位 （unit），并將該 unit 歸類到不同的服務類型 （type） 去。 舊的 init 僅分為 stand alone 與 super daemon 實在不夠看，systemd 將服務單位 （unit） 區分為 service, socket, target, path, snapshot, timer 等多種不同的類型（type）， 方便管理員的分類與記憶。 * 將多個 daemons 集合成為一個群組： 如同 systemV 的 init 里頭有個 runlevel 的特色，systemd 亦將許多的功能集合成為一個所謂的 target 項目，這個項目主要在設計操作環境的創建， 所以是集合了許多的 daemons，亦即是執行某個 target 就是執行好多個 daemon 的意思！ * 向下相容舊有的 init 服務腳本： 基本上， systemd 是可以相容于 init 的啟動腳本的，因此，舊的 init 啟動腳本也能夠通過 systemd 來管理，只是更進階的 systemd 功能就沒有辦法支持就是了。 雖然如此，不過 systemd 也是有些地方無法完全取代 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 還有很多特殊的服務類型 （type） 可以提供更多有趣的功能！確實值得學一學～ 而且 CentOS 7 已經用了 systemd 了！想不學也不行啊～哈哈哈！好～既然要學，首先就得要針對 systemd 管理的 unit 來了解一下。 * 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 類型分類說明 那 /usr/lib/systemd/system/ 以下的數據如何區分上述所謂的不同的類型 （type） 呢？很簡單！看擴展名！舉例來說，我們來瞧瞧上一章談到的 vsftpd 這個范例的啟動腳本設置， 還有 crond 與純文本模式的 multi-user 設置： ``` [root@study ~]# ll /usr/lib/systemd/system/ | grep -E '（vsftpd|multi|cron）' -rw-r--r--. 1 root root 284 7月 30 2014 crond.service -rw-r--r--. 1 root root 567 3月 6 06:51 multipathd.service -rw-r--r--. 1 root root 524 3月 6 13:48 multi-user.target drwxr-xr-x. 2 root root 4096 5月 4 17:52 multi-user.target.wants lrwxrwxrwx. 1 root root 17 5月 4 17:52 runlevel2.target -> multi-user.target lrwxrwxrwx. 1 root root 17 5月 4 17:52 runlevel3.target -> multi-user.target lrwxrwxrwx. 1 root root 17 5月 4 17:52 runlevel4.target -> multi-user.target -rw-r--r--. 1 root root 171 6月 10 2014 vsftpd.service -rw-r--r--. 1 root root 184 6月 10 2014 vsftpd@.service -rw-r--r--. 1 root root 89 6月 10 2014 vsftpd.target # 比較重要的是上頭提供的那三行特殊字體的部份！ ``` 所以我們可以知道 vsftpd 與 crond 其實算是系統服務 （service），而 multi-user 要算是執行環境相關的類型 （target type）。根據這些擴展名的類型， 我們大概可以找到幾種比較常見的 systemd 的服務類型如下： | 擴展名 | 主要服務功能 | | --- | --- | | .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 更加有彈性！ | 其中又以 .service 的系統服務類型最常見了！因為我們一堆網絡服務都是通過這種類型來設計的啊！接下來，讓我們來談談如何管理這些服務的啟動與關閉。