系統磁碟最佳化——"/var/spool/postfix/maildrop"

標籤：dir   span   markdown   cront   提示   div   時間   郵件   gre   

檔案清理

最近某伺服器磁碟空間警示，在排查過程中發現"/var/spool/postfix/maildrop"目錄下堆積了很多小檔案，起初想直接刪除，但是使用rm刪除是提示“參數列表過長”，後來使用rsync來清楚垃圾檔案：

# 建立一個臨時空檔案夾mkdir /tmp/blankdir# 清理/var/spool/postfix/maildroprsync -av --delete /tmp/blankdir/  /var/spool/postfix/maildrop/# rsync選項說明：# --delete-before 接收者在傳輸之前進行刪除操作# --progress 在傳輸時顯示傳輸過程# --a 歸檔模式，表示以遞迴方式傳輸檔案，並保持所有檔案屬性# --H 保持硬串連的檔案# --v 詳細輸出模式# --stats 給出某些檔案的傳輸狀態

注意：

• 不管是使用rm還是rsync，在清理檔案之前一定要仔細確認檔案是否有用，避免誤操作。
• 使用rsync時空目錄的路徑後要帶上"/"

追根溯源

在清理完檔案後不久又有一次記憶體警示，檢測發現有大量的“CRON、sendmail、postdrop”進程，同時還發現“/var/spool/postfix/maildrop”又有大量檔案產生，Why？

於是開始排查，經過一番“海底撈”，真相終於浮出水面：

由於 Linux 在執行 cron 時，會將 cron 執行指令碼中的 output 和 warning 資訊，都會以郵件的形式發送 cron 所有者， 而由於客戶環境中的 sendmail 和 postfix 沒有正常運行，導致郵件發送不成功，全部小檔案堆積在了 maildrop 目錄下面，而且沒有自動清理轉換的機制，所以長達一年的時間，此目錄已堆積了大量的檔案。查看 man cron 的資訊，可以知道會發送給 cron owner。

既然定位到是cron惹的禍，那就先把“sendmail、postdrop”幹掉，解決燃眉之急，然後尋找解決方案吧，辦法如下：

• 將/etc/crontab檔案中MAILTO="root"改成MAILTO=""（該辦法只對crontab下的cron有效）；

• 在所有cron的第一行加入 MAILTO=""便可，這樣執行目前使用者的Cron時，就不會發送郵件了

  MAILTO=""* * * * * root /usr/sbin/python /tmp/test.py

之後再次清理“/var/spool/postfix/maildrop”下的垃圾檔案，觀察一下，沒有檔案再產生，問題解決！

系統磁碟最佳化——"/var/spool/postfix/maildrop"