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

這段時間也沒更新代碼，本地測試也是OK的。但是部署到服務器上就出問題了。因為服務器是租用淘寶聚石塔的，難道是因為防火墻的問題？但是也就僅僅只有這個頁面存在問題，其他都是正常的。

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

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

Google /var/spool/clientmqueue 這個文件夾占用過大的原因發現是

系統中有用戶開啟了cron，而cron中執行的程序有輸出內容，輸出內容會以郵件形式發給cron的用戶，而sendmail沒有啟動所以就產生了這些文件。

好吧，果斷刪除 /var/spool/clientmqueue 文件夾下的所有內容。重新測試，發現 bug 消失了。

然后去 /etc/cron* 看看有什么樣的定時任務，發現有很多，應該是創建聚石塔服務器創建的，也不好修改。那么就只能采取迂回戰術了。在 /etc/cron.daily 下新建文件 rmclientmqueue：

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

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