作為一名合格的 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 在啟動監聽時需要建立監聽日志檔案，于是首先檢視磁盤空間使用情況
從磁盤輸出資訊可知，所有的分區磁盤空間都還有剩餘不少，而 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
從輸出來看，根分區空間仍然沒有釋放，這是怎麼回事
一般來說不會出現删除檔案後空間不釋放的情況，但是也存在例外，比如檔案程序鎖定，或者有程序一直在向這個檔案寫資料，要了解這個問題，就需要知道 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
賣二手QQ平台設定沒有問題，那麼一定是設定沒有生效導緻的，接下來檢查下啟動 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
# fsck -V -a /dev/sdb1
# mount /dev/sdb1 /www/data
看完以上的内容，相信你對于Linux運維的了解又加深了一層。作為一名Linux愛好者，如果你在學習中遇到了困惑需要交流，可以來我們的網站（
http://www.magedu.com/）擷取幫助，擷取更多技術知識點+v156 5219 9186，歡豆線上解答哦~
![Windows下配置Apache的SSL服務[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)