gojira.net

刚刚登录上服务器,查看到 /var 分区已达 90%，日志是定期分析处理的，怎么会占这么大的空间？
查看日志文件夹/var/log 大小没问题，只有两百多M，那到底是什么文件占用了大量空间了？

继续找，发现：
du -sh /var/spool/clientmqueue/
13G /var/spool/clientmqueue

找到/var/spool/clientmqueue/ 目录占了大量空间，罪魁祸首就是它了。

这个目录底下的文件到底是干什么的？

分析：
当使用简单的sendmail发邮件的时候，或者系统默认要发一些邮件（比如cron发的邮件）的时候，首先会把邮件拷贝到这个目录里，然后等待MTA(mail transfer agent) 来处理，MTA做的事情通常是把这个目录中的邮件弄到/var/spool/mqueue里，然后再发送到真正的目的地。出现/var/spool/clientmqueue/非常大的情况通常因为没有合适的MTA发送邮件（例如sendmail没有启动，或者是挂掉了），就都积累在这里了。

如果这些的邮件并不是你需要的，比如是系统默认发的每分钟跑一次的什么什么cron的信，你可以简单的rm -f /var/spool/clientmqueue/*删掉他们。
当然，文件多了一些，直接rm系统可能会提示-bash: /bin/rm: Argument list 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 {} \;
不过还是推荐用如下方法：
cd /var/spool/clientmqueue
ls | xargs rm -f

好了，原因就是这个了。

/var/spool/clientmqueue目录占大量空间的根本解决办法:
将crontab里面的命令后面加上 > /dev/null 2>&1
注：2>&1：把错误重定向到输出要送到的地方。即把上述命令的执行结果重定向到/dev/null，即抛弃，同时，把产生的错误也抛弃。

删除/var/spool/clientmqueue这个目录里面所有的文件就行了。
重新修改所有的cron 加上 > /dev/null 2>&1
这样的话就解决了/var/spool/clientmqueue占用空间的问题 。

另外为了保险起见 /var/spool/mqueue/里面的文件也干掉吧，如果文件过多，按上面的方法再来一遍。