删除maildrop 目录下大量文件以及避免后续再次发生

这两天遇到一个问题:
1、问题现象
一个linux主机上报存储过大的告警,/var/spool/postfix/maildrop 目录下的文件多大400万个,占用存储30G,ls、rm等命令执行就卡主,抽查一两个文件,文件名是类似095285C63AF6这样的12位16进制的数字顺序组合,文件大小都是几K,文件内容没有实质性的意义。

2、问题原因:网上查了下,具体如下
该主机上有一些crontab,执行频率比较高,每次执行都会默认将output和warning信息邮件发送给crontab的属主,linux没有配置邮件功能,会导致有你发送不出去,从而以文件的形式堆积在/var/spool/postfix/maildrop目录下。

3、问题解决方案
3.1、临时方案:这些文件没有实际作用,手动删除。
手动删除400多万个小文件,rm -f 删除执行不动,不知道执行效率,如果一直放在那里执行,也不确定会不会因客户端会话过期导致执行失败。而且rm -f 如果文件过多,也会报错说传递的参数过大,导致无法删除。
自动化脚本:通过 ls -f1 /var/spool/postfix/maildrop/* > ~/tmp.txt ,将文件名清单写入到临时文件中,然后通过shell脚本,读取文件清单,一个个文件删除,加上语句,也可以知道当前删除的是哪个文件,脚本内容如下。

#!/bin/bash

cd /var/spool/postfix/maildrop/

ls -f1 /var/spool/postfix/maildrop/* > /root/tmp.txt

for i in `cat /root/tmp.txt`

do

echo $i

rm -f $i

done

echo "complete!"

3.2、彻底解决方案:禁用crontab的邮件发送
在每个用户的crontab下增加邮件配置的语句,如下示例:

 MAILTO=""

*/5 * * * * /bin/bash

*/2 * * * * /bin/sh

4、总结
耗时最长的是手动删除400多个文件,毕竟积累了好几年的东西, shell脚本不一定是最快、最优的方式,比如是否可以直接删除maildrop文件夹,删除完后再创建一个maildrop文件夹,不确定是否可行,但是是做法上最简单的一种,能解决当前问题就行,看问题紧急、重要程度和影响。

以上是 删除maildrop 目录下大量文件以及避免后续再次发生 的全部内容, 来源链接: utcz.com/z/267451.html

回到顶部