出了Linux故障找不到方法？看大牛簡單、樸實的解決思路
與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
