Loading... <div class="tip share">请注意,本文编写于 1628 天前,最后修改于 857 天前,其中某些信息可能已经过时。</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 如果对你有帮助,可以请我喝杯奶茶哦