共計 4799 個字符，預計需要花費 12 分鐘才能閱讀完成。
今天就跟大家聊聊有關 Linux 運維常見故障及處理的方法是什么，可能很多人都不太了解，為了讓大家更加了解，丸趣 TV 小編給大家總結了以下內容，希望大家根據這篇文章可以有所收獲。
作為 Linux 運維，多多少少會碰見這樣那樣的問題或故障，從中總結經驗，查找問題，匯總并分析故障的原因，這是一個 Linux 運維工程師良好的習慣。每一次技術的突破，都經歷著苦悶，伴隨著快樂，可我們還是執著的繼續努力，從中也積累了更多的經驗，這就是實踐給予我們的豐厚回報。
下面匯總了我做項目過程可能出現的故障及解決方法，看看是否與你有共鳴，并對你有幫助？
第一：常見問題解決集錦 1.shell 腳本不執行
問題：
某天研發某同事找我說幫他看看他寫的 shell 腳本，死活不執行，報錯。我看了下，腳本很簡單，也沒有常規性的錯誤，報“:badinterpreter:Nosuchfileordirectory”錯。
看這錯，我就問他是不是在 windows 下編寫的腳本，然后在上傳到 linux 服務器的 hellip; hellip; 果然。
原因：
在 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/2 1
3.telnet 很慢 /ssh 很慢
問題：
某天研發某同事說 10.50 訪問 10.52memcached 服務異常，讓我們檢查下看網絡 / 服務 / 系統是否有異常。檢查發現系統正常，服務正常，10.50ping10.52 也正常，但 10.50telnet10.52 很慢。同時發現該機器的 namesever 是不起作用的。
原因：
becauseyourPCdoesn rsquo;tdoareverseDNSlookuponyourIPthen hellip;whenyoutelnet/ftpintoyourlinuxbox,it rsquo;lldoadnslookuponyou。
解決：
1) 修改 /etc/hosts 使 hostname 和 ip 對應；
2）在 /etc/resolv.conf 注釋掉 nameserver 或者找一個“活的”nameserver。
4.Read-onlyfilesystem
問題：
同事在 mysql 里建表建不成功，提示如下：
mysql createtablewosontest(colddname1char(1));
ERROR1005(HY000):Can rsquo;t create table lsquo;wosontest rsquo;(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 lsquo;{print$NF} rsquo;|xargsrm-rf7. 獲取不了網關 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 Prime; /etc/security/limits.conf echo“*hardnproc65535 Prime; /etc/security/limits.conf echo“*softnofile65535 Prime; /etc/security/limits.conf echo“*hardnofile65535 Prime; /etc/security/limits.conf echo“”/root/.bash_profile echo“ulimit-n65535 Prime; /root/.bash_profile echo“ulimit-u65535 Prime; /root/.bash_profile最后重啟機器或者執行：
ulimit-u655345 ulimit-n6553510.ibdata1 和 mysql-bin 致磁盤空間問題
問題：
2.51 磁盤空間報警，經查發現 ibdata1 和 mysql-bin 日志占用空間太多（其中 ibdata1 超過 120G，mysql-bin 超過 80G）
原因：
bdata1 是存儲格式，在 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 lsquo;mysql-bin.010 prime;;
刪除某天前的日志：mysql PURGEMASTERLOGSBEFORE rsquo;2010-12-2213:00:00 prime;;
②在 /etc/my.cnf 里設置只保存 N 天的 bin-log 日志
expire_logs_days=30//BinaryLog 自動刪除的天數
二、故障排查匯總表
看完上述內容，你們對 Linux 運維常見故障及處理的方法是什么有進一步的了解嗎？如果還想了解更多知識或者相關內容，請關注丸趣 TV 行業資訊頻道，感謝大家的支持。
