Chinaunix首页 | 论坛 | 博客
  • 博客访问: 1735824
  • 博文数量: 220
  • 博客积分: 8531
  • 博客等级: 中将
  • 技术积分: 4971
  • 用 户 组: 普通用户
  • 注册时间: 2007-07-18 13:33
文章分类

全部博文(220)

文章存档

2017年(1)

2015年(1)

2014年(5)

2013年(6)

2012年(6)

2011年(30)

2010年(37)

2009年(53)

2008年(41)

2007年(40)

分类: LINUX

2008-08-28 19:17:03

____今天在客户那遇到一个典型问题,有两台机器也是/分区占用的比较多,最后定位在/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.

阅读(1691) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~