Linux系统中的crontab与sendmail

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/mail
lrwxrwxrwx 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 -h
Filesystem 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% /opt
none 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 -i
Filesystem 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% /opt
none 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 Crf *（好强大的命令啊！）。咦，这时你会发现报错了。
[root@eall70 clientmqueue]# rm -rf *
-bash: /bin/rm: Argument list too long
　　文件太多，这个命令都不好使了。好吧退到它的上级目录，执行rm Crf clientmqueue 。啊，终于成功了！问题全部解决了，现在sendmail已经停止了， crontab无法往clientmqueue里填充文件了，真的如此吗？
让我们来看下面例子，证实是否真的如想象中的那样。
[root@yzhq var]# crontab -l
0 1 * * * /home/oracle/dbbackup
6 0 1,15 * * /home/oracle/filebackupall
[root@yzhq var]# cat /home/oracle/filebackupall
#!/bin/bash
rq=` 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.js
tar: Unexpected EOF in archive
tar: Error is not recoverable: exiting now
[root@yzhq root]#
上面的命令是查看该备份文件里有哪些内容。很显然，从上面的错误提示可以得知它异常地终止了。
发生这种现象时，也着实让我大吃一惊。我赶快抓紧时间，把所有的系统全都检测了一遍，出现了此问题的，立刻手动运行了一遍，并从系统中取出备份。
为什么会出现这种现象呢？其他的定时运行脚本都没有这个异常的现象，如数据库的逻辑导出日志，文件的增量备份都没出现此问题。后来我才发现问题发生在脚本 输出的信息量的大小上。如果定时脚本输出的信息量大，它就会运行运行一会后，信息量达到某一值时，脚本就会停止，而信息量小时就不会出现这种问题。这也就 是其它备份不出现问题，而单就大目录的全备出现问题的原因。当sendmail关闭时，并且/var/spool/clientmqueue/也被删除的 情况下，crontab这时就不能处理这么大的数据输出，它只是运行了一下，然后自己就把该脚本给停止了，从而产生只有几十K的毫无用途的文件。
注意，如果你在系统内卸载了sendmail，会直接造成上面的情况。
难道，如果我们做了上面的操作，除了重新安装sendmail，或恢复/var/spool/clientmqueue/目录，就没有办法解决这种问题了吗？
答案当然不是这样的，计算机就是这么神秘和灵活多变，我们还有其他方法。这时我们只需在问题出现的地方，进行加以解决。它不是一遇到大量的数据信息数据就开始不正常吗？那好我们让就让它一个数据也产生不了，就可以解决这个问题了。按照如下设置：
[root@yzhq var]# crontab -l
0 1 * * * /home/oracle/dbbackup
6 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 sendmail
sendmail-doc-8.12.11-4.RHEL3.6
sendmail-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.6
error: Failed dependencies:
/usr/sbin/sendmail is needed by (installed) redhat-lsb-1.3-3.1.EL3
smtpdaemon 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.6
warning: /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 db42a60e
Preparing... ########################################### [100%]
1:sendmail ########################################### [100%]
[root@yzhq root]# rpm -ivh redhat-lsb-1.3-3.1.EL3.i386.rpm
warning: redhat-lsb-1.3-3.1.EL3.i386.rpm: V3 DSA signature: NOKEY, key ID db42a60e
Preparing... ########################################### [100%]
1:redhat-lsb ########################################### [100%]
[root@yzhq root]# rpm -ivh mdadm-1.5.0-9.1.i386.rpm
warning: mdadm-1.5.0-9.1.i386.rpm: V3 DSA signature: NOKEY, key ID db42a60e
Preparing... ########################################### [100%]
1:mdadm ########################################### [100%]
4) crontab 与 sendmail的相关启动信息启动。
[root@yzhq root]# service crond status
crond (pid 1876) is running...
[root@yzhq root]# service crond stop
Stopping crond: [ OK ]
[root@yzhq root]# service crond start
Starting crond: [ OK ]
[root@yzhq root]# service crond restart
Stopping crond: [ OK ]
Starting crond: [ OK ]
[root@yzhq root]# service sendmail status
sendmail (pid 31924 31915) is running...
[root@yzhq root]# service sendmail stop
Shutting down sendmail: [ OK ]
Shutting down sm-client: [ OK ]
[root@yzhq root]# service sendmail start
Starting sendmail: [ OK ]
Starting sm-client: [ OK ]
[root@yzhq root]# service sendmail restart
Shutting down sendmail: [ OK ]
Shutting down sm-client: [ OK ]
Starting sendmail: [ OK ]
Starting sm-client: [ OK ]
5) 测试sendmail
[root@yzhq root]# cat /etc/sysconfig/sendmail
DAEMON=yes
QUEUE=1h
[root@yzhq mail]# mail root
Subject: yuzhiqiang
Hello,World!
Cc:
[root@yzhq mail]# mail -u root
Mail 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 2007
Date: Fri, 19 Oct 2007 10:52:23 +0800
From: root
To: root@yzhq.tjhouse.com
Subject: yuzhiqiang
Hello,World!
&
At EOF
& q
Saved 1 message in mbox
[root@yzhq mail]#
这时就证明你装好了。
6) /var/spool/clientmqueue/ 删除后，发邮件的报错现象
[root@eall25 root]# mail root
Subject: pppp
haha
Cc:
[root@eall25 root]# can not chdir(/var/spool/clientmqueue/): No such file or directory
7) 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/dbbackup
cron 是每分钟检测一次系统，是否有任务要执行。以下是其他的例子
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号。