記一次服務(wù)器排錯
1.背影
最近, 公司一臺服務(wù)器動不動就癱, 從監(jiān)控上看, 基本都是內(nèi)存枯竭。在間隙中查看了服務(wù)器進程后, 發(fā)現(xiàn)了罪魁禍首……
可以看到, 我們的服務(wù)器被大量的sshd進程塞得滿滿當當(當時比500還要多一些, 達到了恐怖的830+), 服務(wù)器發(fā)出不堪重負的呻吟：我已經(jīng)……一滴都沒有了……
和開發(fā)小姐姐溝通后了解到, 這些sshd進程是業(yè)務(wù)里需要用到的進程, 不能取消。后面的故事大家都知道了, 據(jù)說服務(wù)器走的時候, 臉上是帶著笑的, 很是安詳。
到這里, 業(yè)務(wù)自然也跟著一起死了, 所有服務(wù)全掛變磚, 根本無法訪問。就這樣,服務(wù)器把我一個人晾在那邊, 自己買橘子去了。
2. 抉擇
經(jīng)過一通胡亂分析, 擺在面前有兩條路：
等待占用進程執(zhí)行完畢, 內(nèi)存被釋放后, 服務(wù)器一夜好夢, 自然蘇醒, 事實上第二天中午服務(wù)器確實蘇醒了, 然而不不到半個小時, 又被塞得滿滿當當, 翻起白眼來。
在所有服務(wù)都死了的情況下, 不指望服務(wù)器能死者蘇生, 俗話說得好, 運維有三寶：重啟重裝換電腦。畢竟內(nèi)存這東西就和夫妻吵架不過夜一樣, 一重啟自然就回到了夢開始的地方。
說實話, 這臺服務(wù)器我并不敢隨便重啟, 究其原因, 是自己剛接手這臺服務(wù)器, 接手時也沒有具體文檔, 其上組件應(yīng)用和業(yè)務(wù)邏輯均不可知, 一旦重啟, 服務(wù)是否齊全、如何去恢復(fù)均是未知。
但讓業(yè)務(wù)癱著總不是個辦法, 本著事在人為的探索精神, 對著翻白眼的服務(wù)器使用了大招：究極薅電源。
3. 夢魘
就在自己盤算著缺服務(wù)少配置的時候怎么去向開發(fā)請教的時候,真正的噩夢不知不覺的來到了。
在我還沒緩過氣來的時候, 屏幕上一個大大的"初始化實例"出現(xiàn), 本來, 云主機在開啟的過程中必然會經(jīng)歷這樣一個過程, 但這個時間實在是太漫長了, 以至于甚至打開QQ群吹了十分鐘水它還在初始化實例。
這宛如當年碰到的小機靈鬼瞎改fstab的熟悉氣息, 感謝天感謝地, 啟動失敗這種事都被我遇上了。機子啟動老不好, 多半是廢了掛載問題。于是我新建一臺云主機, 將老機子的硬盤掛載到了新機子下, 準備看看到底是哪里出了問題。然鵝我不知道的是, 前面不是一個解密的過程, 而是一個接一個的連環(huán)坑……
首先, 多年來的經(jīng)驗驅(qū)使我直奔老硬盤上的etc/fstab, 打開一看, 里面只有一個形單影只的根目錄——很明顯, 沒有額外的存儲設(shè)備掛載, 自然也不會存在掛載失敗的問題, 第一條pass。
那么, 還有沒有哪里能夠找到蛛絲馬跡呢？稍加思索后, 我決定從啟動日志里尋找報錯信息。于是我進入了var/log/開始尋找boot.log……
?等等……我的boot.log呢？！幾秒鐘之后, 我的表情發(fā)生了微妙的變化……在log目錄下, 我沒有看到任何與boot相關(guān)的日志, 盯著電腦屏幕陷入了
呆滯沉思
4. 巧合
回過神來的我, 只好拿去GHS的精神去各個地方查閱相關(guān)資料。
因為系統(tǒng)是Debian, 且是較老的8.0, 國內(nèi)百度幾乎沒有我需要的資料, /var/log下沒有啟動日志, 哪怕是dmesg文件在訪問時也顯示為空。
在將近兩個小時的尋找無果后, 我已經(jīng)準備放棄時, 角落里一個dmesg這個命令引起了我的注意。抱著死馬當成活馬醫(yī)的心態(tài), 輸入了次此命令, 成功的看到了啟動日志, 可喜可賀可喜可賀。
這里值得一提的是, 如果是在另一個系統(tǒng)中的話, 是沒法使用dmesg命令查看的, 因此我是在原系統(tǒng)中使用的dmesg命令。那么問題來了, 既然系統(tǒng)沒法啟動, 我又是怎么進入的原系統(tǒng)呢？
這里應(yīng)該有一張圖：優(yōu)質(zhì)解答——我不知道.jpg, 因為進入系統(tǒng)的方法更像是巧合。下面來看一下我是怎么進入系統(tǒng)的……
我們知道, 為了查看問題所在, 我們建了一個新的系統(tǒng), 而我為了測試"是不是debian都是一關(guān)機就再也起不來的"這種無聊的問題, 為什么我會有這樣的想法, 因為前兩天剛裝了一下debian, 想保留原本的win的情況下安裝的debian給我的體驗非常之差, 關(guān)機各種grub引導(dǎo)報錯, 一會兒能開一會不能開, 無限接近于"一關(guān)機就起不來"。
而在這種想法的引導(dǎo)下, 我將兩個盤來回掛載和卸載, 然后在某次掛載后, 我驚訝的發(fā)現(xiàn)：
在控制臺中的硬盤是這樣的：
而在機器中的硬盤是這樣的：
可以看到, 趁著亞馬遜服務(wù)器不注意, 我們悄悄把掛載的硬盤進行了一個偷梁換柱, 實現(xiàn)了開機……個鬼。此處顯示的根分區(qū)掛載明顯對不上, 但這種錯誤的掛載反而能夠開機, 這一定是amazon的問題.jpg
而dmesg日志中有兩處報紅：
有了報錯信息, 就能將問題逐漸定位了, 這時候我感覺自己信心十足, 嗯, 事實證明了感覺終究只是感覺。
5. 吃瓜
那么真相只有一個, 那就是autofs！畢竟, 它的報錯長一些(好吧, 其實是因為一開始并沒有使用dmesg -T, 因此看不到報錯時間, 時間那里顯示的是 7.855319這樣的數(shù)字), 于是我順著/dev/autofs去查起來, 度娘依然跟個惹不起一樣靠不住, 萬般無奈一下掛了SOCKS5去谷歌看資料, 然后我查到了一個東西：
https://github.com/systemd/systemd/issues/9501
作為吃瓜群眾, 我看完了這群人的爭論, 翻譯一下大概就是：在內(nèi)核3-4版本的中間, 內(nèi)核編寫人員決定去掉autofs4這么個模塊, 但debian系統(tǒng)好像并沒有跟上, 于是系統(tǒng)去調(diào)用了內(nèi)核中不存在的模塊導(dǎo)致報錯, 而服務(wù)器因為這個掛載失敗, 系統(tǒng)無法啟動?？粗土旨{斯一起編內(nèi)核的哥們和別人爭論的亞子, 這瓜吃的賊開心。
但吃瓜歸吃瓜, 問題總要去著手解決, 我花了一定的時間去分析這個問題是如何產(chǎn)生的, 并研究這個問題該如何解決。
首先, 從那哥們的發(fā)言來看, 內(nèi)核中應(yīng)該是刪除了autofs的相關(guān)文件, 事實上, 我確實沒有在磁盤中找到autofs4文件, 但令我十分不解的是, /dev下莫名地多出了一個/dev/autofs。而啟動日志中我們很明顯的可以看到"systemd[1]: Failed to open /dev/autofs: No such file or directory"。是我瞎了還是服務(wù)器瞎了？
我只能認為這是服務(wù)器"打了個盹"的產(chǎn)物——還記得上面提到的那奇葩的根分區(qū)掛載嗎？因此我提出一個猜想：/dev下的autofs是原本應(yīng)該掛在根目錄下的新盤(xvda)中的東西, 而服務(wù)器在啟動時由于Amazon控制臺出現(xiàn)了bug反倒將autofs作為老硬盤(xvdf)中的文件掛載上了, 因此啟動成功。當然, 這是胡亂猜測, 沒有特別實錘的依據(jù)。
而順著這個思路往下, 我們可以看到是什么導(dǎo)致/dev/autofs文件消失的呢？因為聊天中我們有看到, 編寫內(nèi)核的時候, 那哥們將autofs4做了別名做成了autofs, 正好和/dev中的東西一樣, 而報錯中我們也確實能看到/dev/autofs的相關(guān)報錯是由autofs4的導(dǎo)入失敗而導(dǎo)致的。于是, 我將新硬盤掛載到一個目錄下, 在其上尋找autofs相關(guān)文件, 發(fā)現(xiàn)一個問題：新的系統(tǒng)中/lib/modules/3.16.0-4-amd64中有一個kernel目錄, 其下有一個fs/autofs4/autofs4.ko文件, 而老硬盤中整個kernel目錄不翼而飛……我想這大概就是為什么掛載不上吧……
于是我將新硬盤的/lib/modules/3.16.0-4-amd64/kernel目錄整個拷回老硬盤中,具體有沒有用, 說實話我不知道。因為這臺服務(wù)器上跑著業(yè)務(wù), 我不可能為了測試一下問題有沒有解決就去重啟著玩兒, 萬一沒解決起不來那場面還是算了吧……
6. 回到原點
在那之后, 我又查了一些資料, 并且man了一下dmesg命令, 發(fā)現(xiàn)可以使用-T選項去查看具體時間。于是就有了上面的兩張圖。
新的問題出現(xiàn)了, 我沒記錯的話, 那天我是搞到1點35左右睡的覺, 然后1點20左右服務(wù)器可能已經(jīng)起來了。如果是這樣的話, 那么后面的報錯并不是服務(wù)器啟動失敗的報錯, 而前面那個1:15的才是, 如果是這樣的話, 前面那么多東西方向都是錯的, 沒啥卵用, 而1:15的報錯非常簡潔：
"[Fri Dec 20 01:01:14 2019] Cannot get hvm parameter CONSOLE_EVTCHN (18): -22!"
如果有大佬知道這方面的報錯怎么處理的話歡迎聯(lián)系……最近準備考試實在沒精力再在這里折騰了……
