/var/spool/postfix/maildrop占用空间及inode问题处理

早上收到报警如下：

触发2级告警【严重】- 来源【指标平台】
⏰ 告警时间：2023-04-20 09:15:43
🕐 发生时段：2023-04-20 09:14:43 ~ 持续中
📌 告警标题：基础资源监控-linux系统inode使用率（本地磁盘）一线运维
📚 监控类型：基础资源监控
📜 策略名称：磁盘
🔖 告警摘要：报警对象:[ip=xx.xx.xx.xx,businessName=xxxx,device=/dev/mapper/centos-var,mountpoint=/var];inode使用率>=阈值(80)，当前值:100.00%;持续时长:1分13秒
☎ 联系人员：
📄 详细信息：基础资源监控-linux系统inode使用率（本地磁盘）一线运维
🔔 一线运维： 通知 ✔

触发3级告警【一般】- 来源【指标平台】
⏰ 告警时间：2023-04-20 09:14:44
🕐 发生时段：2023-04-20 09:14:44 ~ 持续中
📌 告警标题：基础资源监控-linux系统磁盘空间（使用率超80%且剩余200G以下）一线运维
📚 监控类型：基础资源监控
📜 策略名称：磁盘
🔖 告警摘要：报警对象:[ip=xx.xx.xx.xx,businessName=xxxx,device=/dev/mapper/centos-var,mountpoint=/var];磁盘使用率>=阈值(80)，当前值:97.00%;磁盘可用容量<阈值(200)，当前值:0.00GB;持续时长:10分12秒
☎ 联系人员：
📄 详细信息：linux系统磁盘空间（使用率超80%且剩余200G以下）
🔔 一线运维： 通知 ✔

磁盘满的同时inode也满了，这种情况一般是var空间较小，且小文件较多
经排查为/var/spool/postfix/maildrop下计划任务失败发送邮件文件导致
通过查看邮件中的报错信息，定位到计划任务的失败原因，已进行修复

我看网上很多都是直接关闭掉了，方法我也整理了下，贴在下面

vim /etc/crontab
将‘MAILTO=root’替换成‘MAILTO=" "
systemctl restart crond
编辑当前用户的cron服务
# crontab -e
MAILTO=""

方法二
echo “unset MAILCHECK” >> /etc/profile ；source  /etc/profile
# 创建一个临时空文件夹

方法三
直接把信息输出到 /dev/null
crontab -l
#每周一至周六凌晨3:00 mysqldump全量备份
0 3 * * 1-6 /bin/bash /data/mysql/mysqldump.sh >/dev/null 2>&1

mkdir /tmp/blankdir
# 清理/var/spool/postfix/maildrop
rsync -av --delete /tmp/blankdir/  /var/spool/postfix/maildrop/

关不关失败发送邮件，还要看个人选择，执行失败发送邮件信息里还是比较有用，能快速定位到问题原因并进行修复

不过，想要及时发现，可能需要配置邮件服务器、或者配置监控系统实时监控里面文件信息，让邮件或监控信息真正能发出去才有价值

以上方法更推荐使用第三种，对于不需要发送的信息直接丢掉即可，不至于所有的都不能接收到邮件。