一次 GitLab 无法启动的排查:Docker 日志把 500G 磁盘打满
一、问题现象
重启 GitLab 容器时报错:
bash
Error response from daemon: Cannot restart container gitlab:
open /data/docker/containers/.../.tmp-resolv.conf.hash: no space left on device
第一眼看起来像:
- GitLab 容器损坏
- Docker 崩溃
- 网络异常
但真正的核心报错只有一句话:
no space left on device
二、第一步:确认磁盘状态
执行:
bash
df -h
结果:
bash
/dev/vdb 500G 500G 260K 100% /data
结论:
/data磁盘 500G 已经 100% 打满。
而 Docker 数据目录就在:
bash
/data/docker
三、第二步:定位大目录
bash
du -sh /data/* | sort -rh
结果:
bash
354G /data/docker
97G /data/ai_iot
7.3G /data/gitlab
可以看到:
Docker 占用了 354G。
四、第三步:继续细分 Docker 目录
bash
du -sh /data/docker/* | sort -rh
结果:
bash
204G /data/docker/containers
149G /data/docker/overlay2
关键问题找到了:
/data/docker/containers占用了 204G。
五、containers 目录是什么?
这个目录主要存储:
bash
/data/docker/containers/<container_id>/*-json.log
也就是:
Docker 容器运行日志文件
Docker 默认使用 json-file 作为日志驱动:
- 不限制日志大小
- 不自动轮转
- 持续追加写入
如果是 CI 服务,比如:
- GitLab
- GitLab Runner
构建日志会非常巨大。
六、确认具体日志文件
可以查看最大日志:
bash
ls -lh /data/docker/containers/*/*-json.log | sort -k5 -rh | head
通常会发现某个容器日志达到几十甚至上百 GB。
七、紧急处理方案(安全)
清空日志:
bash
truncate -s 0 /data/docker/containers/*/*-json.log
特点:
- ✅ 不删除容器
- ✅ 不删除数据
- ✅ 不影响运行
- ✅ 立即释放空间
执行后:
bash
df -h
会看到磁盘空间立即恢复。
然后重启容器:
bash
docker restart gitlab
八、根本原因
Docker 默认日志策略:
text
log-driver: json-file
无大小限制
无轮转
无限增长
时间一长必然爆盘。
九、长期解决方案(必须做)
编辑:
bash
/etc/docker/daemon.json
加入:
json
{
"log-driver": "json-file",
"log-opts": {
"max-size": "100m",
"max-file": "3"
}
}
然后重启 Docker:
bash
systemctl restart docker
效果:
- 单个日志文件最大 100MB
- 最多保留 3 个
- 自动轮转
- 不会再爆盘
十、经验总结
这次问题本质不是:
- ❌ GitLab 损坏
- ❌ 容器崩溃
- ❌ Docker Bug
而是:
Docker 日志无限增长导致磁盘打满。
排查思路总结:
- 先看
df -h - 找最大目录
du -sh - 定位 Docker 子目录
- 判断是 overlay / image / containers
- 针对性处理
十一、推荐运维建议
如果服务器长期运行:
- 必须设置 Docker 日志限制
- 定期执行
docker system prune - 监控磁盘使用率
- 对 CI 构建日志进行控制
否则爆盘只是时间问题。
结语
这类问题非常常见,但容易被误判为:
- GitLab 故障
- Docker 崩溃
- 容器异常
其实 90% 的情况只是:
磁盘满了。
希望这次排查过程能帮到遇到类似问题的人。