案例現象

我在 3 月 31日的時候發表了一篇《shell 腳本之一鍵部署安裝 Nginx》，介紹瞭如何通過 shell 腳本一鍵安裝 Nginx

我腳本中執行了 Nginx 開機自啟動的命令，當我使用 systemctl status nginx 命令覆核的時候，我發現 Nginx 服務設置開機自啟動並沒有生效

使用下麵的命令設置一下

通常來說，設置開機自啟動其實就是將 nginx.service 這個文件創建一個軟連接然後掛在/etc/systemd/system/multi-user.target.wants/ 目錄下麵

舉個例子，我要將 atd.service 設置開機自啟動

可以看到設置了開機自啟動的服務都在這個目錄下麵有軟連接，但是沒有 Nginx 服務

我們使用下麵的命令來看下 nginx 服務有沒有設置開機自啟動

奇怪，怎麼 systemctl enable nginx.service 沒有生效？

手動創建一下軟鏈接試試

 發現設置開機自啟動成功

問題：使用 systemctl 命令不能設置 nginx 服務開機自啟動，需要手動去掛載軟連接

定位問題

在排查問題之前，我先給大家簡單介紹一下 daemon 與 服務（service）

daemon 與 服務（service）

我們知道，在 Linux 中，服務（service）其實就是一個個程式，它們能夠實現某一功能、提供某一服務

但通常我們在查閱類 Unix 系統相關的技術文檔時，又經常會看到“請啟動某某 daemon 來提供某某功能”

那麼這個 daemon 到底是啥意思？它跟 service 有什麼區別？

簡單點來說，系統為了實現某些功能必須要提供一些服務（比如想要實現負載均衡的功能需要提供 Nginx 服務）

但是提供的 service 需要程式的運作（例如你需要啟動 Nginx 進程），所以我們一般認為使系統能夠提供某些 service 的程式稱作 daemon（例如使系統能夠提供負載均衡服務的程式 nginx 為 daemon）

看到這裡小伙伴們可能都暈了，說實話我第一次看到的時候也是這樣的

其實你不必去區分什麼是 daemon 和 service，因為提供某一 service 是需要一個 daemon 在運作，沒有這個運作的 daemon 就不會有這個 service

無論是命令行模式（runlevel 3），還是圖像界面模式（runlevel 5），我們在開機進入 Linux 主機之後，系統已經開始提供很多 service 了（例如 sshd ）

那麼這些 service 是如何啟動的，系統又是怎麼管理它們的呢？

在早期 Linux 是使用 SystemV 來管理服務的，啟動系統服務的管理方式被稱為 SysV 的 init 腳本處理方式——系統內核第一個程式是 init，然後 init 去喚起所有系統需要的服務

SystemV 管理服務的開機自啟動有兩種方式：

1. 通過掛軟連接的方式

將 /etc/rc.d/rc[0-6]/SXX 服務名字掛載到 /etc/init.d/ 下（其中 SXX 中的 S 表示啟動該服務，XX 是數字，為啟動的順序）

2. 通過 chkconfig 命令

創建軟連接的方式比較麻煩，一般來說都是用命令來管理

但是 CentOS 7 之後就放棄了使用多年的 SystemV ，改用 systemd 來管理服務

systemd 管理服務

systemd 將過去所謂的 daemon 程式稱作一個個服務單位（unit），而每個 unit 根據功能來區分成不同的類型（type）：

• 系統服務（service）

• 負責網路數據監聽與交換的服務（socket）

• 快照服務（sanpshot）

而且 systemd 將許多的 unit 集合成一個所謂的 target 項目，你執行某個 target 其實就是執行 target 下的多個 unit

可能有小伙伴覺得，這麼多 unit 分成不同的 type，然後又被合集到不同的 target ，管理起來不會很麻煩嗎

其實也還好，因為相關的文件都存放在下麵的目錄當中了

總結，系統開機會不會執行某些服務是看 /etc/systemd/system/ 目錄下有沒有該服務的啟動腳本，而服務的啟動腳本是放在 /usr/lib/systemd/system/下的

