cron、sendmail、postdrop 最近有一台centos7服务器故障,经过排查发现是cron导致的,具体如下:
情景1:因cron错误触发sendmail进程发送告警邮件(没有配置邮件服务器),邮件发送失败,进而触发postdrop进程,这个操作会不断累积,最终导致内存/innode号资源不足; 情景2:postdrop失败会有警告信息生成,保存在/var/spool/postfix/maildrop,经过一段时间的累积,最终导致磁盘资源不足; fix情景1: 检查mem占用情况,发现大量的CRON——sendmail——postdrop进程; 先解决燃眉之急,直接pkill postdrop释放内存和innode资源,但是几天后又出现同样的问题; why 有这么多的postdrop进程呢? 查看系统日志发现有执行失败的cron,于是问题开始浮出水面(如情景1中所述); how to fix it? 先写了一个脚本监控sendmail进程的启动频率: while true
do
date +%H:%M:%S >> 1.txt
ps -e | grep sendmail | wc >>1.txt
sleep 5
done结果发现每10分钟就会启动一个sendmail进程,查看其用户为internal(一个普通用户); 上面讲到和cron有关,于是就先排查crontab -l -uinternal,果然开发自己写了定时任务(按规定是禁止开发手动添加定时任务的),上网查到最简单直接的fix办法就是在定时任务首行加上参数“MAILTO=""”; 过来几天查看服务器状态,发现又有很多sendmail进程,why?此时查看/etc/cron.d下的cron,发现这里也有使用internal用户执行的定时任务,于是再次使用上述方法; 心想,总不能随时都这样手动fix吧,而且普通用户那么多,cron文件也很多,这。。。进一步查资料发现如下内容:
MAILTO是针对用户配置的,于是将该参数加入/var/spool/cron/internal下;
经检验发现,上面的操作同样对/etc/cron.d下的定时任务不生效、、、GG; 再次搜索,参考解决办法如下:
/etc/cron.d下面有一个sysstat定时任务脚本,crond会自动读取其中的配置信息,正好这个文件里有一个项就是每10分钟执行一次systat软件包的命令,测试表明这个命令由于所写日志文件不存在而导致报错,一旦报错,crond就会sendemail(不管MAILTO的值如何?)。在这条命令后面加上 &>/dev/null后,发现crond不再启动sendmail进程。 原来内容:
# run system activity accounting tool every 10 minutes
*/10 * * * * root /usr/lib/sa/sa1 1 1
# generate a daily summary of process accounting at 23:53
53 23 * * * root /usr/lib/sa/sa2 -A
其中的命令会报错:
[root@lcha2 root]# /usr/lib/sa/sa1 1 1
Cannot open /var/log/sa/sa20: No such file or directory
修改后:
# run system activity accounting tool every 10 minutes
*/10 * * * * root /usr/lib/sa/sa1 1 1 &>/dev/null
# generate a daily summary of process accounting at 23:53
53 23 * * * root /usr/lib/sa/sa2 -A &>/dev/null 参考:
https://blog.csdn.net/liang100k/article/details/53634809
https://blog.csdn.net/dodott/article/details/53907518
https://www.aliyun.com/jiaocheng/200151.html
心得体会 日志文件是系统分析的关键,要确保所有日志文件目录可用,如果不可用,syslogd不会自动创建它们,也就失去了记录日志的机会! crond,logrotate,syslogd相互配合 crond和sendmail的关系绝非一般,crontab中MAILTO设置了空,crond仍然会调用sendmail发送邮件,解决方式是把crond执行的命令最后加上 &> /dev/null。 多动手测试,熟练使用bash命令。 fix情景2: 先清理垃圾文件释放磁盘资源; 然后还是因为错误cron的原因,回归到情景1。 终极fix 后续经过不断的搜索,找到如下方法彻底解决了上述问题:
方法1: 使用crond服务的内置参数“-s”,其功能是将邮件发送失败后的错误输出到syslog,对于系统日志配置了logrotate规则,所以不会造成垃圾文件无限制堆积。但是该方法存在的弊端是,在syslog中会有大量垃圾文件,不利于运维管理。方法2: 使用crond服务的“-m off”参数,其作用是关闭crond邮件发送功能,这样可以更加优雅的解决问题。 (adsbygoogle = window.adsbygoogle || []).push({});