登錄到主機發現服務器上有近40個名稱爲[sh] <defunct>的進程
Ps –ef 帶進程號查 發現是殭屍進程是
發送郵件的/usr/sbin/sendmail -FCronDaemon -i -odi -oem -oi -t進程
殺掉這些殭屍進程
kill -9 `ps -ef|grep def|awk '{print $3}'`
後進行分析如下：
首先查到/var/mail下的root文件將近57G，這是異常的。
後聯想到cron，發現root下有cron任務
[root@server mail]# ll -h
total 57G
-rw------- 1 root root 57G Apr 13 04:02 root
[root@server mail]# crontab -l
50 23 * * * /sbin/ hwclock --directisa --hctosys
0 5 * * * /starnet/dbbak/dbbak.sh
0 6 8,15,22,30 * * /dmbstart_all
40 11 * * * /dmbstart_all
[root@server mail]#
照成這些現象的原因是crontab中的程序執行，導致輸出大量信息到標準設備上，輸出的信息又觸發了系統的sendmail，把信息當作郵件發給root用戶。上述截圖裏可以發現root這個用戶的mail文件已有57G之大，說明輸出的信息量大。
crontab 計劃內容中定義命令如果有輸出信息的話，會調用sendmail把輸出信息發到/var/mail文件中，所以如果有大量輸出信息，將會造成殭屍進程(defunct)；這時候應該在定義的命令後邊加上 "> /dev/null 2>&1"
解決辦法: 把cron任務的輸出定向到空設備上
即將crontab裏面的每行命令後面加上 > /dev/null 2>&1
並及時清理原root的mail文件。
==============================================================================================
系統默認要發一些郵件（比如cron發的郵件）的時候，首先會把郵件拷貝到這個目錄裏，然後等待MTA(mail transfer agent) 來處理，MTA做的事情通常是把這個目錄中的郵件弄到/var/spool/mqueue裏，然後再發送到真正的目的地。出現/var/spool/clientmqueue/非常大的情況通常因爲沒有合適的MTA發送郵件，就都積累在這裏了，假如這裏的郵件並不是你需要的，比如是系統默認發的每分鐘跑一次的什麼什麼cron的信，你可以簡單的刪掉他們。當然，文件多了一些，直接rm -f *，系統可能會說argument too long什麼的，沒有關係，find /var/spool/clientmqueue/ -type f –delete或者find /var/spool/clientmqueue/ -type f -exec rm {} \+可能對你有幫助，當然這兩條命令要求find的版本比較新。如果不幸你的版本比較低，可以嘗試find /var/spool/clientmqueue/ -type f -exec rm {} \;
原因分析：系統中有用戶開啓了cron，而cron中執行的程序有輸出內容，輸出內容會以郵件形式發給cron的用戶，而sendmail沒有啓動所以就產生了這些文件；
解決辦法:
1、 將crontab裏面的命令後面加上> /dev/null 2>&1
2、 知識點：
2>：重定向錯誤。
2>&1：把錯誤重定向到輸出要送到的地方。即把上述命令的執行結果重定向到/dev/null，即拋棄，同時，把產生的錯誤也拋棄。
使用du -sh * 或 du -sh /* 查看目錄的大小，查找佔用空間大的目錄
注：/是系統目錄，可以cd到當前目錄下執行du -sh *