crontab与sendmail的特殊关系Linux系统作为免费开放的高效系统平台，已被众多企业所欣然接受。大量的企业级应用都跑在其上，Dell 公司也开始销售基于Linux系统的个人电脑。数据库软件的巨擎Oracle的新产品在众多系统平台的选择中，也选择了Linux作为Oracle 11g数据库的首发平台。大量事实证明，企鹅正在向我们走的越来越近。谈到Linux系统管理方面，不得不提到crontab与sendmail。 crontab是维护系统定时运行服务的守护程序，可以利用它来定时执行一些脚本任务；sendmail是mail服务的守护进程程序，可以利用它来向用户发关于管理信息邮件。这篇文章重点描述他们之间的关系以及一些基本的使用方法。本文是基于Red Hat Enterprise Linux AS release 3 (Taroon Update 8)平台撰写，相关信息都是基于此平台测试。笔者因在日常管理中，发现crontab与sendmail存在一种关系值得我们大家注意，所以才有了写这篇文章的冲动，下面直接开门见山。crontab定时运行的任务，会利用sendmail定时发给用户邮件。如果，sendmail正常开启，或者sendmail在关闭状态下而且其必要文件没有被修改。那么crontab会很好的运行，否则的话会系统运行的脚本出现意象不到的结果。 默认情况下，sendmail会被开启。它会接收到所有来自crontab的执行信息，并传给root用户（如果你使用的全是root用户运行脚本的话），如下所示的位置：[root@yzhq var]# ll /var/maillrwxrwxrwx 1 root root 10 Apr 19 2007 /var/mail -> spool/mail这时你也可以看到/var/mail实际指向的是/var/spool/mail。还有的就是系统对于软连接，进行ll 操作时，显示的是文件链接的属性，而不是文件夹里的内容。硬链接只能指向文件而不能是文件夹（关于为什么可以查看磁盘存储i索引节点方面的知识）。要想查看文件夹的属性需加ls -ld 的选项。作为一个生产系统，这个文件夹下的root文件每天都会有增长，作为一名管理员，要定期检查这里来防止它异常的庞大造成系统故障。如果该文件过于庞大，可以使用如下命令将其清零，如：[root@yzhq mail]# cat /dev/null > /var/spool/mail/root 我们为什么要天天清理这个东西呢？太麻烦了，把sendmail关掉后，不就发不了邮件了吗！那时我们就不需要做那个无聊的事了。要知道关掉sendmail后，crontab默认定时执行和后来由于管理需要添加进去的脚本，运行时产生的输出这时就会发往/var/spool /clientmqueue/。而定时输出的信息都是小文件，它会逐渐占据这个/var分区，从而导致该分区虽然(用df -h 查看)还有很多剩余空间。但是，已经不能在这里创建任何文件了。造成此问题的原因是小文件耗尽了/var分区的所有i索引节点，一些应用程序这时也会报错。查看索引节点的使用情况可通过df -i。[root@yzhq var]# df -hFilesystem Size Used Avail Use% Mounted on/dev/sda3 9.7G 233M 8.9G 3% //dev/sda1 99M 15M 79M 16% /boot/dev/sda2 29G 6.2G 22G 23% /home/dev/sda11 71G 23G 45G 34% /optnone 1004M 0 1004M 0% /dev/shm/dev/sda7 2.0G 33M 1.8G 2% /tmp/dev/sda6 9.7G 1.8G 7.4G 20% /usr/dev/sda5 9.7G 948M 8.2G 11% /usr/local/dev/sda10 981M 579M 352M 63% /var[root@yzhq var]# df -iFilesystem Inodes IUsed IFree IUse% Mounted on/dev/sda3 1281696 26206 1255490 3% //dev/sda1 26104 40 26064 1% /boot/dev/sda2 3842720 7324 3835396 1% /home/dev/sda11 9338880 86204 9252676 1% /optnone 256918 1 256917 1% /dev/shm/dev/sda7 256512 78 256434 1% /tmp/dev/sda6 1281696 78282 1203414 7% /usr/dev/sda5 1281696 14543 1267153 2% /usr/local/dev/sda10 127744 127744 0 100% /var 那好，来解决这个问题，删除那些文件。进入/var/spool/clientmqueue/，执行rm –rf *（好强大的命令啊！）。咦，这时你会发现报错了。[root@eall70 clientmqueue]# rm -rf *-bash: /bin/rm: Argument list too long 文件太多，这个命令都不好使了。好吧退到它的上级目录，执行rm –rf clientmqueue 。啊，终于成功了！问题全部解决了，现在sendmail已经停止了， crontab无法往clientmqueue里填充文件了，真的如此吗？让我们来看下面例子，证实是否真的如想象中的那样。[root@yzhq var]# crontab -l0 1 * * * /home/oracle/dbbackup6 0 1,15 * * /home/oracle/filebackupall[root@yzhq var]# cat /home/oracle/filebackupall#!/bin/bashrq=` date +"%Y%m%d" `tar -zcvf - /home/becvx| split -b 1000m - /opt/backup/promkall$rq.tar.gz.上面的这个是对一个目录进行tar备份操作，它做的是对/home/becvx目录及其里边的文件就行打包压缩，并限制每个备份文件大小为1000m存放在/opt/backup/下，它的名字也会根据日期的不同作相应的变化。这个脚本在备份的时候，如果手动运行的话，你会看到在前台会输出大量的备份信息。信息量的大小是跟该目录的文件多少有关的，文件越多，输出的信息量越大；文件越少，输出的信息量就越少。然而，问题又出现了。当手动备份出的文件足有上百M时，而通过crontab自动运行的这个脚本产生的文件才几十KB。天啊，那个目录根本不可能那么小，这个自动运行的任务肯定出问题了。以前还能很好的运行，而且其他的脚本现在也正常啊，问题到底在哪里呢？其实问题就发生在crontab在规定的时刻运行脚本时，还没等脚本运行完它就停止了。下面是对备份文件的检验：[root@yzhq root]# tar tzvf promkall20071019.tar.gz.aa---------- 省略部分 ---------- -rw-r--r-- promkftp/promkftp 10707 2006-07-20 11:56:51 home/promk/html/js/autoComplete.jstar: Unexpected EOF in archivetar: Error is not recoverable: exiting now[root@yzhq root]#上面的命令是查看该备份文件里有哪些内容。很显然，从上面的错误提示可以得知它异常地终止了。发生这种现象时，也着实让我大吃一惊。我赶快抓紧时间，把所有的系统全都检测了一遍，出现了此问题的，立刻手动运行了一遍，并从系统中取出备份。为什么会出现这种现象呢？其他的定时运行脚本都没有这个异常的现象，如数据库的逻辑导出日志，文件的增量备份都没出现此问题。后来我才发现问题发生在脚本输出的信息量的大小上。如果定时脚本输出的信息量大，它就会运行运行一会后，信息量达到某一值时，脚本就会停止，而信息量小时就不会出现这种问题。这也就是其它备份不出现问题，而单就大目录的全备出现问题的原因。当sendmail关闭时，并且/var/spool/clientmqueue/也被删除的情况下，crontab这时就不能处理这么大的数据输出，它只是运行了一下，然后自己就把该脚本给停止了，从而产生只有几十K的毫无用途的文件。注意，如果你在系统内卸载了sendmail，会直接造成上面的情况。难道，如果我们做了上面的操作，除了重新安装sendmail，或恢复/var/spool/clientmqueue/目录，就没有办法解决这种问题了吗？答案当然不是这样的，计算机就是这么神秘和灵活多变，我们还有其他方法。这时我们只需在问题出现的地方，进行加以解决。它不是一遇到大量的数据信息数据就开始不正常吗？那好我们让就让它一个数据也产生不了，就可以解决这个问题了。按照如下设置：[root@yzhq var]# crontab -l0 1 * * * /home/oracle/dbbackup6 0 1,15 * * /home/oracle/filebackupall > /dev/null 2>&1上面的意思是将脚本的标准输出和错误输出指向了/dev/null，实际上就是不会产生任何输出。当然你也可以将它追加到特定的文件，保留信息以备日后查看。这样问题到此就彻底解决了，希望我的描述，能让你更进一步了解crontab 与 sendmail两者之间的关系。下面列出一些其他相关信息，供您参考：1) 如果发现/var/spool/clientmqueue目录容量很大，你也可以开启sendmail，这样它里边的小文件就会自动跑到/var/spool/mail/root中去了，然后清理那个文件即可。2) 如果你删掉了/var/spool/clientmqueue目录，下面的演示如何删除并重建该目录。[root@yzhq spool]# ls -ld /var/spool/clientmqueue/drwxrwx--- 2 smmsp smmsp 3051520 Aug 28 16:24 clientmqueue[root@yzhq spool]# rm -rf clientmqueue/[root@yzhq spool]# mkdir clientmqueue[root@yzhq spool]# chown smmsp.smmsp clientmqueue/[root@yzhq spool]# chmod 770 clientmqueue/3) 如果你卸载了sendmail，下面演示如果卸载重新安装。[root@yzhq root]# rpm -qa |grep sendmailsendmail-doc-8.12.11-4.RHEL3.6sendmail-8.12.11-4.RHEL3.6[root@yzhq root]# rpm -e sendmail-doc-8.12.11-4.RHEL3.6[root@yzhq root]# rpm -e sendmail-8.12.11-4.RHEL3.6error: Failed dependencies:/usr/sbin/sendmail is needed by (installed) redhat-lsb-1.3-3.1.EL3smtpdaemon is needed by (installed) mdadm-1.5.0-9.1[root@yzhq root]# rpm -e mdadm-1.5.0-9.1[root@yzhq root]# rpm -e redhat-lsb-1.3-3.1.EL3[root@yzhq root]# rpm -e sendmail-8.12.11-4.RHEL3.6warning: /var/log/mail/statistics saved as /var/log/mail/statistics.rpmsave[root@yzhq root]# rpm -ivh sendmail-8.12.11-4.RHEL3.6.i386.rpm warning: sendmail-8.12.11-4.RHEL3.6.i386.rpm: V3 DSA signature: NOKEY, key ID db42a60ePreparing... ########################################### [100%]1:sendmail ########################################### [100%][root@yzhq root]# rpm -ivh redhat-lsb-1.3-3.1.EL3.i386.rpmwarning: redhat-lsb-1.3-3.1.EL3.i386.rpm: V3 DSA signature: NOKEY, key ID db42a60ePreparing... ########################################### [100%]1:redhat-lsb ########################################### [100%][root@yzhq root]# rpm -ivh mdadm-1.5.0-9.1.i386.rpmwarning: mdadm-1.5.0-9.1.i386.rpm: V3 DSA signature: NOKEY, key ID db42a60ePreparing... ########################################### [100%]1:mdadm ########################################### [100%]4) crontab 与 sendmail的相关启动信息启动。[root@yzhq root]# service crond statuscrond (pid 1876) is running...[root@yzhq root]# service crond stopStopping crond: [ OK ][root@yzhq root]# service crond startStarting crond: [ OK ][root@yzhq root]# service crond restartStopping crond: [ OK ]Starting crond: [ OK ][root@yzhq root]# service sendmail statussendmail (pid 31924 31915) is running...[root@yzhq root]# service sendmail stopShutting down sendmail: [ OK ]Shutting down sm-client: [ OK ][root@yzhq root]# service sendmail startStarting sendmail: [ OK ]Starting sm-client: [ OK ][root@yzhq root]# service sendmail restartShutting down sendmail: [ OK ]Shutting down sm-client: [ OK ]Starting sendmail: [ OK ]Starting sm-client: [ OK ]5) 测试sendmail[root@yzhq root]# cat /etc/sysconfig/sendmailDAEMON=yesQUEUE=1h[root@yzhq mail]# mail rootSubject: yuzhiqiangHello,World!Cc: [root@yzhq mail]# mail -u rootMail version 8.1 6/6/93. Type ? for help."/var/mail/root": 1 message 1 new>N 1 root@yzhq.tjhouse. Fri Oct 19 10:52 16/703 "yuzhiqiang"& Message 1:From root@yzhq.tjhouse.com Fri Oct 19 10:52:23 2007Date: Fri, 19 Oct 2007 10:52:23 +0800From: root <root@yzhq.tjhouse.com>To: root@yzhq.tjhouse.comSubject: yuzhiqiangHello,World!& At EOF& qSaved 1 message in mbox[root@yzhq mail]# 这时就证明你装好了。6) /var/spool/clientmqueue/ 删除后，发邮件的报错现象[root@eall25 root]# mail rootSubject: pppphaha Cc: [root@eall25 root]# can not chdir(/var/spool/clientmqueue/): No such file or directory7) crontab 的一些基本用法。crontab -u 设定某个用户的定时服务crontab -l 列出某个用户的定时服务的详细信息crontab -r 删除某个用户的定时服务crontab -e 编辑某个用户的定时服务0 1 * * * /home/oracle/dbbackup上面的信息的左侧5个部分分别代表为分钟 0-59小时 0-23天 1-31月 1-12星期 0-7 (0和7都可以表示为星期日，或者使用sun代表)参照上面的解释，那一行代表为每天一点钟的时候运行脚本/home/oracle/dbbackupcron 是每分钟检测一次系统，是否有任务要执行。以下是其他的例子0-23/2 在''0,2,4,6,8,10,12,14,16,18,20,22''的时间点内运行，或者说是每2个小时。也已可以用*/2表示。30 4 1,15 * 5 这个似乎看起来有些矛盾。它的要求是每月的1号，15号的4点30分运行脚本。并且如果一到星期5，也会在这一时刻运行，而不论是否是1号或者15号。
本文转自holy2009 51CTO博客，原文链接:http://blog.51cto.com/holy2010/353565
