crontab和/var/spool/clientmqueue的问题

一个朋友向我咨询他遇到的一个问题。

Centos的操作系统， 自然是主流应用的WWW。 近期无缘无故的Cron失效， 所有的任务都无法执行。 多次重启主机， 重启Cron服务均是如此。 起先我由于没有拿到控制台， 怀疑是Cron经典的环境变量问题， 修改了半天也是白忙。 总算此兄开恩，将root的权限给了我。:)

登入主机，crontab -l，所有命令都正常，单独执行也都OK。跑到/var/spool/cron下也没有发现有什么文件权限之类的问题。 每天都被cron mail挤爆信箱的我觉的从邮件入手吧。 谁知那位兄弟没有配置邮件系统， 而且直接disable了sendmail服务。

这里需要说明的是，Crontab 默认会将定时执行的结果通过mail返回给用户。 如果没有启动Sendmail服务， 系统（确切的应该是sendmail程序）将会把每一个结果保存为一个文件，放置在/var/spool/clientmqueue下。

cd /var/spool/clientmqueue 呵呵，果然！等了半个多小时愣是没有给list出来。du -sh 也是个费时费力的操作了。 mv * 太慢，直接 ls | xargs rm 操作，清空了所有的文件，重试了一下，搞定！

解决此类方法的建议：
开启sendmail服务，这是最佳途径。
每条命令使用 ‘>>’  指向一个日志文件，如果觉得返回没有必要，就直接  >/dev/null 2>&1 丢弃掉。
更加变态的方式就是再加一条cron，定期清空 /var/spool/clientmqueue

PS：之前没有弄过，完成测试的时候才理清的一个Cron问题：
30 3 * * 1 dosomething ,是每周一3点半执行是确信无疑的了。
30 3 1 * 1 dosomething, 是当1号是周一的时候执行吗？不是！是1号，或者周一的时候执行。crontab中的星期是一个“或”的概念，而非其他的“和”的概念。

转自：

 

/var/spool/clientmqueue/目录的作用： 当你使用简单的sendmail发邮件的时候， 或者系统默认要发一些邮件（比如cron发的邮件）的时候，首先会把邮件拷贝到这个目录里，然后等待MTA(mail transfer agent) 来处理，MTA做的事情通常是把这个目录中的邮件弄到/var/spool/mqueue里，然后再发送到真正的目的地。出现/var/spool/clientmqueue/非常大的情况通常因为没有合适的MTA发送邮件，就都积累在这里了，假如这里的邮件并不是你需要的，比如是系统默认发的每分钟跑一次的什么什么cron的信，你可以简单的删掉他们。当然，文件多了一些，直接rm -f *，系统可能会说argument too long什么的，没有关系，find /var/spool/clientmqueue/ -type f –delete或者find /var/spool/clientmqueue/ -type f -exec rm {} \+可能对你有帮助，当然这两条命令要求find的版本比较新。如果不幸你的版本比较低，可以尝试find /var/spool/clientmqueue/ -type f -exec rm {} \;

 

看下一个台湾朋友的经历：
在一個風和日麗的夜晚，我坐在家裡看著電視，後來手機一陣響起，結果是楊老師發現一台主機發生異常，伺服器的 /var/spool/mqueue 目錄被塞了一堆還沒有寄出的信件， 而當時沒有把 /var/spool 另外分割出來，所以也影響到了系統 root (/) 區塊，只剩六百多 MB 可以使用，這時一想會有幾個可能.
1. 這台 server 有幫學校的 PC 做寄送信件，所以可能是廣告信在寄出.
2. 使用這台 server 做 mail 寄信的機器，可能是中毒，於是就不斷的送信出去.
一開始只有想到這兩個原因，但是可要把被吞掉的空間給吐出來，所以就打算把所有的 mail queue 都先砍了，當然，要先停掉 mail service.

在砍這些正在排隊的信件時，發現一件事，就是裡面的檔案太多了，使用 ls 命令就變得超級遲頓，沒有反應，使用 mailq 來看看到底是那些信被 queue 住也沒辦法，後來想想算了，只好全剖砍了，不要再玩下去，之後，很順手的下了 rm -rf * 這下子呢，發生了一件很離奇的事，居然檔案太多無法刪除，第一次聽到 rm 在 complain (我是聽到的，楊老師是實作者，所以他有看到 ^^).
那個 error 是: bash: /bin/rm: Argument list too long
雖然無法刪除，但是楊兄並不放棄，到主機面前，開啟了 X Window 之後使用那 Linuxer 最常使用的鸚鵡螺 (nautilus) 開啟到 /var/spool/mqueue. 喔 ~ 可以使用 X Window 來刪呢 ! 後來想說即然 X Window 有這麼大的本事，那麼就用它來刪了其它的 queue files 就好啦，於是掛上電話，放楊兄一個人努力的在機房刪著 ...
當然我也沒有閒著，電視劇剛好演完，於是開啟我的工作伙伴，再度當網路潛水艇 ... 游著游著，突然想到，何不使用 find 來刪除看看 ? 於是刪回歷史文件，發現一個命令就是 find ./ | xargs rm -rf 千萬別小看這小小的指令，因為在我看完之後不久，楊兄打進來，說已經刪到手軟，這時也是晚上十點了，於是我就推薦了這個這道指令，嗯，很好，全都刪了，還頗快的 ...

喔，還沒說為什麼會刪到手軟，是因為 nautilus 在 Load 目錄時，是分批的，不是一次全部讀，所以一次大約是幾千封在讀，刪了之後，沒想到又冒出了還有幾千封 ... 真是嚇死人，後來推論應該是分批的關係.
在下了 find ./ | xargs rm -rf 之後，還在訝異快速之餘，就發現時間不多了，學校也要關門，所以就先 say bye bye，在現場苦命的楊兄也回家休息了.

分析:
rm 有最大一次刪除的數量，所以當一個目錄裡有太多的檔案或目錄時，就會出現錯誤，小弟試過應該是在二萬以下，而使用 find ./ | xargs rm -rf 的目的是先使用 find 列出檔案，再導向到 xargs，xargs 再喂給 rm，在這裡，xargs 會分批依照 rm 的最大數量餵給 rm，然後就可以順利刪除檔案了。

 

这里为什么ls会比find慢很多？？？  为什么呢？ 记得去刨根问底一下：
自己的经历：
    几个用户的crontab中的脚本都没有重定向， 所以导致/var/spool/clientmqueue目录中的文件过多， 把所在文件系统的inode都用光了。 使用ls | xargs rm -rf删， 删了半天， 用ps发现还没有ls完。 使用find ./ -name "*" -type f | xargs rm -rf， 用ps可以看到， 很快进程列表中就有rm xxx的进程实例在运行了