记录一次errno.ENOSPEC致使的supervisor启动失败

0x00 原由

最近公司的蓝鲸发布上线系统又一次 down 掉了，而以前搭建这个平台的老哥已经离职，因此我也是临危受命来负责处理这个问题，只隐约记得当时那位老哥好像是说过频繁 down 掉的缘由是性能瓶颈，并升级过一次 ECS 的配置，因此我第一反应也认为是机器性能瓶颈，然而事情并无那么简单。

0x01 分析

1. 现象分析

排查问题的过程我以为和看病很类似，因此第一时间是看现象，当时的现象是 nginx 返回 502 code，而根据502 code 的含义和以往的经验，我第一时间就想到的是后端服务 down 掉了，接下来一检查，果真是如此。因此下一步是要把后端程序服务启动起来。

2. 资料查阅

因为我之间并无接触过蓝鲸这个发布平台，因此我第一次时间是去找官方文档，而不是直接操做一把梭，这也是我在这几年工做中摸索出来的重要的一点。在查阅了官方的的资料后，我大概清楚了蓝鲸的软件架构，并了解到了蓝鲸的主要几个服务是由 supervisor 托管的，那么接下来就是须要把这几个服务启动起来了。

3. 问题处理

supervisor和 systemd 做为 Linux 上用的最多的两款进程管理系统，我仍是比较熟悉的，因此当我尝试将supervisord 启动的时候，却报错了：

Error: Cannot open an HTTP server: socket.error reported errno.ENOSPC (28)

当我看到这个错误的时候，和全部的程序员同样，首先就是复制错误码到 google 里面搜索看有没有结果。。。然而并无和我同样的错误，我只好查阅 supervisor 的官方文档，里面也并无详细的说明，接下来我又查了一些英文资料也无任何线索，我开始有些焦急了。

万幸，我明白越是在排查问题的时候就越是要镇静，像无头苍蝇同样乱飞是没有任何效果的。因此我再仔细认真的读了报错信息的每个单词，最后我以为弄清楚error code，也就是 errno.ENOSPC (28)是关键，因此我改成搜索这个错误信息。

原来这个错误的意思在Node.js里是 no space left on device.（设备上无剩余空间），那么在 supervisor 里可能也是相似的，顿时我感受豁然开朗，那么我接下来就是检查磁盘空间了

但是磁盘空间仍然至关充足，我又一次迷惑了。。。就在这时，我忽然想起了不久前看过的一篇介绍 Linux文件系统的文章（说明平时技术的积累也很重要），文章里说磁盘在执行文件系统格式化的时候，会分为三个存储区，分别是：

• 超级块，存储整个文件系统的状态
• 索引节点区，用来存储索引节点
• 数据块区，用来存储文件数据

既然/dev/vdb1的数据块区是有空余的，那么索引节点是否是还有空余的呢？我执行df -hi看了下

/dev/vdb1的IFree 为 0，接下来我又在/data目录里面搜索了下，发现不少历史遗留的日志文件，至此真相大白了。

4. 缘由

之因此蓝鲸进程启动失败的缘由就是/dev/vdb1块设备上的索引节点被大量的日志占用光了，而以前的日志清理脚本并无完全清理干净日志，因此致使有时服务不可用。

0x02 解决

在找到问题的缘由后，我能作的解决方法有两种：

1. 增长/dev/vdb1的索引节点
2. 定时删除/dev/vdb1的日志

在查阅了资料后，我发现方法一须要从新格式化块设备

Do you want to increase the amount of inodes? Either increase the capacity of the disk entirely (Guide: Increase A VMware Disk Size (VMDK) LVM), or re-format the disk using mkfs.ext4 -i to manually overwrite the bytes-per-inode ratio.

因此这个方法是不可接受的。那么我就只能采用定时删除日志的方法了,写了个 crontab 的脚本执行定时任务

至此该问题完全解决

0x03 小结

此次又解决了一个问题，知足了我小小的成就感，然而我以为更重要是我总结出了排查问题的要点：

1. 根据现象分析问题，不要凭直觉下手
2. 不要直接一把梭，干事以前先阅读说明文档，大部分的问题说明文档里都有
3. 遇到问题是常态，不要焦躁，冷静分析
4. 平时多技术积累，也许如今用不到，但总会有用到的时候

0x04 延伸资料

• 理解 Inode
• How To Increase Amount of Disk inodes in Linux（Linux 上如何增长 Inode）