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

做爲一名合格的 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 查看版本

 

解決方法：一、

# rm [a-n]* -rf

# rm [o-z]* -rf

二、使用 find 命令來刪除

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

三、經過 shell 腳本

#/bin/bash

RM_DIR=’/var/spool/clientmqueue’

cd $RM_DIR

for I in `ls`

do

rm –f $i

done

四、從新編譯內核

須要手動增長內核中分配給命令行參數的頁數，打開 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 時，有如下幾種使用方法：

 

一、 在用戶環境變量中加入

若是用戶使用的是 bash，那麼能夠在用戶目錄的環境變量文件. bashrc 或者. bash_profile 中加入 「ulimit –u128」 來限制用戶最多可使用 128 個進程

二、 在應用程序的啓動腳本中加入

若是應用程序是 tomcat，那麼能夠再 tomcat 的啓動腳本 startup.sh 中加入‘ulimit -n 65535’來限制用戶最多可使用 65535 個文件描述符

三、 直接在 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運維的瞭解又加深了一層。做爲一名Linux愛好者，若是你在學習中遇到了困惑須要交流，能夠來咱們的網站（http://www.magedu.com/）獲取幫助，瞭解行業評價最高的Linux課程能夠撥打電話：18519746220。