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

____今天在客户那遇到一个典型问题，有两台机器也是/分区占用的比较多，最后定位在/var/spool/clientmqueue这个目录。这个目录里面有223w个小文件。我已经猜到这个问题了，因为上一次我拿24小时的时候，也是接到一个电话，发现/var/spool/postfix/maildrop/下面有很多小文件，正好接这个电话的时候，jiangeng在旁边，他说上周他接过一个一模一样的问题，停掉postfix和sendmail然后清空/var/spool/postfix/maildrop/这个目录即可。我当时也是让他清空完事。但是那件事过去之后，我就没再想是什么原因，但是隐约知道跟邮件有关，应该是临时邮件。今天遇到的这个问题，和上一次累死，但是稍微不同，可能是一个系统默认邮件服务是postfix一个是sendmail。我首先想清除这些小文件，但是使用rm  -rf  *的时候，直接就给断掉shell了。我重新登上去，ls的时候，就花了好几分钟。看来是因为底下文件太多了，想用通配符的方式删除看来是不行了。采用最笨的方法，将文件名输出到一个文件里面，然后用脚本一个一个删除。很慢啊。
____等着删除之余，我想看看到底是怎么产生的这些小文件。这个目录是sendmail产生的，进程里面可以看出来crond衍生出的sendmail服务，/etc/cron.*里面没有发现关于sendmail的文件，crontab里面也只有两个任务都没有用到sendmail。返回来又仔细看进程的时候，发现sendmail产生的时候，在其前面是crontab里面的那个脚本，而且这两个都是一个父进程crond产生的。我突然想到是不是crontab里面的脚本执行失败时都都要发给root？现场没有时间分析具体的原因，我想了个比较笨的方法。crond调用的/usr/sbin/sendmail启动的sendmail进程，拿我就将/usr/sbin/sendmail更名为mailsend（本来想卸掉sendmail的，但是又怕出问题），这样crontab的确会产生一个crond的死进程，但是还是正常执行了。我分析是因为sendmail命令没有造成的。此时也不生成小文件了。
____回公司之后开始找环境测试这个问题。这是个典型的问题，起码jiangeng和我最近都遇到过了，而且都没有追究原因，只是简单的暂时解决而已。现在我既然已经发现是crond在发邮件了，就要找到最终的解决办法。环境采用4.1.但是找到的是一个4.1sp3。随便写了个计划任务，看进程的时候发现使用postfix发送邮件。然后看/var/spool/postfix/maildrop下面已经开始有小文件了，看来就是crond运行的时候，希望将脚本返回信息通过邮件的形式发给谁，比如root。我将系统的MTA从默认的postfix改成sendmail。然后就发现成了/var/spool/clientmqueue开始产生小文件了（注释一下，本来sendmail是可以正常发邮件的，所以这个目录里面开始并没有东西，后来我把/var/spool/mail/root加了个不可更改属性，才产生的文件）。由此看来，就是crond在执行的时候，会将脚本的接过发给某个人比如root。
____在网上搜了一下，发现原来是crontab中一个参数MAILTO=“”可以限定这个。看crontab的man5说明，如果cron有什么原因需要将命令结果发一封邮件，那么就要看MAILTO这部分了，如果给MAILTO赋值了，并且不是空，那么就会发给这个用户；如果是空，MAILTO=""，那就不发任何邮件。如果没有定义MAILTO，也就是说crontab里面没有写这一行，那么就发给这个crontab的主人。 这就是为什么crond老往外发信的原因了。但是为什么出现这些小文件呢？问mlsx之后，mlsx说这是邮件堵塞，postfix默认情况下是无法发邮件的，那么堵塞很正常，但是sendmail为什么堵塞不知道。当然象我这样，给/var/spool/mail/root加了个不可更改属性是不会出现的。
____问题基本搞清除了，解决办法是在crontab里面加上MAILTO=“”，这样不论系统默认的MTA是什么，crond都不会再发邮件了，那当然不会出现堵塞了。
____其实这反应一个问题，mlsx说他早就知道这个问题，但是他老感觉其他人也知道。但是我在红旗工作了三年了，才第一次关注这个问题。这说明什么呢？说明我们太想当然了，太不求甚解了，也说明我们太懒了。
____原文摘录如下

cpragman                            05-22-2005, 12:33 AM
I've found tons of undelivered cron messages in my /var/spool/clientmqueue folder (from Jaguar), and now panther seems to be stuffing them into /Var/spool/postfix/maildrop.

I cleaned 17GB out of /var/spool/clientmqueue last night. This has got to stop.

I know I can enable sendmail and configure forwarding for root to pass these along to a regular mail account, but I'd rather not bother.

I'd like to make cron stop mailing these notices. I see that I can edit my crontab file to add the variable "MAILTO=" and it will stop.

This seemed to work for ROOT, but when I try to edit my own user crontab file (crontab -e), I get an error message that makes no sense.

"/tmp/crontab.FRHPisVp3G":1: bad minute
crontab: errors in crontab file, can't install

I don't get it. I can change this file in all kinds of ways without error, but as soon as I add the "MAILTO=" line, it throws this error.

Any ideas what I'm doing wrong?




---

voldenuit                   05-22-2005, 03:35 PM
How about redirecting stderr and stdout to /dev/null ?

That's how I do it, I didn't even know about the trick you try to use.

---

ajp                05-22-2005, 04:45 PM
why have the mailto variable set at all. remove or comment it out and see what happens.


---




cpragman         05-22-2005, 07:04 PM
ajp,

There is no "MAILTO=" parameter set by default in the system's crontab file, you have to add it manually. According to "man 5 crontab", cron automatically generates a mail message to the user spawning the job. That means that on my system, I can count on a couple of root jobs a day, plus numerous user jobs per day. Adds up quickly.

If the MAILTO= parameter is provided with a username , the mail goes to that user. If the "MAILTO=" is provided with no user name, then no mail is generated (i.e., black hole).

The REAL problem I'm having is that the system's crontab (i.e., /etc/crontab) accepts the "MAILTO=" variable, yet for some reason my user's crontab filed (edited with "crontab -e") refuse to accept any file I provide that has "MAILTO=" in it.

---

cpragman    05-23-2005, 07:15 AM
I solved this one last night.

The correct syntax to add to the crontab file is as follows:

MAILTO=""

My problem was that I left out the empty quotes. Once I fixed that, no new messages were added to /var/spool/postfix/maildrop.