3.24下午接到客戶反饋，系統出現了大量的sendmail及postdrop進程，導緻系統崩潰。需要協助排查。具體故障截圖及處理過程如下。

客戶提供的截圖：

可以看到系統産生了大量的sendmail及postdrop進程，1分鐘産生一個。

通過查看對應進程的父進程确定是crond導緻的

應急措施 停止crond

service stop crond

殺掉sendmail及postdrop進程

ps -ef|grep "/usr/sbin/sendmail"|grep -v grep |awk '{print $2}'|xargs kill ps -ef|grep "/usr/sbin/postdrop"|grep -v grep |awk '{print $2}'|xargs kill

同時客戶反饋上午的時候發現/var目錄滿了 然後重啟了主機 把postfix服務給停止了。通過網上查看crond 導緻大量的sendmail進程有相關的案例.

聯系客戶查看crontab是否配置定時任務。結果如下

系統中存在兩個定時任務，一個是用于nginx日志切割的，一個是用于華三虛拟化agent檢測的。注意上圖的/etc/crontab裡面的mail="root"。

按照網上的解決方案，我先把日志切割的任務添加一下日志輸出重定向。

然而添加的時候出現設備上面沒有空間的報錯。

查看文件系統使用率正常

聯想到大量的sendmail可能會産生很多小文件，查看i節點信息，果然i節點滿了

處理i節點問題

cd /var/spool/postfix/maildrop ls | xargs -n 1000 rm -rf //要批量删，一次1000個，直接rm可能删不成功

再次查看恢複正常

再次修改contab腳本，正常修改。

啟動crond服務。經過十幾分鐘的觀察sendmail服務未啟動。

總結：

所以根本的原因還是postfix服務被禁用了導緻的。

解決這個問題有兩個辦法：

在crontab末尾加上 >/dev/null 2>&1. 或&> /dev/null 例如*/10 * * * * /home/a.sh >/dev/null 2>&1 另外一種方法是crontab第一行加入,那麼後面執行的crontab腳本就不會發送mail了 MAILTO=""

man 5 contab查看crontab幫助

In addition to LOGNAME, HOME, and SHELL, cron(8) looks at the MAILTO variable if a mail needs to be send as a result of running any commands in that particular crontab. If MAILTO is defined (and non-empty), mail is sent to the specified address. If MAILTO is defined but empty (MAILTO=""), no mail is sent. Otherwise, mail is sent to the owner of the crontab. This option is useful if you decide to use /bin/mail instead of /usr/lib/sendmail as your mailer. Note that /bin/mail does not provide aliasing and UUCP usually does not read its mail. If MAILFROM is defined (and non-empty), it is used as the envelope sender address, otherwise, ``root'' is used。

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!