案例現象

我在 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 是數字，為啟動的順序）

1. 透過 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 ）

 

---

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