EXT3_DX_ADD_ENTRY: DIRECTORY INDEX FULL!

时间:2022-10-17 15:59:05

inode问题故障1例
故障关键字:ext3_dx_add_entry: Directory index full!

线上业务的一台服务器无缘无故突然挂了
让机房帮忙连接显示器后发现报错

EXT3_DX_ADD_ENTRY: DIRECTORY INDEX FULL!//bbsmax.ikafan.com/static/L3Byb3h5L2h0dHAvaW1hZ2Uua2JuaXguY29tL0Jsb2cvbW9uaXRvcl9lcnJvci5qcGc=.jpg

遂让机房重启了

重启后能正常进入系统,查看/var/log/message后,依然发现有这个报错,而且是持续了很久了,看来是没关注好这类型错误

先是马上查看了硬盘的inode数

df -i看,没有异常,inode use采用了14%

再Google一下,说是ext3文件系统单个目录下不能超过32000个节点

然后就查一下到底是哪个目录占用inode过多了

for i in /*; do echo $i; find $i |wc -l; done

这时候在/var目录下卡住了半天不出结果
接着进入/var里面查看一下
先是看了/var下的xdebug目录跟tmp目录,都是空的,没有异常
随手进入了spool目录
ll一看,惊呆了,其他目录都是4096大小的,里面的一个目录clientmqueue是一个天文数字
ll -h一看,1017M的目录。。。我去,这里面隐藏了多少inode
马上Google之,说是计划任务cron由于没有把输出重定向掉,而导致的,cron会把执行的计划任务的输出以mail的形式发给指定的管理员账户,默认是发给root的,然后由于没有安装或者开启sendmail服务,就会把邮件积压在这个目录里面

马上检查crontab,/etc/crontab,/etc/cron.d/*,/var/spool/cron/root,都看了,所有计划任务都是加了重定向>/dev/null 2>&1的

那就奇怪了,怎么没效果呢
马上把目录移除掉rm -rf,rsync –delete,ls | xargs rm -f都好像卡死了一样没效果

果断把它先mv掉,然后重建一个给它,发现cron继续往里面写文件了,看一下内容,都是cron的输出,重启一下crond看看,还是老样子,没效果,继续写

暂时解决办法:
把clientmqueue目录mv掉,不建立目录了,让cron无处可写,然后现在挂在screen里用rsync –delete的方法来删掉mv过的clientmqueue目录,挂了一晚,一直还卡在那,想看看有没在删
ps aux | grep rsync获取pid,然后strace -p pid,看到进程一直在unlink了,这下才放心,确定它是一直在删除的了
df -i再看看,inode use降到了8%了,目前还在删

后续
删了1天半,终于删完了
后面把sendmail服务删掉就没有再往clientmqueue写文件了

yum remove sendmail