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

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

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

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

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

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

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

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

問題1：Read-only file system 錯誤與解決方法

解析：出現(xiàn)這個問題的原因有很多種，可能是文件系統(tǒng)數(shù)據(jù)塊出現(xiàn)不一致導致的，也可能是磁盤故障造成的，主流ext3/ext4文件系統(tǒng)都有很強的自我修復機制，對于簡單的錯誤，文件系統(tǒng)一般都可以自行修復，當遇到致命錯誤無法修復的時候，文件系統(tǒng)為了保證數(shù)據(jù)一致性和安全，會暫時屏蔽文件系統(tǒng)的寫操作，講文件系統(tǒng) 變?yōu)橹蛔x，今兒出現(xiàn)了上面的“read-only file system”現(xiàn)象。

手工修復文件系統(tǒng)錯誤的命令式fsck，在修復文件系統(tǒng)前，最好卸載文件系統(tǒng)所在的磁盤分區(qū)

# umount /www/data 
 
Umount : /www/data: device is busy 

提示無法卸載，可能是這個磁盤中還有文件對應的進程在運行，檢查如下：

# fuser –m /dev/sdb1 
 
/dev/sdb1: 8800 

接著檢查一下8800端口對應的什么進程，

# ps –ef |grep 8800 

檢查后發(fā)現(xiàn)時apache沒有關(guān)閉，停止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

根據(jù)上面的報錯了解到是磁盤空間滿了，那么首先是檢查磁盤空間，

# df –h 

查看到是/var磁盤分區(qū)空間已經(jīng)達到100%，至此定位了問題所在。是/var磁盤空間飽滿導致，因為crontab會在保存時將文件信息寫到/var目錄下面，然而這個磁盤沒有空間了，所以報錯。

接著通過命令du –sh * 命令檢查/var目錄下面的所有文件或者目錄的大小，發(fā)現(xiàn)/var/spool/clientmqueue目錄占用了/var整個分區(qū)大小的90%，那么/var/spool/clientmqueue目錄下的文件都是怎么產(chǎn)生的，能否刪除，基本上都是郵件信息，可以刪除

# rm * 
 
/bin/rm :argument list too long 

當在linux 系統(tǒng)中試圖傳遞太多參數(shù)給一個命令時，就會出現(xiàn)“argument list too long ”錯誤，這是linux系統(tǒng)一直以來都有的限制，查看這個限制可以通過命令“getconf ARG_MAX”來實現(xiàn)，

# 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、重新編譯內(nèi)核

需要手動增加內(nèi)核中分配給命令行參數(shù)的頁數(shù)，打開kernel source 下面的include/linux/binfmts.h文件，找到如下行：

#denfine MAX_ARG_PAGES 32 

將32改為更大的值，例如64或者128，然后重新編譯內(nèi)核

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

客戶的一臺Oracle數(shù)據(jù)庫如武器在關(guān)機重啟后，Oracle監(jiān)聽無法啟動，提示報錯 Linux error : No space left on device

從輸出信息看出來是因為磁盤耗盡導致監(jiān)聽無法啟動，因為Oracle在啟動監(jiān)聽時需要創(chuàng)建監(jiān)聽日志文件，于是首先查看磁盤空間使用情況

# df –h 

從磁盤輸出信息可知，所有的分區(qū)磁盤空間都還有剩余不少，而Oracle監(jiān)聽寫日志的路徑在/var分區(qū)下，/var下分區(qū)空間足夠。

解決思路：

既然錯誤提示語磁盤空間有關(guān)，那就深入研究關(guān)于磁盤空間的問題，在linux系統(tǒng)中對磁盤空間的占用分為三個部分：第一個是物理磁盤空間，第二個是inode節(jié)點所占用的磁盤空間，第三個是linux用來存放信號量的空間，而平時接觸較多的是物理磁盤空間。既然不是物理磁盤空間的問題，接著就檢查是否是inode節(jié)點耗盡的問題，通過執(zhí)行命令“df -i”查看可用的inode節(jié)點。由輸出結(jié)果看出確實是因為inode耗盡導致無法寫入文件。

可以通過下面的命令查看某個磁盤分區(qū)inode的總數(shù)

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

每個inode都有一個號碼，操作系統(tǒng)用inode號碼來區(qū)分不同的文件，通過‘ls -i’命令可以查看文件名對應的inode號

如果要查看這個文件更詳細的inode信息，可以通過stat命令來實現(xiàn)

# stat install.log 

解決問題

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

問題4：文件已經(jīng)刪除，但是空間沒有釋放的原因

