前段時間公司的一個項目出現(xiàn)了一個 bug，使用 ajax 上傳大文件時會出現(xiàn)網(wǎng)絡(luò)問題。使用 chrome 開發(fā)者工具查看網(wǎng)絡(luò)請求時，發(fā)現(xiàn)錯誤是 ERR_CONNECTION_RESET 。看到這個錯誤就想到訪問 Google 出現(xiàn)的情況， 哈哈。然后用 IE 的開發(fā)人員工具查看網(wǎng)絡(luò)請求，顯示的錯誤碼是 403。

這段時間也沒更新代碼，本地測試也是OK的。但是部署到服務(wù)器上就出問題了。因?yàn)榉?wù)器是租用淘寶聚石塔的，難道是因?yàn)榉阑饓Φ膯栴}？但是也就僅僅只有這個頁面存在問題，其他都是正常的。

服務(wù)器上安裝了 nginx 和 tomcat ，查看 nginx 的訪問日志，發(fā)現(xiàn)記錄太多，放棄。查看錯誤記錄發(fā)現(xiàn)提示磁盤空間不足，日志無法寫入。

果斷用 df -lh 查看磁盤占用情況，發(fā)現(xiàn)掛載點(diǎn) / 已滿。切換到根目錄，運(yùn)行 du -sh * 查看各文件夾大小，發(fā)現(xiàn) var 占用了30多G，繼續(xù) du -sh /var/* 最終找到文件夾 /var/spool/clientmqueue 占用30多G。

Google /var/spool/clientmqueue 這個文件夾占用過大的原因發(fā)現(xiàn)是

系統(tǒng)中有用戶開啟了cron，而cron中執(zhí)行的程序有輸出內(nèi)容，輸出內(nèi)容會以郵件形式發(fā)給cron的用戶，而sendmail沒有啟動所以就產(chǎn)生了這些文件。

好吧，果斷刪除 /var/spool/clientmqueue 文件夾下的所有內(nèi)容。重新測試，發(fā)現(xiàn) bug 消失了。

然后去 /etc/cron* 看看有什么樣的定時任務(wù)，發(fā)現(xiàn)有很多，應(yīng)該是創(chuàng)建聚石塔服務(wù)器創(chuàng)建的，也不好修改。那么就只能采取迂回戰(zhàn)術(shù)了。在 /etc/cron.daily 下新建文件 rmclientmqueue：

#!/bin/sh
rm -rf /var/spool/clientmqueue/*
chmod u+x rmclientmqueue

這樣就完美的解決了問題。