[续]/var/spool/postfix/maildrop/下的小文件怎么来的？-凯发app官方网站

一文中提到了系统/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=“”的方法一样可以解决这个问题。

阅读(1880) | 评论(0) | 转发(1) |

上一篇：infiniband 卡做双卡 bonding

给主人留下些什么吧！~~

| | | | |

感谢所有关心和支持过chinaunix的朋友们