Crontab導致Linux檔案描述符枯竭問題 問題 系統中的定時任務,過一段時間之後,不能運行。通過系統命令查看到系統有大量sendmail進程,導致檔案描述符耗盡。以下主要通過分析整個處理過程,供大家參考。處理過程 根據以上問題,分析步驟如下:1、首先手動執行了一下定時任務,結果執行失敗,通過錯誤判斷是檔案描述符被用光了。具體報錯如下:"cannot open shared object file: Too many open files in system"2、查看定時任務是否堆積,ps -ef | grep <TASK_NAME>沒有發現任何任務在跑。猜測應該是其他問題導致,具體是什麼,不清楚。3、通過系統命令top看到有多個sendmail進程,然後ps -ef | grep sendmail,發現大量進程。初步定位應該是sendmail的問題。首先將所有sendmail進程kill掉,然後定時任務可以執行了。一段時間後,重新查看進程,發現又有了一些sendmail進程,進一步定位問題。/usr/sbin/sendmail -FCronDaemon -i -odi -oem -oi -t -f root4、通過pstree發現,sendmail進程是有crond守護進程啟動的。crontab怎麼會啟動sendmail進程?原來crond在執行指令碼時會將指令碼輸出資訊以郵件的形式發送給crond使用者,但是sendmail進程堆積的原因是什麼呢?init───2*[bash] ├─crond──102*[crond─┬─sendmail] │ └─sh───sh] 5、查看sendmail日誌,發現大量的warning警示資訊。經查原來是環境的postfix沒有正常運行,導致大量sendmail進程阻塞。postfix/postdrop[23110]: warning: mail_queue_enter: create file maildrop/749274.23110: No such file or directory 6、根據博文[1]中的方法,將crontab的第一行添加:MAILTO=””,然後查看確實沒有了sendmail進程。 本以為解決了問題,但是過了幾天發現系統負載升高,同樣的方式查看,發現有了大量的postdrop進程,pstree發現發生了變化,原來postdrop進程是sendmail進程產生的,也就是說sendmail並沒有完全解決掉。init───2*[bash] |-crond---125*[crond---sendmail---postdrop] │ │ └─sh───sh] 7、查看sendmail日誌(/var/log/maillog),發現大量的warning警示資訊,錯誤顯示是許可權問題,那麼首先查看maildrop目錄的許可權(/var/spool/postfix/maildrop/),修改許可權後,查看沒有了該warning資訊。 警示資訊如下:postfix/postdrop[21235]: warning: mail_queue_enter: create file maildrop/577217.21235: Permission denied 執行命令如下:chown postfix.postdrop /var/spool/postfix/public -Rchown postfix.postdrop /var/spool/postfix/maildrop -Rchmod 777 /var/spool/postfix/maildrop -R (僅修改以上兩步時,仍然有警示。) 8、基於穩妥考慮,將/etc/crontab的MAILTO設為"",這樣保證crontab不發送日誌,也就不會產生sendmail進程了。 9、通過pstree檢查進程樹狀態,crond守護進程不會調用sendmail了,具體如下所示:init───2*[bash] ├─crond 除此之外,在查看sendmail日誌的時候,發現以下警示資訊較多,應該是系統設定上有些問題。經查是由於/etc/postfix/main.cf設定檔中,inet_protocols = all的原因。修改配置為inet_protocols = ipv4後,warning資訊沒有了。postfix/postdrop[17405]: warning: inet_protocols: IPv6 support is disabled: Address family not supported by protocolpostfix/postdrop[17405]: warning: inet_protocols: configuring for IPv4 support only