inode占满前因后果

最新推荐文章于 2024-09-14 19:55:29 发布

weixin_34314962

最新推荐文章于 2024-09-14 19:55:29 发布

阅读量552

点赞数

文章标签：操作系统 python

原文链接：https://my.oschina.net/andChow/blog/2980744

版权

2019独角兽企业重金招聘Python工程师标准>>>

0. 问题描述

现象
收到钉钉报警，线上Solr服务器/var分区inode占满。
影响
/var分区无法再创建新文件。
inode是什么
inode为文件系统中块的索引节点，os中每个文件会占用一个inode，且inode的大小是有限制，和磁盘大小成正比，与分区块的数量一致，所以在磁盘格式化后大小已固定。

1. 排查

# 1. 使用df -i 查看各分区inode使用情
[root@xxx ~]# df -i
Filesystem       Inodes   IUsed    IFree IUse% Mounted on
/dev/sda2       2097152   26111  2071041    2% /
tmpfs          33059719       4 33059715    1% /dev/shm
/dev/sda1         32768      46    32722    1% /boot
/dev/sda7      77840384   49535 77790849    1% /data
/dev/sda3       2097152  199748  1897404   10% /usr
/dev/sda5       2097152 2061500    35652   99% /var
# 结论：确定var分区inode基本快满了

# 2. 使用 find /var目录查看最近1个小时内生成的文件
[root@xxx ~]# find /var/  -type f -mtime +60
....
/var/spool/postfix/maildrop/8B39F1B854F
/var/spool/postfix/maildrop/EA79986E6
/var/spool/postfix/maildrop/7576417CEB2
/var/spool/postfix/maildrop/EFEEA128578
/var/spool/postfix/maildrop/DF9C5216A
/var/spool/postfix/maildrop/895FB124392
.... 
# 结论：通过上述内容，基本可以定位是有由于/var/spool/postfix/maildrop目录下生成太多小文件引发问题的

# 3. 临时解决方法
[root@xxx maildrop]# cd /var/spool/postfix/maildrop
[root@xxx maildrop]# rm -rf * 
-bash: /bin/rm: Argument list too long # 无法删除
# 3.1 由于文件太多无法删除的解决办法，通过如下脚本查找出当前目录下的所有文件，然后再删除
[root@xxx maildrop]# find /var/spool/postfix/maildrop -type f -name '*' | xargs rm -rf '*'

[root@xxx maildrop]# df -i 
Filesystem       Inodes  IUsed    IFree IUse% Mounted on
/dev/sda2       2097152  26111  2071041    2% /
tmpfs          33059719      4 33059715    1% /dev/shm
/dev/sda1         32768     46    32722    1% /boot
/dev/sda7      77840384  50439 77789945    1% /data
/dev/sda3       2097152 199748  1897404   10% /usr
/dev/sda5       2097152   3952  2093200    1% /var # 恢复正常

2. 原因分析及解决办法

通过上述操作，发现原因为：/var/spool/postfix/maildrop目录生成大量文件。

进一步分析
maildrop文件夹下的文件生成原因为：

由于 Linux 在执行 cron 时，会将 cron 执行脚本中的 output 和 warning 信息，都会以邮件的形式发送 cron 所有者，而由于客户环境中的 sendmail 和 postfix 没有正常运行，导致邮件发送不成功，全部小文件堆积在了 maildrop 目录下面，而且没有自动清理转换的机制，所以长达一年的时间，此目录已堆积了大量的文件。查看 man cron 的信息，可以知道会发送给 cron owner

根治方法
cron任务执行结果未屏蔽，解决办法：

# 1. 有问题的设置方式
*/10 * * * * /tmp/test.sh

# 2. 使用>/dev/null 2>&1，将执行过程中的output和warning屏蔽，但cron任务执行的日志，仍会在/var/log/cron中找到
*/10 * * * * /tmp/test.sh >/dev/null 2>&1