歡迎光臨
每天分享高質量文章

6 個 Linux 運維典型問題,大牛的分析解決思路在這裡

來源:CU技術社群

ID:ChinaUnix2013

作為一名合格的 Linux 運維工程師,一定要有一套清晰、明確的解決故障思路,當問題出現時,才能迅速定位、解決問題,這裡給出一個處理問題的一般思路:


  • 重視報錯提示資訊:每個錯誤的出現,都是給出錯誤提示資訊,一般情況下這個提示基本定位了問題的所在,因此一定要重視這個報錯資訊,如果對這些錯誤資訊視而不見,問題永遠得不到解決。

  • 查閱日誌檔案:有時候報錯資訊只是給出了問題的錶面現象,要想更深入的瞭解問題,必須檢視相應的日誌檔案,而日誌檔案又分為系統日誌檔案(/var/log)和應用的日誌檔案,結合這兩個日誌檔案,一般就能定位問題所在。

  • 分析、定位問題:這個過程是比較複雜的,根據報錯資訊,結合日誌檔案,同時還要考慮其它相關情況,最終找到引起問題的原因。

  • 解決問題:找到了問題出現的原因,解決問題就是很簡單的事情了。

從這個流程可以看出,解決問題的過程就是分析、查詢問題的過程,一旦確定問題產生的原因,故障也就隨之解決了。

結合上面介紹的 Linux 運維問題的解決思路後,下麵我們挑選了6個比較典型的 Linux 運維問題,來看看是如何分析和解決的:


問題 1:檔案系統破壞導致系統無法啟動

Checking root filesystem

/dev/sda6 contains a file system with errors, check forced

An error occurred during the file system check


這個錯誤可以看出,作業系統 / dev/sda6 分割槽檔案系統出現了問題,這個問題發生的機率很高,通常引起這個問題的原因主要是系統突然斷電,引起檔案系統結構不一致,一般情況下,解決此問題的方法是採用 fsck 命令,進行強制修複。


# umount /dev/sda6

# fsck.ext3 -y /dev/sda6

問題 2:“Argument list too long” 錯誤與解決方法

# crontab -e

編輯完後儲存退出後,報錯 no space left on device

根據上面的報錯瞭解到是磁碟空間滿了,那麼首先是檢查磁碟空間,


# df -h

檢視到是 / var 磁碟分割槽空間已經達到 100%,至此定位了問題所在。是 / var 磁碟空間飽滿導致,因為 crontab 會在儲存時將檔案資訊寫到 / var 目錄下麵,然而這個磁碟沒有空間了,所以報錯。

接著透過命令 du –sh * 命令檢查 / var 目錄下麵的所有檔案或者目錄的大小,發現 / var/spool/clientmqueue 目錄佔用了 / var 整個分割槽大小的 90%,那麼 / var/spool/clientmqueue 目錄下的檔案都是怎麼產生的,能否刪除,基本上都是郵件資訊,可以刪除


# rm *

/bin/rm :argument list too long

當在 linux 系統中試圖傳遞太多引數給一個命令時,就會出現 “argument list too long” 錯誤,這是 linux 系統一直以來都有的限制,檢視這個限制可以透過命令 “getconf ARG_MAX” 來實現,


# getconf ARG_MAX

# more /etc/issue 檢視版本


解決方法:1、

# rm [a-n]* -rf

# rm [o-z]* -rf

2、使用 find 命令來刪除

# find /var/spool/clientmqueue –type f –print –exec rm –f {} \;

3、透過 shell 指令碼

#/bin/bash

RM_DIR=’/var/spool/clientmqueue’

cd $RM_DIR

for I in `ls`

do

rm –f $i

done

4、重新編譯核心

需要手動增加核心中分配給命令列引數的頁數,開啟 kernel source 下麵的 include/linux/binfmts.h 檔案,找到如下行:

#denfine MAX_ARG_PAGES 32

將 32 改為更大的值,例如 64 或者 128,然後重新編譯核心

問題 3:inode 耗盡導致應用故障


客戶的一臺 Oracle 資料庫如武器在關機重啟後,Oracle 監聽無法啟動,提示報錯 Linux error : No space left on device

從輸出資訊看出來是因為磁碟耗盡導致監聽無法啟動,因為 Oracle 在啟動監聽時需要建立監聽日誌檔案,於是首先檢視磁碟空間使用情況


# df -h

從磁碟輸出資訊可知,所有的分割槽磁碟空間都還有剩餘不少,而 Oracle 監聽寫日誌的路徑在 / var 分割槽下,/var 下分割槽空間足夠。


解決思路:

