这里是普通文章模块栏目内容页
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 <root@yzhq.tjhouse.com>
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号。