Crontab causes file descriptor depletion in Linux

Crontab causes file descriptor depletion in Linux. scheduled tasks in the system cannot run after a period of time. The system command shows that the system has a large number of sendmail processes, which causes the file descriptor to run out. The following mainly analyzes the entire processing process for your reference. .. Crontab causes Linux file descriptor depletion problem the scheduled task in the system cannot run after a period of time. The system command shows that the system has a large number of sendmail processes, which causes the file descriptor to run out. The following mainly analyzes the entire processing process for your reference. According to the above problems, the analysis steps are as follows: 1. after a scheduled task is manually executed, the execution fails and the file descriptor is used up by mistake. The specific error is as follows: "cannot open shared object file: Too open files in system" 2. check whether the scheduled task is accumulated. ps-ef | grep No task is running. I guess it should be caused by other problems. what is it? I don't know. 3. you can see multiple sendmail processes through the system command top, and then ps-ef | grep sendmail to find a large number of processes. It should be the issue of sendmail. First, kill all sendmail processes, and then the scheduled task can be executed. After a while, check the process again and find that there are some sendmail processes to further locate the problem. /Usr/sbin/sendmail-FCronDaemon-I-odi-oem-oi-t-f root4. pstree found that the sendmail process was started by the crond daemon. How does crontab start the sendmail process? The original crond will send the script output information to the crond user in the form of an email when executing the script. but what is the reason for the sendmail process to pile up? Init ── 2 * [bash] javas── crond ── 102 * [crond ── sendmail] │ mongo── sh] 5. view the sendmail log, A large amount of warning information is found. It turns out that the environment's postfix is not running properly, resulting in a large number of sendmail processes being blocked. Postfix/postdrop [23110]: warning: mail_queue_enter: create file maildrop/749274.23110: No such file or directory 6. add the first line of crontab according to the method in blog [1: MAILTO = ", and then check that the sendmail process does not exist. I thought the problem was solved, but after a few days, I found that the system load increased. in the same way, I found that there were a large number of postdrop processes, and pstree found that there was a change, originally, the postdrop process was generated by the sendmail process. that is to say, sendmail is not completely resolved. Init ── 2 * [bash] |-crond --- 125 * [crond --- sendmail --- postdrop] │ share── sh] 7. View sendmail logs (/var/log /maillog ), A large amount of warning alarm information is found. The error is displayed as a permission problem. First, check the permissions of the maildrop Directory (/var/spool/postfix/maildrop/). after modifying the permissions, check that this warning information is missing. The alarm information is as follows: postfix/postdrop [21235]: warning: mail_queue_enter: create file maildrop/577217.21235: Permission denied execute the command: chown postfix. postdrop/var/spool/postfix/public-Rchown postfix. postdrop/var/spool/postfix/maildrop-Rchmod 777/var/spool/postfix/maildrop-R (there is still an alarm when only two steps are modified .) 8. set the MAILTO of/etc/crontab to "" based on security considerations. This ensures that the crontab does not send logs, and no sendmail process will be generated. 9. check the process tree status through pstree. the crond daemon will not call sendmail, as shown in the following code: init ── 2 * [bash] handle-crond, when viewing the sendmail log, the following alarm information is found to be large, which should be caused by some problems in system settings. It is found that inet_protocols = all is in the/etc/postfix/main. cf configuration file. After the configuration is changed to inet_protocols = ipv4, the warning information is unavailable. Postfix/postdrop [17405]: warning: inet_protocols: IPv6 support is disabled: Address family not supported by protocolpostfix/postdrop [17405]: warning: inet_protocols: loading ING for IPv4 support only