lnode满，维护记录

df  17% 正常

df -i 100%

inode耗尽。

find */ ! -type l | cut -d / -f  | uniq -c

查出占用lnode最大的目录是

/var/spool/exim4/input

居然有15W多个小文件

exim4是邮件服务器。

奇怪，这服务器根本就没有作邮件服务。

如果不是出现这次的异常，我根本不知道服务器有装exim4。

删光后，文件又一点点冒出来了。

打开其中一看。立马闻到了“坏味道”。

捉到狐狸尾巴了。

1a5aTr-0006zH-5Z-D/home/ftp_tmp/-----.tmp
Traceback (most recent call last):
  File "/root/name/bcp_76_wb.py", line , in <module>
    ftp.connect("61.163.86.10","",)
  File "/usr/lib/python2.7/ftplib.py", line , in connect
    self.sock = socket.create_connection((self.host, self.port), self.timeout)
  File "/usr/lib/python2.7/socket.py", line , in create_connection
    raise err
socket.error: [Errno ] Connection refused

这明明就是错误日志，而且是python的，服务器上确实有跑其他开发的人员的python项目。

再打开几个

1a5Aso-0003rm-UL-D
&* 数目 :
 &*数目 :
 (vsFTPd 2.3.)
20151205192002100_139_410100_748836377_004.log
20151205192002100_139_410100_748836377_004.log.ok
20151205192002100_139_410100_748836377_009.log
20151205192002100_139_410100_748836377_009.log.ok
20151205192002100_139_410100_748836377_011.log
20151205192002100_139_410100_748836377_011.log.ok
request ok

root@srv1-:/var/spool/exim4/input# vim 1aCPgF-0008U0--H

-allow_unqualified_sender
-deliver_firsttime
-local
XX

root@debian

166P Received: from root by srv1-.localhost with local (Exim 4.80)
        (envelope-from <root@debian>)
        id 1aCPgF-0008U0-
        for root@debian; Fri,  Dec  :: +
* From: root (Cron Daemon)
032F From: root@debian (Cron Daemon)
* To: root
016T To: root@debian
  Subject: Cron <root@srv1-> python /root/xiaoyun/audit_top_cron.py
  Content-Type: text/plain; charset=UTF-
  X-Cron-Env: <SHELL=/bin/sh>
  X-Cron-Env: <HOME=/root>
  X-Cron-Env: <PATH=/usr/bin:/bin>
  X-Cron-Env: <LOGNAME=root>
050I Message-Id: <E1aCPgF-0008U0-@srv1-.localhost>
  Date: Fri,  Dec  :: +

都是python的。

该服务器，有多个项目，我个人既开发又维护。

原因是

系统中有用户开启了cron，而cron中执行的程序有输出内容，输出内容会以邮件形式发给cron的用户，系统有装邮件服务器，则会写到邮件服务器的队列。如果没有邮件服务器会写入/var/spool/clientmqueue目录。

而python正好是cron启的，日志就全跑/var/spool/exim4/input了，把lnode用光了。

我个人负责go/nodejs/java项目，项目都写为服务开机启动

python的程序是由另一名人员开发部署，靠cron定时检测，检测未启则启动。

比开机启动要健壮，服务器运行了4个多月，出现了这个问题。

修改办法，把cron任务的输出重定向 即在计划任务后加上> /dev/null 2>&1

解决。