crond-sendmail-postdrop导致Linux定期死掉的完整解决过程实录

原创 2013年05月22日 15:32:19

问题描述

一台2004年配置的RedFlag Server 4.1数据库服务器,基本软件是Oracle9i,没有按照X窗口系统。一次发现日志磁盘分区无法写入,问题是sendmail导致大量小的文件,占满了inode编号,从而导致虽然磁盘仍有空间,但是inode用完的局面。由于本系统用途为单一的数据库服务器,所以邮件几乎没什么用途,于是删除了这些小文件,然后chkconfig停止了sendmail服务。于是之后发生了如下的故事...

理论上说,纯命令行的Linux系统相当稳定,可是这台机器最近总是不定期一周左右死掉。症状为:系统无法登陆,以登陆还是重复显示登陆提示符,系统的各项服务如sshd和最基本的数据库服务也不能工作。由于已经无法登入系统,所以排错相当困难。硬重启后系统则正常,只是不久后问题依旧,非常烦人。

排错过程

maillog日志文件占满分区空间

照例查看系统日志,/var/log/message、/var/log/secure、dmesg等,没有发现异常。df -h发现日志所在的文件系统分区使用率100%了,是不是因为这个原因系统死掉呢?如如何根据日志判断呢?(ToDo)。
记得之前有一次因为这个分区占用较大,一气之下把/var/log整个目录都rm -rf了,导致了一些关键的目录和文件被删除,如/var/log/rflogview/以及其下面的文件,这些是系统日志文件,文件不存在了,syslogd也就无法写入(syslogd不会自动创建不存在的日志文件),所以一些关键的系统日志都被丢失了。

du -sh 查看找到了一个巨大的文件/var/log/mailog。head、tail查看内容,发现全是同样的内容行,如下:
May 13 15:29:23 lcha2 postfix/postdrop[1443]: warning: mail_queue_enter: create file maildrop/383480.1443: No such file or directory
May 13 15:29:23 lcha2 postfix/postdrop[1269]: warning: mail_queue_enter: create file maildrop/330426.1269: No such file or directory
May 13 15:29:23 lcha2 postfix/postdrop[1439]: warning: mail_queue_enter: create file maildrop/357169.1439: No such file or directory
May 13 15:29:23 lcha2 postfix/postdrop[1654]: warning: mail_queue_enter: create file maildrop/984222.1654: No such file or directory
使用 tail -f /var/log/maillog,发现每秒都有几乎相同的文本行输出。按照上面的日志内容,判定是postfix这个套件的postdrop程序发出的日志。是谁启动了postdrop呢?
使用pstree,结果如下:

init-+-aacraid
     |-atd
     |-bdflush
     |-crond---125*[crond---sendmail---postdrop]

可见crond守护进程启动了sendmail,进而启动了postdrop。查看crond的配置, crontab -e,都没有发现几秒就启动的程序,所以可能是sendmail自己一旦邮件发送不成功,就持续重新发送而导致持续启动postdrop,而postdrop总是执行失败,导致持续写入日志到日志文件。日志文件增大的速率超过了logrotate的删除频率,所以占据了100%的磁盘空间。

由于sendmail没有退出,导致启动它的crond也不能退出,从而导致多个crond进程并存。

找到了问题,解决起来相对简单。一种方式就是不让postdrop产生的日志写入日志文件,这通过修改/etc/syslog.conf文件达成;第二种方式是增大logrotate的删除频率,这通过修改logrotate的crond像以及/etc/logrotate.conf配置文件达成;第三就是找到postdrop失败的原因,修正使其能够成功进行。最简单的就是第一种了,也能满足目前的需要,所以就采取了第一种方式。

修改syslog.conf使得不记录mail的warning信息,修改前如下:
mail.*                                                        /var/log/maillog
修改后
mail.err  /var/log/maillog
这样就通过提高日志记录的级别来舍弃了mail类的warning级别日志。

service syslog restart重新启动syslogd。然后tail -f /var/log/maillog,在没有上面类似日志的输出了。

文件打开数量达到极限

然而,几天后重新出现死机的现象,不过这次在现场显示器上看到了类似 "cannot open shared object file: Too many open files in system"的信息。在Linux中,“一切都是文件”,程序文件本身、各种库文件、管道、设备、网络连接等等都是文件。上述信息说明,系统打开的文件数量到达了极限,从而导致无法打开新文件,当然也就无法执行程序。通过 sysctl -a 可以看到fs.file-max = 131072,这个数字也不小了。那么是谁打开了这么多的文件呢?通过lsof 查看发现名为sendmail和postdrop的多个进程,每个进程都打开了多个文件。通过 ps -e | grep sendmail | cut -d ' ' -f2 | xargs kill,以及ps -e | grep postdrop| cut -d ' ' -f2 | xargs kill,杀死所有sendmail和postdrop进程后,再lsof发现打开的文件数骤减。

前面已经给出了pstree的结果,发现是cron启动了sendmail,sendmail启动了postdrop。临时写了一个小的测试脚本,来看sendmai的启动频率。

while true
do
        date +%H:%M:%S >> 1.txt
        ps -e | grep sendmail | wc >>1.txt
        sleep 5
