作為linux運維，多多少少會碰見這樣那樣的問題或故障，從中總結經驗，查詢問題，彙總並分析故障的原因，這是一個Linux運維工程師良好的習慣。每一次技術的突破，都經歷著苦悶，伴隨著快樂，可我們還是執著的繼續努力，從中也積累了更多的經驗，這就是實踐給予我們的豐厚回報。

下面彙總了我做專案過程可能出現的故障及解決方法，看看是否與你有共鳴，並對你有幫助？

第一：常見問題解決集錦

1.shell指令碼不執行

問題：某天研發某同事找我說幫他看看他寫的shell指令碼，死活不執行，報錯。我看了下，指令碼很簡單，也沒有常規性的錯誤，報“:badinterpreter:Nosuchfileordirectory”錯。

看這錯，我就問他是不是在windows下編寫的指令碼，然後在上傳到linux伺服器的……果然。

原因：在DOS/windows裡，文字檔案的換行符為rn，而在*nix系統裡則為n，所以DOS/Windows裡編輯過的文字檔案到了*nix裡，每一行都多了個^M。

解決：

1）重新在linux下編寫指令碼；

2）vi:%s/r//g:%s/^M//g（^M輸入用Ctrl+v,Ctrl+m）

附：sh-x指令碼檔名，可以單步執行並回顯結果，有助於排查複雜指令碼問題。

2.crontab輸出結果控制

問題：

/var/spool/clientmqueue目錄佔用空間超過100G

原因：

cron中執行的程式有輸出內容，輸出內容會以郵件形式發給cron的使用者，而sendmail沒有啟動所以就產生了/var/spool/clientmqueue目錄下的那些檔案，日積月累可能撐破磁碟。

解決：

1）直接手動刪除：ls|xargsrm-f；

2）徹底解決：在cron的自動執行語句後加上>/dev/null2>&1

3.telnet很慢/ssh很慢

問題：

某天研發某同事說10.50訪問10.52memcached服務異常，讓我們檢查下看網路/服務/系統是否有異常。檢查發現系統正常，服務正常，10.50ping10.52也正常，但10.50telnet10.52很慢。同時發現該機器的namesever是不起作用的。

原因：

becauseyourPCdoesn’tdoareverseDNSlookuponyourIPthen…whenyoutelnet/ftpintoyourlinuxbox,it’lldoadnslookuponyou。

解決：

1)修改/etc/hosts使hostname和ip對應；

2）在/etc/resolv.conf註釋掉nameserver或者找一個“活的”nameserver。

4.Read-onlyfilesystem

問題：

同事在mysql裡建表建不成功，提示如下：

