解决方案:No space left on device
寻找原因从字面上理解,这个问题是说磁盘上没有多余的空间。那么到底是什么地方将空间?先用df命令查看当前计算器磁盘空闲情况df -a我这边执行完后可以看到/dev/vda1被完全占用从根目录下开始使用du命令查找出空间占用最大的文件#查看当前目录下每个文件夹所占用的空间du -sh *通过一层一层的比较文件所占用空间,发现是jenkins的运行日志文件占用最大,本来我这边的的服务器磁盘仅10
寻找原因
从字面上理解,这个问题是说磁盘上没有多余的空间。
那么到底是什么地方将空间?
- 先用
df
命令查看当前计算器磁盘空闲情况
df -a
我这边执行完后可以看到/dev/vda1
被完全占用
- 从根目录下开始使用
du
命令查找出空间占用最大的文件
#查看当前目录下每个文件夹所占用的空间
du -sh *
通过一层一层的比较文件所占用空间,发现是jenkins的运行日志文件占用最大,本来我这边的的服务器磁盘仅100G,结果这个日志文件就有86G,我明白就是这个文件将磁盘占满了
解决方案
我首先想到的是直接删除该文件,于是我进入到jenkins的目录下,直接删除了所有日志。
rm -rf *.log
命令执行后,服务器的其他程序临时可以正常使用了。但是我运行df
命令时发现/dev/vda1
还是被完全占用,但是我想应用都正常在运行了,那也许是系统需要重启或过一段时间才能更新该状态,我也就没有再理会这个问题。
然而,这个问题并没有就此结束。第二天同事发现应用又不能访问了,我意识到昨天的那个问题还没有结束。我再次执行了df
和du
命令,发现df
的结果中表明/dev/vda1
依然被全部占用,而du
的结果中却没有再发现大文件了。我尝试着将解决这两种结果不一致的问题,兴许解决后就能解决”No space left o device”的问题了。
根据两个命令结果,我猜测应该是昨天直接通过rm
命令删除的文件空间没有被释放,所以我查看了系统中所有被打开的文件,在其中寻找到了那个日志文件”jenkins.log”。
lsof | grep "jenkins.log"
列表中有很多进程都在打开该文件,虽然文件删除了,但是打开该文件的进程没有关闭,也就是说文件实际上还是存在,rm
仅仅是删除了该文件的标记。
于是乎我果断的终止了打开该文件的进程。
kill -9 22731
执行完毕后,再次运行df
和du
,发现结果相差不大了。到此系统又可以正常运行了。
虽然这个问题算是临时解决了,但是jenkins的日志为什么可以达到86G?这个问题还没有得到解决,由于这一次删除的的充满,没有仔细看看日志的内容,导致该问题的原因不太能够查出。但是这个问题的根源肯定是没有被解决的,只能等到下一次该问题出现后,好好研究一下该日志,从根本上解决这个问题。
相关资料
更多推荐
所有评论(0)