systemctl 命令

systemd 來管理服務的方式是通過 systemctl 命令，相較於 SysV 通過 service / chkconfig / setup / init 一堆命令，systemd 管理服務的方式簡單多了

 

 PS：關閉服務除了 systemctl 命令，也能用 kill 命令的方式，但是這兩個命令不要混用！

 服務的狀態

• 服務的當前狀態：

• active (running)：表示服務正在運行

• active (exited)：表示該服務執行一次就正常結束，目前沒有執行

• active (waiting)：表示該服務正在運行，不要需要等待其他事件執行之後才能繼續處理

• inactive：表示服務目前關閉，沒有運行

• 服務預設狀態：

• enable：開機的時候將自啟動

• disable：開機的時候不會自啟動

• static：這個服務不會開機自啟動，但是有可能會被其他開機自啟動的服務來喚醒（依賴性）

• mask：無論如何都不會被啟動，因為已經被強制註銷

服務的啟動文件

前面我們說過，服務的啟動腳本文件放在  /usr/lib/systemd/system/下的，如果需要對服務的啟動腳本文件修改，需要進入到該目錄下（官方不建議直接修改該目錄下的文件，但是會比較麻煩且繁瑣）

 我們就拿 sshd.service 舉例，來瞭解下服務的啟動腳本裡面的配置欄位

分析上面文件中的內容，我們可以看到分成了三個部分（block）：

• [Unit]

• unit（即服務）本身的說明，以及與其他服務的依賴性設定（After、Wants 欄位）

• [Service]

• 還有 [Socket], [Timer], [Mount], [Path] 等等，不同的 type 就用不同的欄位

• 我們拿的是 sshd.service，所以就是 [Service]

• 這個部分中主要規定了服務的啟動腳本、環境文件名、重啟方式等等

• [Install]

• 表示這個服務安裝到哪個 target 下麵去

• 這部分與 systemctl enable 或  systemctl disable 命令相結合，用於 enable 或 disable 一個服務

下麵我將分別列出三個部分的一些常見配置欄位

 解決問題

現在我們已經大致對 Linux 的服務有了一個初步瞭解

我們回到剛開始的問題：nginx 服務無法通過 systemctl 命令設置開機自啟動，手動掛載軟連接之後自啟動狀態不是 enable ，而是 static

既然是跟 systemctl 相關的，我們去看下 nginx 的服務啟動腳本

可以看到，這台機器上 nginx 的服務啟動腳本只有兩個部分（[Unit]、[Service]），並沒有 [Install]

而  [Install] 部分往往是跟服務的開機自啟動相關

 我們加上 [Install]

其中 multi-user.target 表示命令行模式（即等效於系統運行級別為 3 ）

而 WantedBy表示該服務放在哪個 target 下，一般來講 WantedBy 對應的 target 為指定系統的運行級別

然後重啟一下 nginx 啟動腳本文件

 設置開機自啟動，發現創建軟連接成功了

 看下狀態

總結：

• 一般來講，服務無法設置開機自啟動首先考慮是不是服務啟動腳本配置有問題（/usr/lib/systemd/system/ 目錄下），這種情況常見於編譯安裝的時候需要自己編寫服務啟動文件

• 服務能夠開機自啟動其實就是將 /usr/lib/systemd/system/ 目錄下的服務啟動腳本掛載到了 /etc/systemd/system/ 下，一般是掛載到 /etc/systemd/system/multi-user.target.wants/

• multi-user.target.wants：表示啟動了 multi-user.target 之後（即系統啟動且運行級別為 3，為系統的預設啟動 target）這個目錄下的文件都會跟著啟動

• systemctl status 命令顯示的內容裡面有一個 vendor preset: disabled 欄位，這個表示該服務首次安裝之後不會自啟動，需要手動啟動（systemctl enable）

感謝閱讀，喜歡作者就動動小手[一鍵三連]，這是我寫作最大的動力