[续]/var/spool/postfix/maildrop/下的小文件怎么来的？

    《/var/spool/postfix/maildrop/下的小文件怎么来的？》一文中提到了系统/var被占满而造成系统无法启动，根据进程中的pid和ppid关系分析出来是cron造成的这些小文件，但是当时还有一个现象是被忽略了。
    除了/var/spool/postfix/maildrop中有很多文件之外，系统进程中还有很多类似下面postdrop的进程，这些进程是如何产生的呢？

root 32723 4665 0 11:00 ? 00:00:00 crond
cpems 32726 32723 0 11:00 ? 00:00:00 /bin/sh /home/cpems/cpst/ems/scripts/autoupgrade.sh -d
cpems 32743 32723 0 11:00 ? 00:00:00 /usr/sbin/sendmail -FCronDaemon -i -odi -oem -oi -t
cpems 32753 32743 0 11:00 ? 00:00:00 /usr/sbin/postdrop -r


   
    cron进程默认会将计划任务中所运行的脚本的警告、错误信息或者脚本输出信息发送给计划任务的所有者，而由于系统的postfix默认没有打开，所以这些邮件放到了邮件队列maildrop目录中，如果计划任务比较多，而且都有信息输出或者有错误，那么maildrop中的小文件肯定会越来越多。此时如果启动postfix服务，那么这些文件都会发送给计划任务的所有者，maildrop目录中的小文件没有了，却到了/var/spool/mail下面了（dc5.0上postfix默认无法发送邮件）。
    解决这个问题还需要从计划任务中的内容着手，既然是计划任务，就不要让其中的脚本/命令输出任何信息，如果有信息可以重定向到/var/null。在这就要保证脚本/命令不要有任何错误。当然还可以采用上一篇文章中写到的方法：MAILTO=“”。
   
    书接上文，那么进程中出现很多/usr/sbin/postdrop -r的进程是神么原因呢？
    经过测试发现（别看我说的简单，就四个字“经过测试”，其实测试过程中走了很多弯路，苦恼了很久的），计划任务中的脚本如果不退出，一只挂着，那么才会出现上面引用中的/usr/sbin/postdrop -r进程。看我下面这个计划任务的例子：

[root@DC5SP3 maildrop]# crontab -l
*/1 * * * * ps -wef
*/2 * * * * ps --ef 2>/tmp/ps.txt.1
*/3 * * * * tail -f /var/log/messages


    再对比一下进程中的状态：

root 4041 2510 0 14:57 ? 00:00:00 crond
root 4044 4041 0 14:57 ? 00:00:00 tail -f /var/log/messages
root 4047 4041 0 14:57 ? 00:00:00 /usr/sbin/sendmail -FCronDaemon -i -odi -oem -oi -t
root 4048 4047 0 14:57 ? 00:00:00 /usr/sbin/postdrop -r


    总结出来就是：计划任务中的脚本挂着不退出，就会出现/usr/sbin/postdrop -r进程。
    原因找到了，同样MAILTO=“”的方法一样可以解决这个问题。