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

发布时间 2023-04-20 13:00:20作者: Chuyio

早上收到报警如下:

触发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/

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

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

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