一、引言

•目的：本文从作者运维问题的排查解决思路出发，分享linux操作系统下/目录inode过高排查解决方法。作者水平有限，仅供参考。

•读者对象：运维工程师、开发人员、对linux文件系统感兴趣的同学等。

二、问题现象：

        接到监控同学的告警发现：某服务器的根目录 inode使用率过高。

        备注：在 Linux 系统中，如果根目录 / 的 inode（索引节点）使用率达到100%，将会产生严重的后果。inode 是文件系统中用来存储文件元数据的数据结构，每个文件和目录都有一个唯一的 inode。inode 包含了文件的属性（如权限、所有者、时间戳等），但它并不包含文件的实际数据。因此当 inode 用尽时，意味着无法再创建新的文件或目录，即使磁盘空间仍然有剩余。这便会导致：日志记录中断、服务崩溃、系统性能下降、软件安装和更新失败（需要创建临时文件）等。

三、排查过程：

1.首先通过shell方式登录到服务器运维界面中；

2.通过df -Th发现/目录下磁盘数据使用并没有超过90%，通过df -i发现inode占用过高。

df -i

3.接下来需要定位问题，究竟是什么占用了大量的inode，通过for 循环遍历查一下/目录下哪个子目录的文件数量过多；

for i in /*; do echo $i; find $i |wc -l; done

        遍历发现/var目录下的文件数量非常多，继续按照for循环路径的方式向下排查发现大量的文件集中在/var/spool/postfix下。

        看到是/var/spool/postfix/maildrop这个目录下的文件数量过多，再依据以往的相似问题处理经验判断，基本可以断定是因为crontab的定时任务导致的。在crontab中任务执行后会将执行结果告知邮件联系人，但一旦发送失败就会在/var/spool/postfix/maildrop中生成文件(垃圾邮件)。

        因此检查下crontab定时任务，结果如上图所示，有两个时间同步的任务每天晚上23：59分会执行两遍，因此问题找到，需要进一步清理文件并优化一下定时任务的写法。

四、解决方法：

1.进入到目录下清理文件：

cd /var/spool/postfix/maildrop
ls | xargs -n 500 rm -rf

        备注：在这么多文件数量的目录下，如果直接使用 rm -rf ./* 直接删除，会报错参数列表过长：

        再检查发现inode使用率已经恢复了。

        为了避免后续持续产生垃圾文件，永久解决办法：关闭 crontab 执行后发送邮件给联系人的功能。默认情况下，crontab 任务执行的输出会被发送到用户的邮箱。如果想关闭这一功能，可以通过以下几种方式来实现：

1.设置 MAILTO 空字符串：在 crontab 文件中设置 MAILTO 变量为空字符串，这样就不会发送邮件了。

vi /etc/crontab

MAILTO=""

2.将输出重定向到日志文件：可以将任务执行的输出重定向到日志文件，而不是发送邮件。

59 23 * * * /usr/sbin/ntpdate 10.*.*.38 >> /var/log/cron.log 2>&1

3.使用 >/dev/null 2>&1 抑制输出：如果你想完全抑制任务的输出，可以将输出重定向到 /dev/null。

59 23 * * * /usr/sbin/ntpdate 10.*.*.38 > /dev/null 2>&1

        需注意：使用第1种方法，修改MAILTO后是对所有crontab定时任务生效，如果修改后未生效需要重启crontab服务。

        本文采用第3种方法：

crontab -e
59 23 * * * /usr/sbin/ntpdate 10.*.*.38 > /dev/null 2>&1

        配置后观察一段时间发现无新产生的垃圾文件。

其他情况：

        Inodes占用过高并非只有maildrop这一种情况，只是这种情况偏多。其他可能由于产生的临时文件过多或者0字节文件过多等现象导致，处理方式如下：

1.查看并删除/tmp下临时产生的文件。

ls /tmp | wc -l
find /tmp -type f -exec rm {} \;

2.删除/home/admin下0字节文件。

find /home/admin/ -type f -size 0 -exec rm {} \;

        当然，除了采用清理方式解决问题，还可以通过扩容文件系统的方式来增加可用的 inode 数量。具体步骤取决于使用的文件系统类型（如 ext2、ext3、ext4 等），后续会写一篇文章来介绍inode扩容的方法。

总结：

        当根目录 / 的 inode 用尽时，会对系统的正常运行造成严重影响。因此，一旦发现 inode 使用率过高，应及时处理。本文通过问题的排查思路，发现导致 inode 使用率过高的原因是 crontab 定时任务发送的大量垃圾邮件。针对这一问题，我们进行了垃圾文件的清理，并介绍了三种定时任务的优化方式。最终将问题解决。

        为了防止类似问题再次发生，建议优化监控措施，定期监控 inode 使用情况，并在发现告警时及时采取措施清理无用文件、扩展文件系统或调整 inode 数量。