Loading... <div class="tip share">请注意，本文编写于 1336 天前，最后修改于 565 天前，其中某些信息可能已经过时。</div> ##### Summary 在安装应用的时候，遇到了磁盘空间不足的问题，下面将整个排查思路写出来，给后人一个排查方向 由于是工作上的内容，没有对结果进行截图，只是提供命令和排查思路，遇到问题时可以结合命令和排查思路根据实际情况进行排查 ##### 现象 安装软件的时候，软件提示磁盘空间不足 ##### 排查和修复步骤 1. 查看磁盘容量使用情况 一般提示磁盘没空间，首先想到的肯定是磁盘没有容量了，可以先用 `df` 命令查看磁盘容量使用情况 ```bash df -h ``` 发现磁盘容量还有很多，并不是容量问题 决定磁盘空间大小的一个是 `磁盘容量` ，另外一个则是 `inode可用数` 了。如果 `容量` 没有问题，那么就是 `inode可用数` 为0 2. 查看`磁盘inode` 使用情况 顺着思路使用命令查看 `磁盘inode` 使用情况 ```bash df -i ``` 果然，通过命令发现， `/var` 的 `inode可用数` 为 **0** 。发现问题所在之后，开始排查 3. 查找大小为0的文件 在之前准备面试时，记得这样一个题目：如果 `inode` 满了怎么解决问题？答案是找出 `size` 为 `0` 的文件并 **删除** ，因为 `size` 为 `0` 的小文件不会占用 `磁盘容量` 但是会占用 `inode` 。那么，先找出大小为0的小文件吧，然后删掉一部分，看看能不能解决问题 ```bash find /var -type f -size 0 # find /var -type f -size 0 | xargs rm -rf # 这条命令找出来后可以删除文件 ``` 通过命令找出了一部分文件，但是在 `/var/spool/postfix/maildrop` 目录下就出现假死状态了，等待一段时间后还是假死，开始怀疑这个目录是不是有什么问题，于是停止了操作，打算到这个目录下看看有什么内容。 （其实在查看这个目录文件内容之前，我们已经对 `/var` 目录下部分文件进行了 **删除** 或者 **置空** 操作，但是 `inode可用数` 依然为 **0** ，不是解决问题的根源。） 5. 查看 `目录内容` 进入 `/var/spool/postfix/maildrop` 后执行 `ls` 命令，机器直接卡死了，通过直觉断定这个目录肯定有问题！（一般不要通过直觉去断定，要多方面证据去排查对问题的一个确定。） 为什么 `ls` 会卡死呢，我看到了这样一篇[文章](https://beyondkmp.com/post/ls%E5%91%BD%E4%BB%A4%E5%8D%A1%E4%BD%8F/)。当目录下文件数量过多时，由于 `ls` 会对输出结果进行排序，为了实现排序，会将文件名导入到内存中。那么将会出现假死现象。 既然 `ls` 发生假死，那就通过 `find` 命令去显示文件，但是依然是假死状态。（为什么会出现这种情况，我觉得还需要进一步研究一下，后面更新） ```bash find /var/spool/postfix/maildrop -type f ``` 通过 `ls` 和 `find` 都看不到目录内容，感觉这个目录肯定有问题。现在也暂时没啥思路，先对这个目录进行排查把。下一步怎么排查呢，打算从 `进程` 入手了。 5. 查看 `文件句柄` 既然目录内容无法查看，那么只能从 `进程` 入手了。但是linux进程那么多，又应该怎么排查呢。此处想到了用 `lsof` 命令来查看 `文件句柄` ```bash lsof /var/spool/postfix/maildrop ``` 果不其然，在输出的 `文件句柄` 结果中发现了大量的 `sendmail` 和 `postfix` 的进程在占用 `/var/spool/postfix/maildrop` 里面的文件 （后面复盘的时候，其实也可以从 `top` 命令发现异常的进程，但是不是很明显。也可以通过 `ps - ef`和`uniq`等命令统计进程数量，应该是可以，我后面尝试一下，可以的话补一下命令。不过还是专业点，用`lsof` 比较稳妥。） 5. 查看 `目录` 对应的 `应用程序` 搜索了一下 `sendmail` 和 `postfix` ，发现这个目录是用来存放发送不成功的邮件。系统中有 `cron` ，当 `cron` 执行完成后，会将 `执行脚本` 中的 `output` 和 `warning` 信息以 `邮件` 方式发送给 `cron所有者` 。如果 `sendmail` 和 `postfix` 服务不正常运行， `邮件` 则会以 `小文件` 形式存放在 `/var/spool/postfix/maildrop` 目录下 有了这个思路之后，到这一步其实大概的操作方法大家也知道了，就是删除这些文件。删除文件之前，需要先释放进程对文件的占用，于是写了命令把这些 `postfix` 和 `sendmail` 进程全部 `kill` 掉 ```bash lsof /var/spool/postfix/maildrop | awk 'NR!=1{print $2}' | head -5000 | xargs kill -9 ``` 执行完后，重新进入目录。使用 `find` 来列出 `目录` 的文件。（因为目录下的文件数量太多了，使用 `ls` 会出现假死状况） ```bash find /var/spool/postfix/maildrop -type f ``` 果然， `目录` 下面的文件显示了 6. **删除文件** 找到文件后，我们决定开始删除文件。因为 `ls` 会出现假死情况，所以通过 `find` 列出文件然后进行删除 ```bash find /var/spool/postfix/maildrop -type f | xargs rm -rf ``` 等待一段时间后，文件被删除了，此时再通过命令查看 `inode可用数` ```bash df -i ``` `inode 可用数` 已经恢复了正常，尝试在目录下面创建文件，也是OK了。问题解决。 ##### 总结 1. cron会将定时任务执行的脚本的output和warning的信息作为邮件通过sendmail或postfix发送给cron所有者。 2. 如果sendmail或postfix服务不正常，邮件将以小文件形式保存在 `/var/spool/postfix/maildrop` 3. 如果磁盘空间不足，需要结合磁盘 `可用容量` 和 `inode可以数` 两方面进行排查。 4. 不要理所当然去判断，要多方面证实是该问题再进行判断。 ##### 参考连接 * [https://blog.csdn.net/smstong/article/details/8920808](https://blog.csdn.net/smstong/article/details/8920808) * [https://www.cnblogs.com/maple-study/p/10456988.html](https://www.cnblogs.com/maple-study/p/10456988.html) * [https://www.jianshu.com/p/353a5dbcd423](https://www.jianshu.com/p/353a5dbcd423) * [https://beyondkmp.com/post/ls%E5%91%BD%E4%BB%A4%E5%8D%A1%E4%BD%8F/](https://beyondkmp.com/post/ls%E5%91%BD%E4%BB%A4%E5%8D%A1%E4%BD%8F/) 最后修改：2022 年 10 月 03 日 © 允许规范转载 赞 0 如果对你有帮助，可以请我喝杯奶茶哦