運維監(jiān)控系統(tǒng)發(fā)來通知，報告一臺服務器空間滿了，登陸服務器查看，根分區(qū)確實滿了，這里先說一下服務器的一些刪除策略，由于linux沒有回收站功能，所以線上服務器上所有要刪除的文件都會先移到系統(tǒng)/tmp目錄下，然后定期清除/tmp目錄下的數(shù)據(jù)。這個策略本身沒有什么問題，但是通過檢查發(fā)現(xiàn)這臺服務器的系統(tǒng)分區(qū)中并沒有單獨劃分/tmp分區(qū)，這樣/tmp下的數(shù)據(jù)其實占用根分區(qū)的空間，既然找到了問題，那么刪除/tmp目錄下一些占用空間較大的數(shù)據(jù)文件即可。

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

通過命令發(fā)現(xiàn)在/tmp目錄下有個66G大小的文件access_log，這個文件應該是apache產(chǎn)生的訪問日志文件，從日志大小來看，應該是很久沒有清理的apache日志文件了，基本判定是這個文件導致的根空間爆滿，在確認此文件可以刪除后，執(zhí)行如下刪除命令，

# rm /tmp/access_Iog 
 
# df –h 

從輸出來看，根分區(qū)空間仍然沒有釋放，這是怎么回事

一般來說不會出現(xiàn)刪除文件后空間不釋放的情況，但是也存在例外，比如文件進程鎖定，或者有進程一直在向這個文件寫數(shù)據(jù)，要理解這個問題，就需要知道linux下文件的存儲機制和存儲結(jié)構(gòu)。

一個文件在文件系統(tǒng)中存放分為兩個部分：數(shù)據(jù)部分和指針部分，指針位于文件系統(tǒng)的meta-data中，在將數(shù)據(jù)刪除后，這個指針就從meta-data中清除了，而數(shù)據(jù)部分存儲在磁盤中。在將數(shù)據(jù)對應的指針從meta-data中清除后，文件數(shù)據(jù)部分占用的空間就可以被覆蓋并寫入新的內(nèi)容，之所以出現(xiàn)刪除access_log文件后，空間還沒有釋放，就是因為httpd進程還在一直向這個文件寫入內(nèi)容，導致雖然刪除了access_Ilog文件，但是由于進程鎖定，文件對應的指針部分并未從meta-data中清除，而由于指針并未刪除，系統(tǒng)內(nèi)核就認為文件并未被刪除，因此通過df命令查詢空間并未釋放。

問題排查：

既然有了解決思路，那么接下來看看是否有進程一直在向access_log文件中寫入數(shù)據(jù)，這里需要用到linux下的losf命令，通過這個命令可以獲取一個仍然被應用程序占用的已刪除文件列表

# lsof |grep delete 

從輸出可以看出，/tmp/access_log文件被進程httpd鎖定，而httpd進程還一直向這個文件寫入日志數(shù)據(jù)，最后一列的‘deleted’狀態(tài)說明這個日志文件已經(jīng)被刪除，但是由于進程還在一直向此文件寫入數(shù)據(jù)，因此空間并未釋放。

解決問題：

到這里問題就基本排查清楚了，解決這一類問題的方法有很多，最簡單的方法就是關(guān)閉或者重啟httpd進程，當然重啟操作系統(tǒng)也可以。不過這些并不是最好的辦法，對待這種進程不停對文件寫日志的操作，要釋放文件占用的磁盤空間，最好的方法是在線清空這個文件，具體可以通過如下命令完成:

# echo “ ” >/tmp/access_log 

通過這種方法，磁盤空間不但可以馬上釋放，也可以保障進城繼續(xù)向文件寫入日志，這種方法經(jīng)常用于在線清理apache /tomcat/nginx等web服務產(chǎn)生的日志文件。

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

問題現(xiàn)象：這是一個基于java的web應用系統(tǒng)，在后臺添加數(shù)據(jù)時提示無法添加，于是登陸服務器查看tomcat日志，發(fā)現(xiàn)如下異常信息，java.io.IOException: Too many open files

通過這個報錯信息，基本判斷是系統(tǒng)可以用的文件描述符不夠了，由于tomcat服務室系統(tǒng)www用戶啟動的，于是以www用戶登陸系統(tǒng)，通過ulimit –n 命令查看系統(tǒng)可以打開最大文件描述符的數(shù)量，輸出如下：

$ ulimit –n 
 
65535 

可以看到這臺服務器設(shè)置的最大可以打開的文件描述符已經(jīng)是65535了，這么大的值應該夠用了，但是為什么提示這樣的錯誤呢

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

