哈嘍大家好,我是鹹魚。今天跟大家分享一個關於 Linux 服務(service)相關的案例 案例現象 我在 3 月 31日的時候發表了一篇《shell 腳本之一鍵部署安裝 Nginx》,介紹瞭如何通過 shell 腳本一鍵安裝 Nginx 我腳本中執行了 Nginx 開機自啟動的命令,當我使用 sy ...
哈嘍大家好,我是鹹魚。今天跟大家分享一個關於 Linux 服務(service)相關的案例
案例現象
我在 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 管理服務的開機自啟動有兩種方式:
-
通過掛軟連接的方式
將 /etc/rc.d/rc[0-6]/SXX
服務名字掛載到 /etc/init.d/
下(其中 SXX 中的 S 表示啟動該服務,XX 是數字,為啟動的順序)
-
通過 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
)
感謝閱讀,喜歡作者就動動小手[一鍵三連],這是我寫作最大的動力