作为linux运维，多多少少会碰见这样那样的问题或故障，从中总结经验，查询问题，汇总并分析故障的原因，这是一个Linux运维工程师良好的习惯。每一次技术的突破，都经历著苦闷，伴随着快乐，可我们还是执著的继续努力，从中也积累了更多的经验，这就是实践给予我们的丰厚回报。
第一、常见问题解决集锦
1. shell指令码不执行
(1) 问题：
某天研发某同事找我说帮他看看他写的shell指令码，死活不执行，报错。我看了下，指令码很简单，也没有常规性的错误，报“:badinterpreter:Nosuchfileordirectory”错。
看这错，我就问他是不是在windows下编写的指令码，然后在上传到linux服务器的……果然。
(2) 原因：
在DOS/windows里，文字档案的换行符为rn，而在nix系统里则为n，所以DOS/Windows里编辑过的文字档案到了nix里，每一行都多了个^M。
(3) 解决：
重新在linux下编写指令码;
vi:%s/r//g:%s/^M//g(^M输入用Ctrl+v,Ctrl+m)
附：sh-x指令码档名，可以单步执行并回显结果，有助于排查复杂指令码问题。
2. crontab输出结果控制
(1) 问题：
/var/spool/clientmqueue目录占用空间超过100G
(2) 原因：
cron中执行的程式有输出内容，输出内容会以邮件形式发给cron的使用者，而sendmail没有启动所以就产生了/var/spool/clientmqueue目录下的那些档案，日积月累可能撑破磁盘。
(3) 解决：
直接手动删除：ls|xargsrm-f;
彻底解决：在cron的自动执行语句后加上>/dev/2>&1
3. telnet很慢/ssh很慢
(1) 问题：
某天研发某同事说10.50访问10.52memcached服务异常，让我们检查下看网络/服务/系统是否有异常。检查发现系统正常，服务正常，10.50ping10.52也正常，但10.50telnet10.52很慢。同时发现该机器的namesever是不起作用的。
(2) 原因：
becauseyourPCdoesn’tdoareverseDNSlookuponyourIPthen…
whenyoutelnet/ftpintoyourlinuxbox,it’lldoadnslookuponyou。
(3) 解决：
修改/etc/hosts使hostname和ip对应;
在/etc/resolv.conf注释掉nameserver或者找一个“活的”nameserver。
4. Read-onlyfilesystem
(1) 问题：
同事在mysql里建表建不成功，提示如下：
mysql>createtablewosontest(colddname1char(1)); ERROR1005(HY000):Can’t create table‘wosontest’(errno:30）
经检查mysql使用者许可权以及相关目录许可权没问题;用perror30提示资讯为：OSerrorcode30:Read-onlyfilesystem
(2) 可能原因：
档案系统损坏;
磁盘又坏道;
fstab档案配置错误，如分割槽格式错误错误(将ntfs写成了fat)、配置指令拼写错误等。
(3) 解决：
由于是测试机，重启机器后恢复;
网上说用mount可解决。
5. 档案删了磁盘空间没释放
(1) 问题：
某天发现某台机器df-h已用磁盘空间为90G，而du-sh/*显示所有使用空间加起来才30G，囧。
(2) 原因：
可能某人直接用rm删除某个正在写的档案，导致档案删了但磁盘空间没释放的问题
(3) 解决：
最简单重启系统或者重启相关服务。
干掉程序
/usr/sbin/lsof|grepdeleted
ora25575data33uREG65,654294983680/oradata/DAT
从lsof的输出中，我们可以发现pid为25575的程序持有着以档案描述号(fd)为33开启的档案/oradata/DATAPRE/UNDOTBS009.dbf。
在我们找到了这个档案之后可以通过结束程序的方式来释放被占用的空间：
echo>/proc/25575/fd/33
6. find档案提升效能
(1) 问题：
在tmp目录下有大量包含picture_*的临时档案，每天晚上2:30对一天前的档案进行清理。之前在crontab下跑如下指令码，但是发现指令码效率很低，每次执行时负载猛涨，影响到其他服务。
#!/bin/sh find/tmp-name“picture_*”-mtime+1-execrm-f{};
(2) 原因：
目录下有大量档案，用find很耗资源。
(3) 解决：
#!/bin/sh cd/tmp time=`date-d“2dayago”“+%b%d”` ls-l|grep“picture”|grep“$time”|awk‘{print$NF}’|xa
7. 获取不了闸道器mac地址
(1) 问题：
从2.14到3.65(对映地址2.141)网络不通，但是从3端的其他机器到3.65网络OK。
(2) 原因：
#arp AddressHWtypeHWaddressFlagsMaskIface 192.168.3.254etherincompletCMbond0
表面现象是机器自动获取不了闸道器MAC地址，网络工程师说是网络装置的问题，具体不清。
(3) 解决：
arp系结，arp-ibond0-s192.168.3.25400:00:5e:00:01:64
8. http服务无法启动一例
(1) 问题：
某天研发某同事说网站前端环境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]
(2) 原因：
埠被占用：表面看是7080埠被占用，于是netstat-npl|grep7080看了下发现7080没有占用;
在配置档案中重复写了埠，如果在以下两个档案同时写了Listen7080/etc/httpd/conf/http.conf
/etc/httpd/conf.d/t.10086.cn.conf
(3) 解决：
注释掉/etc/httpd/conf.d/t.10086.cn.conf的Listen7080，重启，OK。
9. toomanyopenfile
(1) 问题：
报toomanyopenfile错误
(2) 解决：
终极解决方案
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致磁盘空间问题
(1) 问题：
2.51磁盘空间报警，经查发现ibdata1和mysql-bin日志占用空间太多(其中ibdata1超过120G，mysql-bin超过80G)
(2) 原因：
bdata1是储存格式，在INNODB型别资料状态下，ibdata1用来储存档案的资料和索引，而库名的资料夹里的那些表文件只是结构而已。
innodb储存引擎有两种表空间的管理方式，分别是：
共享表空间(可拆分为多个小的表空间档案)，这个是我们目前多数数据库使用的方法;
独立表空间，每一个表有一个独立的表空间(磁盘档案)
对于两种管理方式，各有优劣，具体如下：
① 共享表空间：
优点：可以将表空间分成多个档案存放到不同的磁盘上(表空间档案大小不受表大小的限制，一个表可以分布在不同步的档案上)
缺点：
所有资料和索引存放在一个档案中，则随着资料的增加，将会有一个很大的档案，虽然可以把一个大档案分成多个小档案，但是多个表及索引在表空间中混合储存，这样如果对于一个表做了大量删除操作后表空间中将有大量空隙。
对于共享表空间管理的方式下，一旦表空间被分配，就不能再回缩了。当出现临时建索引或是建立一个临时表的操作表空间扩大后，就是删除相关的表也没办法回缩那部分空间了。
②独立表空间：
在配置档案(my.cnf)中设定：
特点：每个表都有自已独立的表空间;每个表的资料和索引都会存在自已的表空间中。
优点：表空间对应的磁盘空间可以被收回(Droptable操作自动回收表空间，如果对于删除大量资料后的表可以通过:altertabletbl_nameengine=innodb;回缩不用的空间。
缺点：
如果单表增加过大，如超过100G，效能也会受到影响。在这种情况下，如果使用共享表空间可以把档案分开，但有同样有一个问题，如果访问的范围过大同样会访问多个档案，一样会比较慢。
如果使用独立表空间，可以考虑使用分割槽表的方法，在一定程度上缓解问题。此外，当启用独立表空间模式时，需要合理调整innodb_open_files引数的设定。
(3) 解决:
①ibdata1资料太大：只能通过dump，汇出建库的sql语句，再重建的方法。
②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自动删除的天数
