linux运维系统故障排查思路及常见故障处理
Posted
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了linux运维系统故障排查思路及常见故障处理相关的知识,希望对你有一定的参考价值。
一 linux系统故障的一般处理思路
报错信息--->查阅日志文件--->分析定位问题--->解决问题。
二 linux系统无法启动原因及解决
系统无法启动的原因很多,常见的有下面几种情况:
1 文件系统被破坏,常常因断电和非法关机引起文件系统结构不一致。修复方法是用fsck命名强制修复,进入单用户模式或者交互界面,按提示进入修改模式中,卸载对应的问题磁盘,然后用fsck命令修复,无法恢复的数据会存放在lost+found下。umount /dev/sda3 fsck.ext4 -y /dev/sda3
2 系统配置/etc/fstab错误或丢失而无法启动。当启动时候出现 starting system logger后停止了,就要想办法恢复/etc/fstab文件,利用linux rescue修复模式登录系统,从而获取挂载点和分区信息,重构/etc/fstab文件。
3 系统内核文件丢失,内核升级错误,引导程序出错,硬件故障等都会引起无法启动
三 linux网络故障处理思路流程
1 检查权限是否打开,iptables,selinux
2 服务是否正常,用Telnet或netstat检查服务是否正常开启
3 检查本机网络是否正常,ping自身IP、同网段主机、网关
4 检查DNS解析是否正常,/etc/hosts和/etc/resolv.conf
5 检测网卡ip设置,route检查路由是否正确
6 检查网路硬件,网卡、路由器、集线器、网线、交换机(lsmod、ifconfig、ip)
四 Read-only file system 错误解决
思路:
网站程序问题
磁盘问题
排查网站程序,看报错信息和服务日志错误,以及系统日志,来定位问题所在 Read-only file system 多数就是磁盘问题,出现上面错误的时候,磁盘对应目录是无法写入的,那么就要进行修复了,文件系统修复命令fsck
首先查看是否有用户正在使用该磁盘,fuser -m /dev/sda1,如果有就停止对应端口程序
接着卸载文件系统 umount /www/data
然后修复文件系统 fsck -V -a /dev/sda1
最后恢复挂载 mount /dev/sda1 /www/data
五 Argument list too long 错误解决
当删除一个目录中的大量文件时,可能会出现这种报错,这是由于linux系统对传递参数的限制,可以用getconf ARG_MAX查看这个数值,
重新编译内核参数可以永久解决问题,但是编译内核有风险,还是用下面方法保险
既然不能一下清除大量文件,那么分批删除或者查找或者循环删除就可以了,可以用下面命令清理
rm [a-n]* -rf
rm [o-z]* -rf
find /www/data -type f -print -exec rm -f {} \;
六 inode耗尽故障
当iNode耗尽后,磁盘虽然有剩余空间,但也会出现 no space left 的报错
用 df -i 命令可以查看所有分区对应inode的使用情况
用 ls -i nginx.log 能查看对应文件的inode编号。详细信息用 stat nginx.log 查看
针对inode耗尽的情况,清理删除那些无用的文件就可以了,尤其是那些碎小的文件
七 删除文件后空间不释放问题
文件系统的数据分为两个部分:数据部分和指针部分,当有进程正在使用某个文件是,执行删除命令,空间是不会释放的,删除的是数据文件部分,指针部分并未删除,所以空间并不释放。
用 lsof |grep delete 查看已删除的文件,找到对应文件 执行清空命令 echo " " > /tmp/nginx.log 空间就会得到释放
八 “too many open files”错误
服务出现报错异常 too many open files
用 ulimit -n 查看文件描述符 65535 是最大值
检查普通用户的值 cat /etc/security/limits.conf |grep www
如果普通用户的值不是65535 那么给普通用户添加这个限制
www soft nofile 65535
www hard nofile 65535
如果上面的普通用户的值显示65535 而依旧出现这个错,就要考虑添加limit值的时间是否早于应用最后一次启动的时间,应用时间早的话,直接重启应用就可以了
以上是关于linux运维系统故障排查思路及常见故障处理的主要内容,如果未能解决你的问题,请参考以下文章