在使用ulimit時，有以下幾種使用方法：

1、 在用戶環(huán)境變量中加入

如果用戶使用的是bash，那么可以在用戶目錄的環(huán)境變量文件.bashrc或者.bash_profile中加入“ulimit –u128”來限制用戶最多可以使用128個進程

2、 在應用程序的啟動腳本中加入

如果應用程序是tomcat，那么可以再tomcat的啟動腳本startup.sh中加入‘ulimit –n 65535’來限制用戶最多可以使用65535個文件描述符

3、 直接在shell命令終端執(zhí)行ulimit命令

這種方法的資源限制僅僅在執(zhí)行命令的終端生效，在退出或者和關(guān)閉終端后，設(shè)置失效，并且這個設(shè)置不影響其他shell終端

解決問題：

在了解ulimit知識后，接著上面的案例，既然ulimit設(shè)置沒有問題，那么一定是設(shè)置沒有生效導致的，接下來檢查下啟動tomcat的www用戶環(huán)境變量是否添加ulimit限制，檢查后發(fā)現(xiàn)，www用戶并無ulimit限制。于是繼續(xù)檢查tomcat啟動腳本startup.sh文件是否添加了ulimit限制，檢查后發(fā)現(xiàn)也沒有添加。最后考略是否將限制加到了limits.conf文件中，于是檢查limits.conf文件，操作如下

# cat /etc/security/limits.conf |grep www 
 
www soft nofile 65535 
 
www hard nofile 65535 

從輸出可知，ulimit限制加在limits.conf文件中，既然限制已經(jīng)添加了，配置也沒有什么錯，為何還會報錯，經(jīng)過思考，判斷只有一種可能，那就是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 

從輸出可以看出，這臺服務器已經(jīng)有283沒有重啟了，而tomcat是在2013年7月6日9點啟動的，啟動了將近77天，接著繼續(xù)看看limits.conf文件的修改時間，

# stat /etc/security/limits.conf 

通過stat命令清除的看到，limits.conf文件最后的修改時間是2013年7月12，晚于tomcat啟動時間，清楚問題后，解決問題的方法很簡單，重啟一下tomcat就可以了。

問題6：(Apache常見錯誤故障案例)”no space left on device “錯誤與解決方法

錯誤現(xiàn)象： 客戶反映在執(zhí)行”apachectl start “啟動Apache是無報錯信息，但是還是不能訪問網(wǎng)頁，客戶的網(wǎng)站是基于Apache+PHP+mysql 的在線交易平臺，聽到客戶描述的現(xiàn)象后，第一反應就是防火墻屏蔽了HTTP端口或selinux的問題，于是登陸服務器查看相關(guān)信息，從輸出信息可以看出，防火墻所有的策略都處于開放狀態(tài)，并未做出任何限制，而selinux也處于關(guān)閉狀態(tài)，應該不是防火墻導致的。既然不是防火墻導致的，那么看看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進程，發(fā)現(xiàn)并沒有HTTP進程運行，同時httpd對應的端口80也并沒有啟動，于是重啟Apache，在啟動Apache的過程中并沒有報錯，啟動完成后發(fā)現(xiàn)仍然HTTP進程沒有運行，由此看來，應該是Apache內(nèi)部出現(xiàn)了問題

解決思路：

在判斷Apache問題后，首先要看的就是Apache的啟動日志，在查看Apache的error日志后，發(fā)現(xiàn)了一個可疑輸出，內(nèi)容為：

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

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

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

System v 信號量通過系統(tǒng)調(diào)用semget來創(chuàng)建，通過linux命令ipcs即可顯示進程間通信用的system v 類型信號量及共享內(nèi)存。

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

解決問題：

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

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

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

問題7：linux系統(tǒng)無法啟動的解決方法

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

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

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

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

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

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

問題8：文件系統(tǒng)破壞導致系統(tǒng)無法啟動

Checking root filesystem 
 
/dev/sda6 contains a file system with errors, check forced 
 
An error occurred during the file system check 

這個錯誤可以看出，操作系統(tǒng)/dev/sda6分區(qū)文件系統(tǒng)出現(xiàn)了問題，這個問題發(fā)生的機率很高，通常引起這個問題的原因主要是系統(tǒng)突然斷電，引起文件系統(tǒng)結(jié)構(gòu)不一致，一般情況下，解決此問題的方法是采用fsck命令，進行強制修復。

# umount /dev/sda6 
 
# fsck.ext3 –y /dev/sda6 

問題9：訪問權(quán)限問題

當某些服務不能訪問的時候，一定要檢查是否被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