systemctl命令直接罢工，竟是系统空间惹的祸

系统突然罢工

最近在维护一台老服务器，需要重启某个服务。按照平时的习惯，执行了个很常规的命令：

systemctl restart nginx

结果系统直接给我来了个：

No space left on device

我当时就懵了，重启个服务跟磁盘空间有啥关系？而且其他命令都正常，就是systemctl相关的命令全部报这个错。

第一反应：检查磁盘空间

看到"No space left on device"，第一反应当然是检查磁盘使用情况：

df -h

image-20240829110158445

结果一看，磁盘使用率才70%多，还有几个G的空闲空间。这就奇怪了，明明有空间，为什么还说没空间？

开始系统性排查

磁盘空间明明够用，那"No space left on device"到底是什么原因？我开始一个个排查可能的原因。

检查文件描述符使用情况

# 查看当前打开的文件描述符数量
lsof | wc -l

# 查看文件描述符限制
ulimit -n

image-20240829110305836

从结果可以看到：

• 当前系统打开了122473个文件描述符
• 限制是200001

这说明文件描述符使用率约61%，还算正常，不是导致问题的原因。

检查inode使用情况

df -i

一查发现问题了：某些分区的inode使用率接近100%！

原来如此，系统想创建临时文件的时候，虽然磁盘空间够，但inode用完了，当然就创建不了文件，自然就报"No space left on device"。

解决inode问题

找到原因了，就开始清理那些占用大量inode的小文件：

# 清理大量的小日志文件
find /var/log -name "*.log.*" -mtime +7 -delete

# 清理systemd日志
journalctl --vacuum-time=7d
journalctl --vacuum-size=500M

# 清理临时文件
rm -rf /tmp/*

清理完之后，再检查inode使用情况：

image-20240829110443809

看到这个结果就放心了，inode使用率已经降下来了，系统应该能正常工作了。

顺便优化其他参数

既然都排查到这里了，顺便把其他几个相关的系统参数也优化一下。

调整文件描述符限制

# 临时调整
ulimit -n 65536

# 永久生效，编辑limits.conf
sudo vim /etc/security/limits.conf
# 添加：
* soft nofile 65536
* hard nofile 65536

调整文件监视器限制

# 临时调整
echo 262144 > /proc/sys/fs/inotify/max_user_watches

# 永久生效
echo 'fs.inotify.max_user_watches = 262144' >> /etc/sysctl.conf
sysctl -p

这个参数控制每个用户能创建多少个文件监视器。像一些前端开发工具（webpack等）、文件同步软件都会用到文件监视功能，限制太小会影响它们正常工作。

验证修复结果

所有参数调整完之后，再次尝试执行systemctl命令：

systemctl restart nginx
systemctl status nginx

这次就正常了！不再报"No space left on device"错误。

这次故障的收获

"No space left on device"不只是磁盘满了

这是我最大的收获。以前遇到这个错误，就只会想到清理磁盘空间。现在才知道还有这么多其他可能的原因：

• inode用完了
• 文件描述符限制太小
• 文件监视器不够用
• 可能还有磁盘配额等其他原因

小文件是inode杀手

大量的小文件比几个大文件更容易耗尽inode。特别是日志文件，如果轮转策略不合理，很容易产生成千上万个小日志文件。

系统参数要适当调整

默认的系统参数往往比较保守，对于跑了很多服务的服务器来说可能不够用。适当调整这些参数能避免很多莫名其妙的问题。

现在我的服务器巡检脚本里加了inode检查，再也不想遇到这种"明明有空间却说没空间"的诡异问题了😅