转自：
固定链接：http://ye6789.bokee.com/6529331.html
谈到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 –rf *（好强大的命令啊！）。咦，这时你会发现报错了。 [root@eall70 clientmqueue]# rm -rf * -bash: /bin/rm: Argument list too long 文件太多，这个命令都不好使了。好吧退到它的上级目录，执行rm –rf 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 use. Fri Oct 19 10:52 16/703 "yuzhiqiang" & Message 1: From Fri Oct 19 10:52:23 2007 Date: Fri, 19 Oct 2007 10:52:23 +0800 From: root <root@yzhq.tjhouse.com> To: 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号。