解决方案：No space left on device

寻找原因

从字面上理解，这个问题是说磁盘上没有多余的空间。

那么到底是什么地方将空间？

1. 先用df命令查看当前计算器磁盘空闲情况

df -a

• 1

我这边执行完后可以看到/dev/vda1被完全占用

1. 从根目录下开始使用du命令查找出空间占用最大的文件

#查看当前目录下每个文件夹所占用的空间
du -sh *

• 1
• 2

通过一层一层的比较文件所占用空间，发现是jenkins的运行日志文件占用最大，本来我这边的的服务器磁盘仅100G，结果这个日志文件就有86G，我明白就是这个文件将磁盘占满了

解决方案

我首先想到的是直接删除该文件，于是我进入到jenkins的目录下，直接删除了所有日志。

rm -rf *.log

• 1

命令执行后，服务器的其他程序临时可以正常使用了。但是我运行df命令时发现/dev/vda1还是被完全占用，但是我想应用都正常在运行了，那也许是系统需要重启或过一段时间才能更新该状态，我也就没有再理会这个问题。

然而，这个问题并没有就此结束。第二天同事发现应用又不能访问了，我意识到昨天的那个问题还没有结束。我再次执行了df和du命令，发现df的结果中表明/dev/vda1依然被全部占用，而du的结果中却没有再发现大文件了。我尝试着将解决这两种结果不一致的问题，兴许解决后就能解决”No space left o device”的问题了。

根据两个命令结果，我猜测应该是昨天直接通过rm命令删除的文件空间没有被释放，所以我查看了系统中所有被打开的文件，在其中寻找到了那个日志文件”jenkins.log”。

lsof | grep "jenkins.log"

• 1

列表中有很多进程都在打开该文件，虽然文件删除了，但是打开该文件的进程没有关闭，也就是说文件实际上还是存在，rm仅仅是删除了该文件的标记。

于是乎我果断的终止了打开该文件的进程。

kill -9 22731

• 1

执行完毕后，再次运行df和du，发现结果相差不大了。到此系统又可以正常运行了。

虽然这个问题算是临时解决了，但是jenkins的日志为什么可以达到86G？这个问题还没有得到解决，由于这一次删除的的充满，没有仔细看看日志的内容，导致该问题的原因不太能够查出。但是这个问题的根源肯定是没有被解决的，只能等到下一次该问题出现后，好好研究一下该日志，从根本上解决这个问题。