一，遇到的问题
系统中的定时任务，过一段时间之后，不能运行。
通过系统命令查看到系统有大量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进程，进一步定位问题。
 

4、通过pstree发现，sendmail进程是有crond守护进程启动的。crontab怎么会启动sendmail进程？原来crond在执行脚本时会将脚本输出信息以邮件的形式发送给crond用户，
但是sendmail进程堆积的原因是什么呢？
 

5、查看sendmail日志，发现大量的warning告警信息。经查原来是环境的postfix没有正常运行，导致大量sendmail进程阻塞。
 

6、根据博文[1]中的方法，将crontab的第一行添加：MAILTO=””，然后查看确实没有了sendmail进程。
本以为解决了问题，但是过了几天发现系统负载升高，同样的方式查看，发现有了大量的postdrop进程，pstree发现发生了变化，原来postdrop进程是sendmail进程产生的，
也就是说sendmail并没有完全解决掉。
 

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
 执行命令如下：
 

8、基于稳妥考虑，将/etc/crontab的MAILTO设为""，这样保证crontab不发送日志，也就不会产生sendmail进程了。
9、通过pstree检查进程树状态，crond守护进程不会调用sendmail了，具体如下所示：
 

除此之外，在查看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 protocol
postfix/postdrop[17405]: warning: inet_protocols: configuring for IPv4 support only

某服务器账号comm无法登录，说是资源消耗完毕。
于是用另一个账号登陆到服务器，检查common账号到底启动了哪些dd引起资源耗尽：
ps -u common
发现有个 sendmail的启动特别多
例如：
common   31446 31377  0 20:20 ?       /usr/sbin/sendmail -FCronDaemon -i -odi -oem -oi -t -f root
鉴于资源耗尽，留下证据后，先杀掉，保证生产：
 

然后，检查是哪个进程启动了sendmail：
 

发现是crond启动了。
这个进程怎么会调用sendmail呢？
既然是crond启动的，而之前一直好好的，于是询问最近谁修改了crond。
经查，有个同事添加了一个crond记录，一分钟运行一次。

然后，查看sendmail进程：
 

果然又有了，而且sendmail是1分钟启动一个。

看来就是它了，将它从crontab暂停，2分钟过去。
没有新的sendmail启动，于是将问题就锁定在它身上了。

也没有想到原因，为啥crond会调用sendmail，google之找到了这样一句
crond在执行脚本时会将脚本输出信息以邮件的形式发送给crond用户，而环境的postfix没有正常运行，导致邮件发送失败。
查看maillog，确实有很多错误：
postfix/postdrop[23110]: warning: mail_queue_enter: create file maildrop/749274.23110: No such file or directory

解决方法：
在crontab中第一行增加MAILTO=""发送为空

如果cron有什么原因需要将命令结果发一封邮件，那么就要看MAILTO这部分了，如果给MAILTO赋值了，并且不是空，那么就会发给这个用户；
如果是空，MAILTO=""，那就不发任何邮件。
如果没有定义MAILTO，也就是说crontab里面没有写这一行，那么就发给这个crontab的用户

下面来看下man手册中的解释吧。
man 5 crontab
    In  addition  to  LOGNAME,  HOME, and SHELL, cron(8) will look at MAILTO if it has any reason to send
 mail as aresult of running commands in "this" crontab.  If MAILTO is defined (and non-empty), mail is
sent to  the  userso  named.   If  MAILTO  is defined but empty (MAILTO=""), no mail will be sent. 
Otherwise mail is sent to the owner of the crontab.  This option is useful if you decide on /bin/mail
 instead of  /usr/lib/sendmail  as  your mailer when you install cron -- /bin/mail doesn′t do aliasing,
and UUCP usually doesn′t read its mail. If MAIL-FROM is defined (and non-empty),
it will be used as the envelope sender address, otherwise,  ‘‘root’’  will  be used.

由于我们这个不需要发邮件，于是 在crontab 第一行加上 MAILTO=""，到此问题解决了。

学习ulimit命令的用法。

功能说明：控制shell程序的资源。
语　　法：ulimit [-aHS][-c <core文件上限>][-d <数据节区大小>][-f <文件大 小>][-m <内存大小>][-n <文件数目>][-p <缓冲区大小>][-s <堆叠大 小>][-t <CPU时间>][-u <程序数目>][-v <虚拟内存大小>]
补充说明：ulimit为shell内建指令，可用来控制shell执行程序的资源。
参　　数：
 

ulimit -a 用来显示当前的各种用户进程限制。
Linux对于每个用户，系统限制其最大进程数。为提高性能，可以根据设备资源情况，设置各linux 用户的最大进程数。
例如，把某linux用户的最大进程数设为10000个：
ulimit -u 10000
对于需要做许多 socket 连接并使它们处于打开状态的 Java 应用程序而言，
最好通过使用 ulimit -n xx 修改每个进程可打开的文件数，缺省值是 1024。
ulimit -n 4096 将每个进程可以打开的文件数目加大到4096，缺省为1024

其他建议设置成无限制（unlimited）的一些重要设置是：
 

有时服务器需要调整ulimit的stack size 参数调整为unlimited 无限，使用ulimit -s unlimited时只能在当时的shell见效，重开一个shell则失效。

解决方法：
在/etc/profile 的最后面添加ulimit -s unlimited。如下图：

然后：
# source /etc/profile
使修改即时生效。

可能的问题：
如果碰到类似的错误提示
ulimit: max user processes: cannot modify limit: 不允许的操作
ulimit: open files: cannot modify limit: 不允许的操作
以上操作对root用户是不会提示这样的限制信息的，只对普通用户有影响，原因何在？

大家可以去研究下文件：/etc/security/limits.conf。

说明：
linux对用户有默认的ulimit限制，而这个文件可以配置用户的硬配置和软配置，硬配置是个上限。
超出上限的修改就会出“不允许的操作”这样的错误。

可以在limits.conf文件最后添加相关内容，如下图：

即限制任意用户的最大线程数和文件数为10240。