mysql>createtablewosontest(colddname1char(1));  
ERROR1005(HY000):Can’tcreatetable‘wosontest’(errno:30） 

經檢查mysql使用者許可權以及相關目錄許可權沒問題；用perror30提示資訊為：OSerrorcode30:Read-onlyfilesystem

可能原因：

1）檔案系統損壞；

2）磁碟又壞道；

3）fstab檔案配置錯誤，如分割槽格式錯誤錯誤(將ntfs寫成了fat)、配置指令拼寫錯誤等。

解決：

1）由於是測試機，重啟機器後恢復；

2）網上說用mount可解決。

5.檔案刪了磁碟空間沒釋放

問題：

某天發現某臺機器df-h已用磁碟空間為90G，而du-sh/*顯示所有使用空間加起來才30G，囧。

原因：

可能某人直接用rm刪除某個正在寫的檔案，導致檔案刪了但磁碟空間沒釋放的問題

解決：

1）最簡單重啟系統或者重啟相關服務。

2）幹掉程序

/usr/sbin/lsof|grepdeleted  
ora25575data33uREG65,654294983680/oradata/DATAPRE/UNDOTBS009.dbf(deleted) 

從lsof的輸出中，我們可以發現pid為25575的程序持有著以檔案描述號（fd）為33開啟的檔案/oradata/DATAPRE/UNDOTBS009.dbf。在我們找到了這個檔案之後可以通過結束程序的方式來釋放被佔用的空間：echo>/proc/25575/fd/33

3）刪除正在寫的檔案一般用cat/dev/null>file

6.find檔案提升效能

問題：

在tmp目錄下有大量包含picture_*的臨時檔案，每天晚上2:30對一天前的檔案進行清理。之前在crontab下跑如下指令碼，但是發現指令碼效率很低，每次執行時負載猛漲，影響到其他服務。

#!/bin/sh 
find/tmp-name“picture_*”-mtime+1-execrm-f{}; 

原因：

目錄下有大量檔案，用find很耗資源。

解決：

#!/bin/sh  
cd/tmp 
time=`date-d“2dayago”“+%b%d”`  
ls-l|grep“picture”|grep“$time”|awk‘{print$NF}’|xargsrm-rf 

7.獲取不了閘道器mac地址

問題：

從2.14到3.65（對映地址2.141）網路不通，但是從3端的其他機器到3.65網路OK。

原因：

#arp  
AddressHWtypeHWaddressFlagsMaskIface  
192.168.3.254etherincompletCMbond0 

表面現象是機器自動獲取不了閘道器MAC地址，網路工程師說是網路裝置的問題，具體不清。

解決：

arp繫結，arp-ibond0-s192.168.3.25400:00:5e:00:01:64

8.http服務無法啟動一例

問題：某天研發某同事說網站前端環境http無法啟動，我上去看了下。報如下錯：

/etc/init.d/httpdstart  
Startinghttpd:[SatJan2917:49:002011][warn]moduleantibot_moduleisalreadyloaded,skipping  
Useproxyforwardasremoteip:true.  
Antibotexcludepattern:.*.[(js|css|jpg|gif|png)]  
Antibotseedcheckpattern:login  
(98)Addressalreadyinuse:make_sock:couldnotbindtoaddress[::]:7080  
(98)Addressalreadyinuse:make_sock:couldnotbindtoaddress0.0.0.0:7080  
nolisteningsocketsavailable,shuttingdown  
Unabletoopenlog[FAILED] 

原因：

1）埠被佔用：表面看是7080埠被佔用，於是netstat-npl|grep7080看了下發現7080沒有佔用；

2）在配置檔案中重複寫了埠，如果在以下兩個檔案同時寫了Listen7080

/etc/httpd/conf/http.conf  
/etc/httpd/conf.d/t.10086.cn.conf 

解決：

註釋掉/etc/httpd/conf.d/t.10086.cn.conf的Listen7080，重啟，OK。

9.toomanyopenfile

問題：

報toomanyopenfile錯誤

解決：

終極解決方案

echo“”>>/etc/security/limits.conf  
echo“*softnproc65535″>>/etc/security/limits.conf  
echo“*hardnproc65535″>>/etc/security/limits.conf  
echo“*softnofile65535″>>/etc/security/limits.conf  
echo“*hardnofile65535″>>/etc/security/limits.conf  
echo“”>>/root/.bash_profile  
echo“ulimit-n65535″>>/root/.bash_profile  
echo“ulimit-u65535″>>/root/.bash_profile 

最後重啟機器或者執行ulimit-u655345&&ulimit-n65535

10.ibdata1和mysql-bin致磁碟空間問題

問題：

2.51磁碟空間報警，經查發現ibdata1和mysql-bin日誌佔用空間太多（其中ibdata1超過120G，mysql-bin超過80G）

原因：

ibdata1是儲存格式，在INNODB型別資料狀態下，ibdata1用來儲存檔案的資料和索引，而庫名的資料夾裡的那些表文件只是結構而已。

innodb儲存引擎有兩種表空間的管理方式，分別是：

1）共享表空間（可拆分為多個小的表空間檔案），這個是我們目前多數資料庫使用的方法；

2）獨立表空間，每一個表有一個獨立的表空間（磁碟檔案）

對於兩種管理方式，各有優劣，具體如下：

①共享表空間：

優點：可以將表空間分成多個檔案存放到不同的磁碟上（表空間檔案大小不受表大小的限制，一個表可以分佈在不同步的檔案上）

缺點：所有資料和索引存放在一個檔案中，則隨著資料的增加，將會有一個很大的檔案，雖然可以把一個大檔案分成多個小檔案，但是多個表及索引在表空間中混合儲存，這樣如果對於一個表做了大量刪除操作後表空間中將有大量空隙。對於共享表空間管理的方式下，一旦表空間被分配，就不能再回縮了。當出現臨時建索引或是建立一個臨時表的操作表空間擴大後，就是刪除相關的表也沒辦法回縮那部分空間了。

②獨立表空間：在配置檔案（my.cnf）中設定：innodb_file_per_table

特點：每個表都有自已獨立的表空間；每個表的資料和索引都會存在自已的表空間中。

優點：表空間對應的磁碟空間可以被收回（Droptable操作自動回收表空間，如果對於刪除大量資料後的表可以通過:altertabletbl_nameengine=innodb;回縮不用的空間。

缺點：如果單表增加過大，如超過100G，效能也會受到影響。在這種情況下，如果使用共享表空間可以把檔案分開，但有同樣有一個問題，如果訪問的範圍過大同樣會訪問多個檔案，一樣會比較慢。如果使用獨立表空間，可以考慮使用分割槽表的方法，在一定程度上緩解問題。此外，當啟用獨立表空間模式時，需要合理調整innodb_open_files引數的設定。

解決:

1）ibdata1資料太大：只能通過dump，匯出建庫的sql語句，再重建的方法。

2）mysql-binLog太大：

①手動刪除：

刪除某個日誌：mysql>PURGEMASTERLOGSTO‘mysql-bin.010′;

刪除某天前的日誌：mysql>PURGEMASTERLOGSBEFORE’2010-12-2213:00:00′;

②在/etc/my.cnf裡設定只儲存N天的bin-log日誌

expire_logs_days=30//BinaryLog自動刪除的天數

二、故障排查彙總表