既然錯誤提示語磁碟空間有關,那就深入研究關於磁碟空間的問題,在 linux 系統中對磁碟空間的佔用分為三個部分:第一個是物理磁碟空間,第二個是 inode 節點所佔用的磁碟空間,第三個是 linux 用來存放訊號量的空間,而平時接觸較多的是物理磁碟空間。既然不是物理磁碟空間的問題,接著就檢查是否是 inode 節點耗盡的問題,透過執行命令 “df -i” 檢視可用的 inode 節點。由輸出結果看出確實是因為 inode 耗盡導致無法寫入檔案。


可以透過下麵的命令檢視某個磁碟分割槽 inode 的總數

# dumpe2fs -h /dev/sda3 |grep ‘Inode count’

每個 inode 都有一個號碼,作業系統用 inode 號碼來區分不同的檔案,透過‘ls -i’命令可以檢視檔案名對應的 inode 號


如果要檢視這個檔案更詳細的 inode 資訊,可以透過 stat 命令來實現

# stat install.log

解決問題

# find /var/spool/clientmqueue/ -name “*” -exec rm -rf {} \;

問題 4:檔案已經刪除,但是空間沒有釋放的原因


運維監控系統發來通知,報告一臺伺服器空間滿了,登陸伺服器檢視,根分割槽確實滿了,這裡先說一下伺服器的一些刪除策略,由於 linux 沒有回收站功能,所以線上伺服器上所有要刪除的檔案都會先移到系統 / tmp 目錄下,然後定期清除 / tmp 目錄下的資料。這個策略本身沒有什麼問題,但是透過檢查發現這臺伺服器的系統分割槽中並沒有單獨劃分 / tmp 分割槽,這樣 / tmp 下的資料其實佔用根分割槽的空間,既然找到了問題,那麼刪除 / tmp 目錄下一些佔用空間較大的資料檔案即可。


# du -sh /tmp/* | sort -nr |head -3

透過命令發現在 / tmp 目錄下有個 66G 大小的檔案 access_log,這個檔案應該是 apache 產生的訪問日誌檔案,從日誌大小來看,應該是很久沒有清理的 apache 日誌檔案了,基本判定是這個檔案導致的根空間爆滿,在確認此檔案可以刪除後,執行如下刪除命令,

# rm /tmp/access_Iog

# df -h


從輸出來看,根分割槽空間仍然沒有釋放,這是怎麼回事

一般來說不會出現刪除檔案後空間不釋放的情況,但是也存在例外,比如檔案行程鎖定,或者有行程一直在向這個檔案寫資料,要理解這個問題,就需要知道 linux 下檔案的儲存機制和儲存結構。


一個檔案在檔案系統中存放分為兩個部分:資料部分和指標部分,指標位於檔案系統的 meta-data 中,在將資料刪除後,這個指標就從 meta-data 中清除了,而資料部分儲存在磁碟中。在將資料對應的指標從 meta-data 中清除後,檔案資料部分佔用的空間就可以被改寫並寫入新的內容,之所以出現刪除 access_log 檔案後,空間還沒有釋放,就是因為 httpd 行程還在一直向這個檔案寫入內容,導致雖然刪除了 access_Ilog 檔案,但是由於行程鎖定,檔案對應的指標部分並未從 meta-data 中清除,而由於指標並未刪除,系統核心就認為檔案並未被刪除,因此透過 df 命令查詢空間並未釋放。


問題排查:

既然有瞭解決思路,那麼接下來看看是否有行程一直在向 access_log 檔案中寫入資料,這裡需要用到 linux 下的 losf 命令,透過這個命令可以獲取一個仍然被應用程式佔用的已刪除檔案串列


# lsof | grep delete

從輸出可以看出,/tmp/access_log 檔案被行程 httpd 鎖定,而 httpd 行程還一直向這個檔案寫入日誌資料,最後一列的‘deleted’狀態說明這個日誌檔案已經被刪除,但是由於行程還在一直向此檔案寫入資料,因此空間並未釋放。


解決問題:

到這裡問題就基本排查清楚了,解決這一類問題的方法有很多,最簡單的方法就是關閉或者重啟 httpd 行程,當然重啟作業系統也可以。不過這些並不是最好的辦法,對待這種行程不停對檔案寫日誌的操作,要釋放檔案佔用的磁碟空間,最好的方法是線上清空這個檔案,具體可以透過如下命令完成:

# echo “”>/tmp/access_log


透過這種方法,磁碟空間不但可以馬上釋放,也可以保障進城繼續向檔案寫入日誌,這種方法經常用於線上清理 apache /tomcat/nginx 等 web 服務產生的日誌檔案。

問題 5:”too many open files” 錯誤與解決方法

問題現象:這是一個基於 java 的 web 應用系統,在後臺新增資料時提示無法新增,於是登陸伺服器檢視 tomcat 日誌,發現如下異常資訊,java.io.IOException: Too many open files


