Linux 定时任务引发的大问题

问题描述

昨天一台开发服务器出现了很奇怪的问题，项目网站无法访问，ssh登录时非常慢，半分钟才进去，在命令行敲命令几乎没有反应，要耐心的等待 进去后用 top 查看系统状态，结果很吓人，平均负载值在360，Tasks数量超级大（具体值忘了），用VI编辑文件都有异常提示，系统几乎瘫痪

解决过程

决定先降低负载，好能正常操作，不然连输入命令都费劲，然后再找原因，从根解决 执行 top 时，在进程列表中看到了大量的 postdrop 进程，很明显这个有问题 先把他停了，让系统有个喘气的机会 #ps -ef|grep postdrop | grep -v grep | awk '{print "kill -9 " $2}' |sh 看日志 找线索 /var/log 下，发下 maillog 文件很大、很新，和之前的嫌疑进程 postdrop 很符合 从 maillog 中发现大量的如下信息 Apr 21 16:56:13 AY140 postfix/postdrop[2377]: warning: mail_queue_enter: create file maildrop/157768.2377: No space left on device 可以看出大概，系统写邮件文件时失败，因为没空间了 查看磁盘空间信息 # df -h 系统盘的使用率是 94%，块空间没满 再看inode使用情况 # df -i 系统盘的Inodes使用率100% 没Inodes可用空间，自然干啥都有问题，现在最紧急的就是清理空间

是谁占用了大量空间？

从日志信息中可以知道，postfix 一直往 maildrop 目录下创建文件，现在失败，说明之前肯定成功创建了很多文件，postfix应该就是凶手 但这个maildrop目录具体在哪儿？搜索资料后，找到了他的绝对路径 /var/spool/postfix/maildrop 看下这个目录占用的空间大小 # du -sh . 4G 多，找对地方了，就是这里的大量文件占用的空间，删掉其中所有文件 # ls | xargs rm -f 又是漫长的等待，删完后，空间占用值直接就降下来了 到这，燃眉之急已经解决，系统能正常点的运行了，下面就要找问题的根本原因 是谁启动了那么多postdrop进程？ 在删除 maildrop 文件之前，复制出来了几个文件，内容都是一个命令的报错信息 再查看进程树 # pstree 发现是cron启动了sendmail，sendmail启动了postdrop 对上了，那个报错的命令正是在cron中定时执行的一个任务，而且是个高频执行的任务 大概明白了问题的来源： （1）定时任务执行的程序报错，输出错误信息 （2）系统要通过sendmail把错误信息发给管理员 （3）sendmail会使用postdrop程序将邮件存入postfix队列目录下的maildrop子目录 我对邮件这部分不熟悉，不知道怎么处理，想到的最简单办法就是不让定时任务出现错误信息，那么就不会发送邮件了 办法是让定时任务的程序输出重定向，在那条定时任务后面加上 " &>/dev/null"，相当于把任务执行的结果信息扔掉了 之后用 top 观察了一段时间，postdrop进程不再出现，系统负载恢复正常，问题解决，接下来就是分析定时任务执行的那个程序为什么报错，应该比较简单了