Inodes 占用率 100%导致服务器 50X

开始#

某天早上，公司项目突然访问失败，一直重定向，页面打开失败

排查#

第一：根据以往经验，首先定位问题是 session 存放路径的权限问题，查看过后发现权限是 ok 的。

第二：查看 nginx 日志，没发现问题

第三：查看项目日志，发现每次访问报错都是报数据表不存在。诡异的直觉告诉我难道数据库被删了，速度查看之后发现并没有

第四：重启服务器，再访问网站还是失败，此时启动 mysql 服务失败，报错 Can 't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock '(2) "。开始搜索这个错误的解决方法，发现是重启失败导致这个文件没生成，然后去查看 my.cnf 的配置，socket 对应的存放路径是 /tmp/mysql.sock。查看 /tmp 目录，不存在，尝试创建 mkdir tmp，报错 xxxx: No space left on device。

第五：看到空间不足，我尝试查看磁盘使用情况 df -ih。发现 inodes 的使用率已达 100%。搜解决方法，发现在 /var/spool/postfix/maildrop 存在大量的小文件，根据方法删除过后（10 多个小时），重启服务器，恢复正常。

挖掘#

思考生成这么多小文件的原因，继续搜 /var/spool/postfix/maildrop，发现是 crontab 惹的祸，它每次的 output 或者 warning 都会发送邮件，发送失败就会生成小文件堆积在此目录下。

问题就又变了，怎么导致邮件发送失败，查日志 less /var/log/maillog。发现里面不断地产生 IPv6 support is disabled: Address family not supported by protocol 和 unable to look up public/pickup: No such file or directory 这两个 warning。

搜过后发现是 postfix 服务有问题，由于 postfix 的配置 inet_protocols = all 设定了同时支持 ipv6 和 ipv4，但是 linux 默认只支持 ipv4，更改配置 inet_protocols = ipv4 过后，maillog 日志不再报错。

此时还有一点就是 crontab 的通知实在过于频繁，所以也找了处理方法。