lnode满,维护记录

时间:2021-01-30 07:19:35

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

解决。