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

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

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

果斷用 df -lh 查看磁盤占用情況，發(fā)現(xià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* 看看有什么樣的定時任務，發(fā)現(xiàn)有很多，應該是創(chuàng)建聚石塔服務器創(chuàng)建的，也不好修改。那么就只能采取迂回戰(zhàn)術了。在 /etc/cron.daily 下新建文件 rmclientmqueue：

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

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

版權聲明：本站文章來源標注為YINGSOO的內(nèi)容版權均為本站所有，歡迎引用、轉載，請保持原文完整并注明來源及原文鏈接。禁止復制或仿造本網(wǎng)站，禁止在非maisonbaluchon.cn所屬的服務器上建立鏡像，否則將依法追究法律責任。本站部分內(nèi)容來源于網(wǎng)友推薦、互聯(lián)網(wǎng)收集整理而來，僅供學習參考，不代表本站立場，如有內(nèi)容涉嫌侵權，請聯(lián)系alex-e#qq.com處理。