出了Linux故障找不到方法?看大牛简单、朴实的解决思路

【技术沙龙】AI开发者实战营-7分钟打造1个定制技能。7月22号,我们等你一起!

出了Linux故障找不到方法?看大牛简单、朴实的解决思路

与windows系统一样,linux操作系统也会存在很多问题和故障,很多linux新手都害怕故障,面对出现的问题显得无可奈何,更有甚者,由此放弃了linux,其实,我们不应该惧怕问题,学习就是一个发现问题与解决问题的过程,只要掌握了解决问题的基本思路,一切故障都会迎刃而解,当然前提是我们已经具备了解决问题的思路和扎实的知识功底。

作为一名合格的linux系统管理员,一定要有一套清晰、明确的解决故障思路,当问题出现时,才能迅速定位、解决问题,这里给出一个处理问题的一般思路:

——重视报错提示信息:每个错误的出现,都是给出错误提示信息,一般情况下这个提示基本定位了问题的所在,因此一定要重视这个报错信息,如果对这些错误信息视而不见,问题永远得不到解决。

——查阅日志文件:有时候报错信息只是给出了问题的表面现象,要想更深入的了解问题,必须查看相应的日志文件,而日志文件又分为系统日志文件(/var/log)和应用的日志文件,结合这两个日志文件,一般就能定位问题所在。

——分析、定位问题:这个过程是比较复杂的,根据报错信息,结合日志文件,同时还要考虑其它相关情况,最终找到引起问题的原因。

——解决问题:找到了问题出现的原因,解决问题就是很简单的事情了。

从这个流程可以看出,解决问题的过程就是分析、查找问题的过程,一旦确定问题产生的原因,故障也就随之解决了。

下面我们来看看这些问题的解法和做法:

问题1:Read-only file system 错误与解决方法

ag游戏大厅注册|平台解析:出现这个问题的原因有很多种,可能是文件系统数据块出现不一致导致的,也可能是磁盘故障造成的,主流ext3/ext4文件系统都有很强的自我修复机制,对于简单的错误,文件系统一般都可以自行修复,当遇到致命错误无法修复的时候,文件系统为了保证数据一致性和安全,会暂时屏蔽文件系统的写操作,讲文件系统 变为只读,今儿出现了上面的“read-only file system”现象。

手工修复文件系统错误的命令式fsck,在修复文件系统前,最好卸载文件系统所在的磁盘分区

#?umount?/www/data??Umount?:?/www/data:?device?is?busy?

提示无法卸载,可能是这个磁盘中还有文件对应的进程在运行,检查如下:

#?fuser?–m?/dev/sdb1??/dev/sdb1:?8800?

接着检查一下8800端口对应的什么进程,

#?ps?–ef?|grep?8800?

检查后发现时apache没有关闭,停止apache

#?/usr/local/apache2/bin/apachectl?stop??#?umount?/www/data??#?fsck?–V?–a?/dev/sdb1??#?mount?/dev/sdb1?/www/data?

问题2:“Argument list too long”错误与解决方法

#?crontab?–e?

编辑完后保存退出后,报错no space left on device

根据上面的报错了解到是磁盘空间满了,那么首先是检查磁盘空间,

#?df?–h?

查看到是/var磁盘分区空间已经达到100%,至此定位了问题所在。是/var磁盘空间饱满导致,因为crontab会在保存时将文件信息写到/var目录下面,然而这个磁盘没有空间了,所以报错。

接着通过命令du –sh * 命令检查/var目录下面的所有文件或者目录的大小,发现/var/spool/clientmqueue目录占用了/var整个分区大小的90%,那么/var/spool/clientmqueue目录下的文件都是怎么产生的,能否删除,基本上都是邮件信息,可以删除

#?rm?*??/bin/rm?:argument?list?too?long?

当在linux 系统中试图传递太多参数给一个命令时,就会出现“argument list too long ”错误,这是linux系统一直以来都有的限制,查看这个限制可以通过命令“getconf ARG_MAX”来实现,

#?getconf?ARG_MAX?

# more /etc/issue 查看版本

解决方法:

1、

#?rm?[a-n]*?-rf??#?rm?[o-z]*?-rf?

2、使用find命令来删除

#?find?/var/spool/clientmqueue?–type?f?–print?–exec?rm?–f?{}?;?



延伸阅读