持续创作，加速成长！这是我参与「掘金日新计划 · 10 月更文挑战」的第15天，点击查看活动详情
时间
大概早上9点多。发现服务器异常，站点无法访问。
处理经过
发现问题之后，立即尝试使用远程工具登录服务器，排查问题；但是发现远程工具无法连接，改用云服务器的控制台进行登录，发现还是登录不了，并且发现监控数据显示cpu、内存处于100%状态；于是，尝试进行重启，重启完成之后，cpu、内存下降到正常的状态，可以正常登录，但是一直无法执行相关启动服务的命令，提示存储不足，考虑到硬盘剩余空间确实比较小，遂进行硬盘扩容、重启，问题还是没解决；
[root@VM_0_11_centos /]# ps -ef |grep java\
Signal 11 (SEGV) caught by ps (procps-ng version 3.3.10).\
ps:display.c:66: please report this bug
于是马上给腾讯云提工单，客服响应之后，服务器进入救援模式，经过排查，看到一个i节点告警的信息。一路排查下去发现是/var/spool/postfix/maildrop下的inode很大，查看了下文件数量有三百多万。定位到了问题。
查询资料了解到
由于 Linux 在执行 cron 时，会将 cron 执行脚本中的 output 和 warning 信息，都会以邮件的形式发送 cron 所有者， 而由于客户环境中的 sendmail 和 postfix 没有正常运行，导致邮件发送不成功，全部小文件堆积在了 maildrop 目录下面，而且没有自动清理转换的机制，所以长时间，此目录已堆积了大量的文件。查看 man cron 的信息，可以知道会发送给 cron owner.
处理方式
这类数据一般没有什么价值，直接删除就好了。执行命令：ls |xargs rm -f。问题解决。
彻底解决
-
crontab中执行的任务的输出需要定向到指定文件，对于不关心的输出输出到/dev/null.
-
增加定时清理文件夹的操作。
*/10 * * * * /root/clean_maildrop.sh >/dev/null 2>&1
3、后续将对服务器进行定期的运维，及时发现处理告警信息，防患于未然。
