Linux運維常見問題有哪些

1.shell腳本不執行

問題：某天研發某同事找我說幫他看看他寫的shell腳本，死活不執行，報錯。我看了下，腳本很簡單，也沒有常規性的錯誤，報“: bad interpreter: No such file or directory”錯。一 看這錯，我就問他是不是在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 |xargs rm -f ； 2）徹底解決：在cron的自動執行語句后加上 >/dev/null 2>&1

3.telnet很慢/ssh很慢

問題：某天研發某同事說10.50訪問10.52memcached服務異 常，讓我們檢查下看網絡/服務/系統是否有異常。檢查發現系統正常，服務正常，10.50ping10.52也正常，但10.50telnet10.52 很慢。同時發現該機器的namesever是不起作用的。 原因：because your PC doesn’t do a reverse DNS lookup on your IP then… when you telnet/ftp into your linux box, it’ll do a dns lookup on you。 解決： 1)修改/etc/hosts使hostname和ip對應； 2）在/etc/resolv.conf注釋掉nameserver或者找一個“活的”nameserver。

4.Read-only file system

問題：同事在mysql里建表建不成功，提示如下： mysql>create table wosontest (colddname1 char(1)); ERROR 1005 (HY000): Can’t create table ‘wosontest’ (errno: 30） 經檢查mysql用戶權限以及相關目錄權限沒問題；用perror 30提示信息為：OS error code 30: Read-only file system 可能原因： 1）文件系統損壞； 2）磁盤又壞道； 3）fstab文件配置錯誤，如分區格式錯誤錯誤(將ntfs寫成了fat)、配置指令拼寫錯誤等。 解決： 1）由于是測試機，重啟機器后恢復； 2）網上說用mount可解決。

5.文件刪了磁盤空間沒釋放

問題：某天發現某臺機器df -h已用磁盤空間為90G，而du -sh  /*顯示所有使用空間加起來才30G，囧。
原因：可能某人直接用rm刪除某個正在寫的文件，導致文件刪了但磁盤空間沒釋放的問題
解決：
1）最簡單重啟系統或者重啟相關服務。
2）干掉進程
/usr/sbin/lsof|grep deleted
ora    25575 data   33u      REG              65,65   4294983680  /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/shfind /tmp -name “picture_*” -mtime +1 -exec rm -f {} ;
原因：目錄下有大量文件，用find很耗資源。
解決：#!/bin/shcd /tmp
time=`date -d “2 day ago” “+%b %d”`
ls -l|grep “picture” |grep “$time”|awk ‘{print $NF}’|xargs rm -rf

7.獲取不了網關mac地址

問題：從2.14到3.65（映射地址2.141）網絡不通，但是從3端的其他機器到3.65網絡OK。 原因： # arp Address HWtype HWaddress Flags Mask Iface 192.168.3.254 ether incomplet CM bond0 表面現象是機器自動獲取不了網關MAC地址，網絡工程師說是網絡設備的問題，具體不清。 解決： arp綁定，arp -i bond0 -s 192.168.3.254 00:00:5e:00:01:64

8.http服務無法啟動一例

問題：某天研發某同事說網站前端環境http無法啟動，我上去看了下。報如下錯： /etc/init.d/httpd start Starting httpd: [Sat Jan 29 17:49:00 2011] [warn] module antibot_module is already loaded, skipping Use proxy forward as remote ip : true. Antibot exclude pattern : .*.[(js|css|jpg|gif|png)] Antibot seed check pattern : login (98)Address already in use: make_sock: could not bind to address [::]:7080 (98)Address already in use: make_sock: could not bind to address 0.0.0.0:7080 no listening sockets available, shutting down Unable to open log [FAILED] 原因： 1）端口被占用：表面看是7080端口被占用，于是netstat -npl|grep 7080看了下發現7080沒有占用； 2）在配置文件中重復寫了端口，如果在以下兩個文件同時寫了Listen 7080 /etc/httpd/conf/http.conf /etc/httpd/conf.d/t.10086.cn.conf 解決： 注釋掉/etc/httpd/conf.d/t.10086.cn.conf的Listen 7080，重啟，OK。

9.too many open file

問題：報too many open file錯誤
解決：終極解決方案echo “” >> /etc/security/limits.confecho “*                soft   nproc          65535″ >>  /etc/security/limits.confecho “*                hard   nproc          65535″ >>  /etc/security/limits.confecho “*                soft   nofile         65535″ >>  /etc/security/limits.confecho “*                hard   nofile         65535″ >>  /etc/security/limits.confecho “” >> /root/.bash_profileecho “ulimit-n   65535″ >> /root/.bash_profileecho “ulimit  -u   65535″ >> /root/.bash_profile
最后重啟機器 或者執行 ulimit -u 655345 && ulimit -n 65535

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 特點：每個表都有自已獨立的表空間；每個表的數據和索引都會存在自已的表空間中。 優點：表空間對應的磁盤空間可以被收回（Drop table操作自動回收表空間，如果對于刪除大量數據后的表可以通過:alter table tbl_name engine=innodb;回縮不用的空間。 缺點：如果單表增加過大，如超過100G，性能也會受到影響。在這種情況下，如果使用共享表空間可以把文件分 開，但有同樣有一個問題，如果訪問的范圍過大同樣會訪問多個文件，一樣會比較慢。如果使用獨立表空間，可以考慮使用分區表的方法，在一定程度上緩解問題。 此外，當啟用獨立表空間模式時，需要合理調整innodb_open_files參數的設置。 解決: 1）ibdata1數據太大：只能通過dump，導出建庫的sql語句，再重建的方法。 2）mysql-bin Log太大： ①手動刪除： 刪除某個日志：mysql>PURGE MASTER LOGS TO ‘mysql-bin.010′; 刪除某天前的日志：mysql>PURGE MASTER LOGS BEFORE ’2010-12-22 13:00:00′; ②在/etc/my.cnf里設置只保存N天的bin-log日志 expire_logs_days = 30 //Binary Log自動刪除的天數