计划任务导致的sedmail进程异常,CPU占用过高,SSH连接不上,网站打不开问题

2023-03-02 PHP linux 云服务商 1290

问题描述

中午网站突然打不开,登录阿里云控制台发现ECS的CPU占用一直在56%以上,尝试ssh登录服务器无法连接,最终只能重启。

问题排查

1. 重启服务器,ssh登录后,发现一堆sendmail进程。

ps aux

/usr/sbin/sendmail -fcrondaemon -i -odi

/usr/sbin/sendmail -fcrondaemon 关键字作为切入口,bing搜索发现有几篇关于此问题博文,其中一篇描述是由系统计划任务(crond)引起【此时没有细读文章,还不理解,为什么是crond引起】。

2. 数据库任务记录表和php任务脚本,未排查出明显的脚本问题

3. 排查系统日志,分别查看了 /var/log/cron, /var/log/maillog, /var/log/messages 三个日志文件

发现 /var/log/maillog 文件,全是以下错误:

postfix/postdrop[1621814]: warning: mail_queue_enter: create file maildrop/600340.1621814: No space left on device

/var/log/messages 文件,从中午出问题时间,全是以下错误:

postdrop: warning: mail_queue_enter: create file maildrop/352345.1624052: No space left on device

4. 修改计划任务 crontab -e 报错 /tmp/crontab.rHuk45:No space left on device

通过 df -h,显示磁盘并没有占满。但是 df -i 却显示 /dev/sda1 inodes 100%,说明该目录文件数量已达到最大数量。

5. du -h 发现, /var/spool/postfix/maildrop 文件夹占用磁盘最大9.5GB

该目录其实是,邮件发送失败时写入的大量小文件。 这时候文件太多,就不要 cdls -la 进入该目录查看内容了,会卡死

问题出现原因

结合搜索到的相关文章,分析出现问题的原因是:

Liunx执行crond计划任务时,当脚本(我的是php脚本)存在标准输出或标准错误输出时,会以邮件的形式通过 sendmail服务发送给cron执行者,而服务器 postfix(邮件服务) 未运行,导致发送失败,文件堆积到 /var/spool/postfix/maildrop 目录,最终文件数量达到最大inodes。再如果输出信息太大会引发sendmail失败,成为僵尸进程,进程中出现一堆的 /usr/sbin/sendmail -fcrondaemon -i -odi 进程,导致CPU占用过高,各项服务停摆。

问题解决方式

一、 删除 /var/spool/postfix/maildrop 下的文件

find /var/spool/postfix/maildrop/ -type f |xargs rm -rf

二、 停止计划任务,把标准输出邮件转发,以下三种种方式皆可:

  1. 编辑crond配置文件

vi /etc/crontab,修改 MAILTO=""

  1. 修改计划任务 crontab -e,开头增加 MAILTO=""

  2. 修改计划任务,将标准输出重定向到空设备,命令行后面拼接 > /dev/null 2>&1

crontab -e
# 命令行后面拼接 > /dev/null 2>&1
php /www/think command > /dev/null 2>&1

三、 重启 crond 服务

systemctl restart crond
0