done
从结果文件1.txt中发现每10分钟,就会启动一个sendmail进程。crontab里有个没有这个频率的启动项,但有一个每5分钟自动网络校时的启动项。把这个项注视掉,重新启动crond,发现仍然有sendmail的启动,从而排除了这个原因。难道是crond本身每10分钟就自动发送邮件吗?按照man 5 crontab的解释,把/etc/crontab的MAILTO设为"",这样crond就不会发送邮件了。重新启动crond服务,发现crond仍然10分钟启动一次sendmail,太奇怪了!干脆直接关闭crond服务,然后再也没有新的sendmail进程产生。难道是crontab被黑了?为什么MAILTO=""了,还会调用sendmail呢?把所有的sendmail进程都kill掉,然后启动crond, 仍然会生产sendmail,看来crond和sendmail的关系绝非一般。

被忽略的/etc/cron.d

弄了半天,发现了/etc/cron.d目录下存在一个文件,而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

全过程总结


心得体会

  • 日志文件是系统分析的关键,要确保所有日志文件目录可用,如果不可用,syslogd不会自动创建它们,也就失去了记录日志的机会!
  • crond,logrotate,syslogd相互配合
  • crond和sendmail的关系绝非一般,crontab中MAILTO设置了空,crond仍然会调用sendmail发送邮件,解决方式是把crond执行的命令最后加上 &> /dev/null。
  • 要全面了解一个软件包,比如cron.d是crond的一部分,作者就就吃亏在这个上面
  • 多动手测试,熟练使用bash命令

解决crond引发大量sendmail、postdrop进程问题

问题:服务器内存接近耗尽报警,ps -ef查看有3000多个进程,大部分都是crond、sendmail、postdrop 而 postdrop是由sendmail启动的,而sendmail又是由c...
  • liang100k
  • liang100k
  • 2016年12月14日 10:32
  • 1323

Linux进程多导致CPU卡死的问题

Linux进程多导致CPU卡死的问题
  • guoyJoe
  • guoyJoe
  • 2015年11月19日 10:57
  • 2405

linux OOM-killer机制(杀掉进程,释放内存)

Linux 下面有个特性叫 OOM killer ( Out Of Memory killer ) ,这个东西会在系统内存耗尽 的情况下跳出来, 选择性的干掉一些进程以求释放一些内存。...
  • hunanchenxingyu
  • hunanchenxingyu
  • 2014年05月19日 17:49
  • 9414

Android应对进程被杀死--Service(一)

序言 最近项目要实现这样一个效果:运行后,要有一个service始终保持在后台运行,不管用户作出什么操作,都要保证service不被kill,这可真是一个难题。参考了现今各种定制版的系统和安全厂...
  • f2006116
  • f2006116
  • 2016年03月16日 21:34
  • 4536

crond-sendmail-postdrop导致Linux定期死掉的完整解决过程实录

问题描述 一台2004年配置的RedFlag Server 4.1数据库服务器,基本软件是Oracle9i,没有按照X窗口系统。一次发现日志磁盘分区无法写入,问题是sendmail导致大量小的文件,...
  • k178441367
  • k178441367
  • 2014年12月11日 11:59
  • 330

由于磁盘空间不够导致redis,zookeeper,kafka,storm死掉的解决方法

在公司的三台虚拟机上答了redis,zookeeper,kafka,storm集群,redis装在redis用户下,其他的装在storm用户下 但是发现莫名奇妙的总是会死掉,一直差不出原因,后来发现...
  • Caide3
  • Caide3
  • 2017年05月05日 18:34
  • 1158

oracle数据量过大导致死掉的解决方法

CREATE OR REPLACE PROCEDURE CNV_INSERT_LFZK_TT_UKH AS CURSOR C_UKH IS SELECT * FROM LFZK_TT...
  • xialinlin8520
  • xialinlin8520
  • 2013年06月07日 11:03
  • 1387

crond引发大量的sendmail进程

某服务器账号comm无法登录,说是资源消耗完毕。 于是用另一个账号登陆到服务器,检查common账号到底启动了哪些dd引起资源耗尽: ps -u common 发现有个 sendmail的启动特...
  • Mrknowledge
  • Mrknowledge
  • 2016年10月24日 14:58
  • 383

可以让你的Linux死掉的程序

作为Linux的用户,如何故意让自己的Linux死机? 这个问题看似简单,但是真要去做,还不是那么容易能做到的。 不信读者先不要看后文,先自己尝试一下如何让自己的Linux死机。 ...
  • smfwuxiao
  • smfwuxiao
  • 2012年09月04日 09:59
  • 3255

GPIO驱动写错,导致内存出现问题,系统死掉

解决方法: 请教了别人,噶偶我让我用nfs挂载,但搞了半天,只是把PC上的文件挂载到了开发板上,比较郁闷 后来在系统快起的时候kill掉自启动的QT程序,卸载自己装载的驱动,然后用FLASHFXP进入...
  • city_of_the_sky
  • city_of_the_sky
  • 2013年11月19日 15:30
  • 793
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:crond-sendmail-postdrop导致Linux定期死掉的完整解决过程实录
举报原因:
原因补充:

(最多只允许输入30个字)