記錄一次errno.ENOSPEC致使的supervisor啓動失敗

0x00 原由

最近公司的藍鯨發佈上線系統又一次 down 掉了，而以前搭建這個平臺的老哥已經離職，因此我也是臨危受命來負責處理這個問題，只隱約記得當時那位老哥好像是說過頻繁 down 掉的緣由是性能瓶頸，並升級過一次 ECS 的配置，因此我第一反應也認爲是機器性能瓶頸，然而事情並無那麼簡單。

0x01 分析

1. 現象分析

排查問題的過程我以爲和看病很類似，因此第一時間是看現象，當時的現象是 nginx 返回 502 code，而根據502 code 的含義和以往的經驗，我第一時間就想到的是後端服務 down 掉了，接下來一檢查，果真是如此。因此下一步是要把後端程序服務啓動起來。

2. 資料查閱

因爲我之間並無接觸過藍鯨這個發佈平臺，因此我第一次時間是去找官方文檔，而不是直接操做一把梭，這也是我在這幾年工做中摸索出來的重要的一點。在查閱了官方的的資料後，我大概清楚了藍鯨的軟件架構，並瞭解到了藍鯨的主要幾個服務是由 supervisor 託管的，那麼接下來就是須要把這幾個服務啓動起來了。

3. 問題處理

supervisor和 systemd 做爲 Linux 上用的最多的兩款進程管理系統，我仍是比較熟悉的，因此當我嘗試將supervisord 啓動的時候，卻報錯了：

Error: Cannot open an HTTP server: socket.error reported errno.ENOSPC (28)

當我看到這個錯誤的時候，和全部的程序員同樣，首先就是複製錯誤碼到 google 裏面搜索看有沒有結果。。。然而並無和我同樣的錯誤，我只好查閱 supervisor 的官方文檔，裏面也並無詳細的說明，接下來我又查了一些英文資料也無任何線索，我開始有些焦急了。

萬幸，我明白越是在排查問題的時候就越是要鎮靜，像無頭蒼蠅同樣亂飛是沒有任何效果的。因此我再仔細認真的讀了報錯信息的每個單詞，最後我以爲弄清楚error code，也就是 errno.ENOSPC (28)是關鍵，因此我改成搜索這個錯誤信息。

原來這個錯誤的意思在Node.js裏是 no space left on device.（設備上無剩餘空間），那麼在 supervisor 裏可能也是相似的，頓時我感受豁然開朗，那麼我接下來就是檢查磁盤空間了

但是磁盤空間仍然至關充足，我又一次迷惑了。。。就在這時，我忽然想起了不久前看過的一篇介紹 Linux文件系統的文章（說明平時技術的積累也很重要），文章裏說磁盤在執行文件系統格式化的時候，會分爲三個存儲區，分別是：

• 超級塊，存儲整個文件系統的狀態
• 索引節點區，用來存儲索引節點
• 數據塊區，用來存儲文件數據

既然/dev/vdb1的數據塊區是有空餘的，那麼索引節點是否是還有空餘的呢？我執行df -hi看了下

/dev/vdb1的IFree 爲 0，接下來我又在/data目錄裏面搜索了下，發現不少歷史遺留的日誌文件，至此真相大白了。

4. 緣由

之因此藍鯨進程啓動失敗的緣由就是/dev/vdb1塊設備上的索引節點被大量的日誌佔用光了，而以前的日誌清理腳本並無完全清理乾淨日誌，因此致使有時服務不可用。

0x02 解決

在找到問題的緣由後，我能作的解決方法有兩種：

1. 增長/dev/vdb1的索引節點
2. 定時刪除/dev/vdb1的日誌

在查閱了資料後，我發現方法一須要從新格式化塊設備

Do you want to increase the amount of inodes? Either increase the capacity of the disk entirely (Guide: Increase A VMware Disk Size (VMDK) LVM), or re-format the disk using mkfs.ext4 -i to manually overwrite the bytes-per-inode ratio.

因此這個方法是不可接受的。那麼我就只能採用定時刪除日誌的方法了,寫了個 crontab 的腳本執行定時任務

至此該問題完全解決

0x03 小結

此次又解決了一個問題，知足了我小小的成就感，然而我以爲更重要是我總結出了排查問題的要點：

1. 根據現象分析問題，不要憑直覺下手
2. 不要直接一把梭，幹事以前先閱讀說明文檔，大部分的問題說明文檔裏都有
3. 遇到問題是常態，不要焦躁，冷靜分析
4. 平時多技術積累，也許如今用不到，但總會有用到的時候

0x04 延伸資料

• 理解 Inode
• How To Increase Amount of Disk inodes in Linux（Linux 上如何增長 Inode）