大量postdrop进程挂死或登录bash 挂起的分析与解决

前言


本文源自作者在苏宁科技集团云平台工作期间的部分工作记录文档,先转到public ,希望能帮到有类似问题的同行


1、  问题描述


/var/log/sa目录是sysstat 安装包的一部分。问题目标机缺失了该目录,当crond 发起的定时任务执行/usr/lib64/sa/sa1访问目录不到报错,会生成mail文件置于/var/spool/postfix/maildrop/,长时间后 /var 目录空间满了之后,导致postdrop 进程阻塞堆积数量多,占用系统资源。

 image2018-11-6%2014%3A46%3A7.png?version=1&modificationDate=1541486917000&api=v2

 

症状2

后来发现另一个症状,root 用户登录时推测有某种消费这些mail 的机制,/var/spool/postfix/maildrop/  如果已经有了文件堆积,会导致登录bash 的 cpu 和内存 消耗很大

 

 

2、  场景复现

1)       用一台虚拟机做测试,该cron文件位于/etc/cron.d/

 image2018-11-6%2014%3A46%3A18.png?version=1&modificationDate=1541486917000&api=v2

/usr/lib64/sa/sa1为每10分钟执行一次

 image2018-11-6%2014%3A46%3A31.png?version=1&modificationDate=1541486917000&api=v2

为了尽快复现,调整为1分钟执行一次

 image2018-11-6%2014%3A46%3A44.png?version=1&modificationDate=1541486917000&api=v2

2)       删除/var/log/sa文件夹

rm –Rf  /var/log/sa

3)       用dd命令占用var空间到接近100%

 image2018-11-6%2014%3A46%3A53.png?version=1&modificationDate=1541486917000&api=v2

4)       由于没有硬盘空间可用,会阻塞大量的sendmail进程和postdrop进程

 image2018-11-6%2014%3A47%3A3.png?version=1&modificationDate=1541486917000&api=v2

 image2018-11-6%2014%3A47%3A11.png?version=1&modificationDate=1541486917000&api=v2

 

当出现找不到sa1文件后,sendmail进程会发消息,并记录到/var/mail/root文件

image2018-11-6%2014%3A47%3A40.png?version=1&modificationDate=1541486917000&api=v2

当磁盘空间不足时候,无法写入导致sendmail被阻塞,会调用postdrop进程将消息丢到/var/spool/postfix/maildrop/文件夹里:

但是磁盘空间不足同样会阻塞postdrop,所以直观表现就是产生大量postdrop和sendmail挂在那。

5) 清除掉var目录下的一部分文件,产生可用磁盘空间,sendmail和postdrop进程会立即解除阻塞状态,postdrop进程全部结束。

 image2018-11-6%2014%3A47%3A51.png?version=1&modificationDate=1541486917000&api=v2

 

 3、  解决方法

1)       清除var目录下部分文件,释放磁盘空间

2)       恢复sa文件夹,避免不断sendmail和postdrop


猜你喜欢

转载自blog.51cto.com/13866624/2387038
今日推荐