系统磁盘优化——"/var/spool/postfix/maildrop"

标签：dir   span   markdown   cront   提示   div   时间   邮件   gre   

文件清理

最近某服务器磁盘空间告警，在排查过程中发现"/var/spool/postfix/maildrop"目录下堆积了很多小文件，起初想直接删除，但是使用rm删除是提示“参数列表过长”，后来使用rsync来清楚垃圾文件：

# 创建一个临时空文件夹
mkdir /tmp/blankdir
# 清理/var/spool/postfix/maildrop
rsync -av --delete /tmp/blankdir/  /var/spool/postfix/maildrop/
# rsync选项说明：
# --delete-before 接收者在传输之前进行删除操作
# --progress 在传输时显示传输过程
# --a 归档模式，表示以递归方式传输文件，并保持所有文件属性
# --H 保持硬连接的文件
# --v 详细输出模式
# --stats 给出某些文件的传输状态

注意：

• 不管是使用rm还是rsync，在清理文件之前一定要仔细确认文件是否有用，避免误操作。
• 使用rsync时空目录的路径后要带上"/"

追根溯源

在清理完文件后不久又有一次内存告警，检测发现有大量的“CRON、sendmail、postdrop”进程，同时还发现“/var/spool/postfix/maildrop”又有大量文件生成，Why？

于是开始排查，经过一番“海底捞”，真相终于浮出水面：

由于 Linux 在执行 cron 时，会将 cron 执行脚本中的 output 和 warning 信息，都会以邮件的形式发送 cron 所有者， 而由于客户环境中的 sendmail 和 postfix 没有正常运行，导致邮件发送不成功，全部小文件堆积在了 maildrop 目录下面，而且没有自动清理转换的机制，所以长达一年的时间，此目录已堆积了大量的文件。查看 man cron 的信息，可以知道会发送给 cron owner。

既然定位到是cron惹的祸，那就先把“sendmail、postdrop”干掉，解决燃眉之急，然后查找解决方案吧，办法如下：

• 将/etc/crontab文件中MAILTO="root"改成MAILTO=""（该办法只对crontab下的cron有效）；

• 在所有cron的第一行加入 MAILTO=""便可，这样执行当前用户的Cron时，就不会发送邮件了

  MAILTO=""
  * * * * * root /usr/sbin/python /tmp/test.py
  

之后再次清理“/var/spool/postfix/maildrop”下的垃圾文件，观察一下，没有文件再生成，问题解决！

系统磁盘优化——"/var/spool/postfix/maildrop"

标签：dir   span   markdown   cront   提示   div   时间   邮件   gre   

原文地址：https://www.cnblogs.com/liujiliang/p/9852998.html