关键词：LVM、ext4、容器运行时、、、、hung task
这篇文章记录了一次典型但很容易被误判的 Linux 系统故障排查过程。问题表面看起来是 / 容器运行时 / 接连报错，但根因其实在底层存储与文件系统一致性。
如果你使用的是：
- LVM
- ext4
- 容器运行时（）
- 曾经发生过非正常关机
那么这篇记录大概率对你有参考价值。
一、问题现象
系统启动或运行过程中，内核和 日志大量刷屏，主要包括：
INFO: task <container-daemon> blocked for more than 362 seconds
<init-system>[1]: Failed to start log service
伴随的实际表现包括：
- 容器运行时 服务无法启动或卡死
- 无法启动，日志系统异常
- 不断重试服务，系统看起来“失控”
- 但系统又并非完全无法启动，还能勉强进入 shell
这类状态非常迷惑，很容易让人误以为是：
- 容器运行时 配置问题
- / 本身损坏
- 某个服务 Bug
实际上都不是。
二、关键信息：hung task
真正重要的只有一条日志：
INFO: task <container-daemon> blocked for more than 362 seconds
这不是 容器运行时 的逻辑错误，而是 Linux 内核的 hung task 检测，含义是：
某个进程（这里是 ）长期处于不可中断状态（D state），通常是在等待 I/O。
一旦出现 hung task：
- 说明问题已经在 内核 / 块设备 / 文件系统层
- 上层服务只是“受害者”
三、环境确认
进一步确认系统结构：
磁盘： 多 TB 级
分区： GPT
文件系统： ext4
存储管理： LVM
容器运行时 存储驱动： <union-filesystem>
根分区： 位于逻辑卷（LV）上
通过命令确认：
vgscan
vgchange -ay
lsblk
得到结果：
/dev/mapper/<vg>-<lv> on / type ext4 (rw,relatime)
关键信息：
出问题的 ext4 文件系统，正是当前已经挂载为
/的根分区。
四、为什么 / / 容器运行时 全部出问题
这是一个典型的因果链：
- 非正常关机（断电 / 强制关闭虚拟机）
- ext4 文件系统产生不一致状态
- 文件系统还能勉强挂载，但 I/O 操作出现阻塞
- 启动需要写磁盘 → 卡死 → 启动失败
- 容器运行时 使用 → 依赖底层 fs → 进入 D 状态
- 反复重试服务 → 日志刷屏
所以：
失败是结果，不是原因；容器运行时 卡死也是结果。
五、一个非常重要的坑：不能在已挂载的根分区 fsck
在问题排查过程中，最危险的一步就是误操作 fsck。
当前状态：
/dev/mapper/<vg>-<lv> on /
意味着：
- 根文件系统已经挂载
- 正在被系统使用
在这种状态下执行：
fsck -f /dev/mapper/<vg>-<lv>
等同于：
对正在运行的系统“拆地基”
高概率直接造成不可逆数据损坏。
六、唯一正确、最低风险的修复方案
1. 进入 Live / Rescue 环境（必须）
目标只有一个：
不让问题逻辑卷被挂载
可以使用：
- Ubuntu 安装 ISO 的 Try 模式
- Rescue 系统
- 任何 Linux Live 环境
2. 在 Live 环境中激活 LVM（不挂载）
vgscan
vgchange -ay
确认逻辑卷未挂载：
lsblk
mount | grep mapper
3. 对 ext4 根卷执行 fsck（核心步骤）
fsck -f /dev/mapper/<vg>-<lv>
注意事项：
- 出现修复提示，一律选择
y - 不要中断
- 不要重启
- 大容量磁盘（如 多 TB 级）耗时较长，耐心等待
七、修复后检查项
重启回系统后，至少确认三点：
- 内核日志是否还有 ext4 错误
dmesg -T | grep -i ext4 - 容器运行时 是否可以正常启动
systemctl start docker systemctl status docker - 是否可用
<log-query-tool> -b | head
如果以上三点正常，说明问题已经从根本解决。
八、经验总结
这次问题不是：
- 坏了
- 容器运行时 坏了
- 配置错了
而是一个非常“现实”的问题：
LVM + ext4 + 容器运行时 + + 非正常关机
这是一个迟早会遇到的组合。
关键经验只有几条：
- hung task 基本就是 I/O 或文件系统问题
- 启动失败，优先怀疑磁盘
- ext4 出问题时，服务层症状非常“混乱”
- 根分区 fsck 一定要在 Live 环境进行
九、延伸思考
如果长期运行 容器运行时、服务多、数据量大：
- 可以考虑把 容器运行时 数据目录单独放一个 LV
- 避免 与根分区强耦合
- 尽量避免强制关机
- 虚拟化环境中，先关客户机，再关宿主机
这些都能显著降低再次遇到同类问题的概率。
这次问题最终是“结构性问题 + 正确工具”解决的典型案例。
希望这篇记录能帮你在遇到类似症状时，少走弯路。