crontab致使磁盤空間滿問題的解決

收到磁盤空間滿的信息。發現主機上/var空間不足。du -sh 一層層的查下去看的時候，最終找到了/var/spool/clientmqueue這個目錄。裏面文件有48w個，娘阿。這個問題的緣由是crontab的一些計劃任務中產生了大量日誌信息。這些日誌信息沒有導入到/dev/null或者指定的文件。結果就產生了目錄下的這些文件。原本這些文件要做爲mail發出去的。結果sendmail沒有啓動，積留在這裏了。建議crontab的計劃任務所有寫成這個樣子：
30 7 * * * /home/mysql/admin/bin/sec.startup restart >/dev/null 2>&1
請注意後面的>/dev/null 2>&1。這裏2>&1表示標準錯誤也放到標準輸出，而標準輸出導入到了/dev/null；也就是說，日誌信息我不要了。若是你要的話，導入到你指定的文件咯。
這裏還有一個注意的地方就是>/dev/null 2>&1的順序。他們的順序也不能反。不然標準錯誤不能導入到標準輸出。仍是要寫到/var/spool/clientmqueue文件中。
咱們能夠看看spool和clientmqueue的linux幫助：
man hier
spool/ miscellaneous printer and mail system spooling
directories

clientmqueue/
undelivered submission mail queue; see
sendmail(8)

原理搞清楚了，之後的問題也避免了。那麼就是已有的文件刪除問題了。注意，不要這樣刪除rm -rf /var/spool/clientmqueue，這個文件夾仍是蠻重要的，據說過刪除該文件夾系統出問題的事例了，但願你不是下一個形成一樣的故障的人。
刪除文件原本很簡單，可是刪除48w個文件就是一個有技術含量的活了。直接rm *會報錯說Argument list too long。rm接收的參數列太多了。咱們就不追究這麼通用的工具怎麼會出這麼使人不爽報錯了吧。簡單的解決辦法：
a、利用xargs。xargs其實就是把傳給它的列表一個一個的傳給它的命令去一個一個的執行。具體的命令爲ls |xargs rm -f。
b、利用find -delete。具體命令爲find /var/spool/clientmqueue/ -type f -delete