LINUX关于Cron调用sendmail引起的资源耗尽问题

具体现象：

使用CRT等远程工具无法登陆主机，本地登陆时异常缓慢，top发现内存及SWAP已经耗尽，查看进程发现存在大量sendmail及postdrop进程。

---

原因分析：

由于服务器上的不同用户定义了很多定时任务。定时任务有个特点，就是如果定时任务中执行的命令有输出时（包括标准输出和错误输出），由于没有地方显示，会调用sendmail把输出的内容通过邮件发送给crontab的拥有者。如果一切正常的情况下，邮件会发送到/var/mail下的用户同名文件中（/var/spool/mail下也会存在，他们是同一个文件的两个引用）。但是一般环境搭建时都会关闭postfix服务，所以邮件发送肯定会失败，此时sendmail又会调用postdrop将邮件存入/var/spool/postfix/maildrop下（如果postfix服务器启动后，会扫描下面的内容将maildrop下的信息重新以邮件形式发送出去，并且清空maildrop）。这时的调用链是cron->sendmail->postdrop。如果定时任务执行不频繁或者输出内容较少时，基本可以忽略maildrop占用空间问题。

但是当postdrop不能正常操作/var/spool/postfix/maildrop目录时(可能是由于权限问题或/var文件系统满或/var的inode满)，导致postdrop不能正常退出而反复尝试写入，在调用链上的sendmail也不能正常结束。当下次启动定时任务时，又会产生相同数量的进程hang住，时间一长就产生了问题：

1、大量进程占用过多PID资源，达到系统限制上限，导致系统无法创建新的进、线程

2、大量进程耗费全部内存及SWAP，导致系统OOM，不断杀掉其他进程或崩溃

3、大量报错写入/var/log/mail中，可能导致/var文件系统满

---

解决方法：

1、使用pkill命令杀掉sendmail及postdrop进程，让系统释放资源，并清理/var/spool/postfix/maildrop下的文件

2、查看并修正目录权限chown postfix:postdrop /var/spool/postfix/maildrop

3、在用户crontab的第一行添加MAILTO=""  表示即使有输出也不发送邮件，然后重启crond服务，或者处理有输出的脚本将输出重定向到/dev/null

4、上述MAILTO的方法为治标，需要为不同用户分别添加比较麻烦，可以在确保postfix服务被停止的情况下，为root用户添加定时任务，定期清理/var/spool/postfix/maildrop下的文件

      另一种方式是去掉/sbin/sendmail.postfix和/sbin/postdrop的执行权限，让进程无法调起也可以达到目的