系統磁盤優化——"/var/spool/postfix/maildrop"
阿新 • • 發佈:2018-10-26
ogre 郵件發送 表示 機制 pan bin 自動清理 why 註意
文件清理
最近某服務器磁盤空間告警,在排查過程中發現"/var/spool/postfix/maildrop"目錄下堆積了很多小文件,起初想直接刪除,但是使用rm刪除是提示“參數列表過長”,後來使用rsync來清楚垃圾文件:
# 創建一個臨時空文件夾 mkdir /tmp/blankdir # 清理/var/spool/postfix/maildrop rsync -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"