與windows系統一樣，linux操作系統也會存在很多問題和故障，很多linux新手都害怕故障，面對出現的問題顯得無可奈何，更有甚者，由此放棄了linux，其實，我們不應該懼怕問題，學習就是一個發現問題與解決問題的過程，只要掌握了解決問題的基本思路，一切故障都會迎刃而解，當然前提是我們已經具備了解決問題的思路和扎實的知識功底。

作為一名合格的linux系統管理員，一定要有一套清晰、明確的解決故障思路，當問題出現時，才能迅速定位、解決問題，這里給出一個處理問題的一般思路：

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

——查閱日志文件：有時候報錯信息只是給出了問題的表面現象，要想更深入的了解問題，必須查看相應的日志文件，而日志文件又分為系統日志文件(/var/log)和應用的日志文件，結合這兩個日志文件，一般就能定位問題所在。

——分析、定位問題：這個過程是比較復雜的，根據報錯信息，結合日志文件，同時還要考慮其它相關情況，最終找到引起問題的原因。

——解決問題：找到了問題出現的原因，解決問題就是很簡單的事情了。

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

下面我們來看看這些問題的解法和做法：

問題1：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 

問題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：(Apache常見錯誤故障案例)”no space left on device “錯誤與解決方法

錯誤現象： 客戶反映在執行”apachectl start “啟動Apache是無報錯信息，但是還是不能訪問網頁，客戶的網站是基于Apache+PHP+mysql 的在線交易平臺，聽到客戶描述的現象后，第一反應就是防火墻屏蔽了HTTP端口或selinux的問題，于是登陸服務器查看相關信息，從輸出信息可以看出，防火墻所有的策略都處于開放狀態，并未做出任何限制，而selinux也處于關閉狀態，應該不是防火墻導致的。既然不是防火墻導致的，那么看看httpd進程是否存在及httpd端口是否正常啟動

# ps –ef |grep httpd|grep –v “grep” |wc –l 
 
0 
 
# netstat –nultp |grep 80 
 
# /usr/local/apache2/bin/apachectl start 
 
# ps –ef |grpe httpd |grep –v “grep” |wc –l 
 
0 

這個操作首先查看了服務器上的httpd進程，發現并沒有HTTP進程運行，同時httpd對應的端口80也并沒有啟動，于是重啟Apache，在啟動Apache的過程中并沒有報錯，啟動完成后發現仍然HTTP進程沒有運行，由此看來，應該是Apache內部出現了問題

解決思路：

在判斷Apache問題后，首先要看的就是Apache的啟動日志，在查看Apache的error日志后，發現了一個可疑輸出，內容為：

No space left on device : mod_rewrite: could not create rewrite_log_lock configuration failed 

看到這個錯誤提示，感覺應該是磁盤空間耗盡導致，于是趕緊查看系統系統所有磁盤分區，結果發現所有磁盤分區都還有很多可用空間，這就奇怪了，在前面的案例介紹中，詳細介紹了linux對磁盤空間的占用分為三個部分:物理磁盤、inode節點磁盤空間和信號量磁盤空間。通過檢查服務器的物理磁盤空間，發現仍有很多剩余，因此排除物理空間的問題，接著通過”df -i”命令查看系統可用的inode節點，發現每個分區可以用的inode還有很多，這樣inode節點問題也被排除了，那么應該是信號量磁盤空間耗盡導致的。

這里簡單的介紹下linux信號量相關知識。信號量是一種鎖機制，用于協調進程之間互斥的訪問臨界資源，以確保某種共享資源不被多個進程同時訪問。Linux系統的信號量是用于進程間通信的。它有兩種標準實現，分別是POSIX及System v ，現在大多數linux系統都實現了這兩種標準，這兩種標準都可用于進行線程間的通信，只是系統調用方式略有不同。

System v 信號量通過系統調用semget來創建，通過linux命令ipcs即可顯示進程間通信用的system v 類型信號量及共享內存。

Posix 信號量可用于線程和進程間通信，并可分為有名和無名兩種，也可以理解為是否保存在磁盤上。

解決問題：

# cat /proc/sys/kernel/sem 
 
# ipcs –s |grep daemon 

Daemon是啟動Apache進程的用戶，默認是daemon，也可能是nobody用戶，根據實際環境而定。解決信號量耗盡的方法很簡單，通過ipcrm命令清除即可，最簡單方法是執行如下命令組合：

# ipcs –s |grep nobody |perl –e ‘while (<STDIN>) { @a=split(/\s+/);print `ipcrmsem $a[1]` }’ 

問題7：linux系統無法啟動的解決方法

這是linux最常見的故障，系統在掉電，以及執行配置更新、軟件升級、內核升級后都有可能導致系統無法啟動，究其原因，可能有很多種，常見的如下幾種：

1) 文件系統破壞，一般是linux的根分區文件系統遭到破壞，導致系統無法啟動，這種情況一般是有系統突然掉電或者非法關機引起的。

2) 文件系統配置不當，比如/etc/inittab文件、/etc/fstab文件等配置錯誤或丟失，導致系統錯誤，無法啟動，這種情況一般是執行配置更新時人為導致的

3) Linux內核文件丟失或者崩潰，從而導致系統無法引導啟動，這種情況可能是內核升級錯誤或者內核存在bug引起的

4) 系統引導程序出現問題，比如grub丟失或者損壞，導致系統無法引導啟動，這種情況一般是人為修改錯誤或者文件系統故障導致的。

5) 系統硬件故障，比如主板、電源、硬盤等出現問題，導致linux系統無法正常啟動，這種情況基本都是由于服務器硬件問題導致的。

問題8：文件系統破壞導致系統無法啟動

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 

問題9：訪問權限問題

當某些服務不能訪問的時候，一定要檢查是否被linux本機防火墻iptables屏蔽了，可以通過iptables –L –n 命令檢查iptables的配置策略。

# iptables –L –n 
 
# iptables –A INPUT –i eth0 –p tcp --dport 80 –j ACCEPT 
 
# iptables –A OUTPUT –p tcp --sport 80 –m state –state ESTABLISHED –j ACCEPT