透過這個報錯資訊,基本判斷是系統可以用的檔案描述符不夠了,由於 tomcat 服務室系統 www 使用者啟動的,於是以 www 使用者登陸系統,透過 ulimit –n 命令檢視系統可以開啟最大檔案描述符的數量,輸出如下:

$ ulimit -n

65535


可以看到這臺伺服器設定的最大可以開啟的檔案描述符已經是 65535 了,這麼大的值應該夠用了,但是為什麼提示這樣的錯誤呢

解決思路,這個案例涉及 ulimit 命令的使用


在使用 ulimit 時,有以下幾種使用方法:

1、 在使用者環境變數中加入

如果使用者使用的是 bash,那麼可以在使用者目錄的環境變數檔案. bashrc 或者. bash_profile 中加入 “ulimit –u128” 來限制使用者最多可以使用 128 個行程

2、 在應用程式的啟動指令碼中加入

如果應用程式是 tomcat,那麼可以再 tomcat 的啟動指令碼 startup.sh 中加入‘ulimit -n 65535’來限制使用者最多可以使用 65535 個檔案描述符

3、 直接在 shell 命令終端執行 ulimit 命令

這種方法的資源限制僅僅在執行命令的終端生效,在退出或者和關閉終端後,設定失效,並且這個設定不影響其他 shell 終端

解決問題:


在瞭解 ulimit 知識後,接著上面的案例,既然 ulimit 設定沒有問題,那麼一定是設定沒有生效導致的,接下來檢查下啟動 tomcat 的 www 使用者環境變數是否新增 ulimit 限制,檢查後發現,www 使用者並無 ulimit 限制。於是繼續檢查 tomcat 啟動指令碼 startup.sh 檔案是否添加了 ulimit 限制,檢查後發現也沒有新增。最後考略是否將限制加到了 limits.conf 檔案中,於是檢查 limits.conf 檔案,操作如下

# cat /etc/security/limits.conf | grep www

www soft nofile 65535

www hard nofile 65535


從輸出可知,ulimit 限制加在 limits.conf 檔案中,既然限制已經添加了,配置也沒有什麼錯,為何還會報錯,經過思考,判斷只有一種可能,那就是 tomcat 的啟動時間早於 ulimit 資源限制的新增時間,於是首先檢視下 tomcat 啟動時間,操作如下

# uptime

Up 283 days

# pgrep -f tomcat

4667

# ps -eo pid,lstart,etime|grep 4667

4667 Sat Jul 6 09;33:39 2013 77-05:26:02


從輸出可以看出,這臺伺服器已經有 283 沒有重啟了,而 tomcat 是在 2013 年 7 月 6 日 9 點啟動的,啟動了將近 77 天,接著繼續看看 limits.conf 檔案的修改時間,

# stat /etc/security/limits.conf


透過 stat 命令清除的看到,limits.conf 檔案最後的修改時間是 2013 年 7 月 12,晚於 tomcat 啟動時間,清楚問題後,解決問題的方法很簡單,重啟一下 tomcat 就可以了。

問題 6:Read-only file system 錯誤與解決方法

解析:出現這個問題的原因有很多種,可能是檔案系統資料塊出現不一致導致的,也可能是磁碟故障造成的,主流 ext3/ext4 檔案系統都有很強的自我修複機制,對於簡單的錯誤,檔案系統一般都可以自行修複,當遇到致命錯誤無法修複的時候,檔案系統為了保證資料一致性和安全,會暫時遮蔽檔案系統的寫操作,講檔案系統 變為只讀,今兒出現了上面的 “read-only file system” 現象。


手工修複檔案系統錯誤的命令式 fsck,在修複檔案系統前,最好解除安裝檔案系統所在的磁碟分割槽


# umount /www/data

Umount : /www/data: device is busy


提示無法解除安裝,可能是這個磁碟中還有檔案對應的行程在執行,檢查如下:


# fuser -m /dev/sdb1

/dev/sdb1: 8800


接著檢查一下 8800 埠對應的什麼行程,


# ps -ef |grep 8800


檢查後發現時 apache 沒有關閉,停止 apache


# /usr/local/apache2/bin/apachectl stop

# umount /www/data

# fsck -V -a /dev/sdb1

# mount /dev/sdb1 /www/data

《Linux雲端計算及運維架構師高薪實戰班》2018年05月14日即將開課中,120天衝擊Linux運維年薪30萬,改變速約~~~~

    *宣告:推送內容及圖片來源於網路,部分內容會有所改動,版權歸原作者所有,如來源資訊有誤或侵犯權益,請聯絡我們刪除或授權事宜。

    – END –


    更多Linux好文請點選【閱讀原文】

    ↓↓↓

    贊(0)

    分享創造快樂