openEuler+Docker真实故障：新容器无法启动，30分钟从崩溃到恢复全记录"

admin
admin
admin
0
文章
0
评论
2026-10-18 13:31:29 网络安全文章 来源：ZONE.CI 全球网 0 阅读模式

cover_image

openEuler+Docker真实故障：新容器无法启动，30分钟从崩溃到恢复全记录

原创

刘军军
刘军军

运维星火燎原

2026年6月6日 00:00
天津

在小说阅读器读本章

去阅读

一、故障现象

1.1 环境信息

  • 操作系统: openEuler 22.03 LTS SP3
  • 内核版本: 5.10.0-136.12.0.89.oe2203sp3.x86\_64
  • Docker版本: 20.10.21 (containerd 1.6.15)
  • 容器编排: Docker Compose 2.12.2
  • 业务应用: 企业级微服务平台（基于Spring Cloud）
  • 部署架构: 3台服务器组成的Docker Swarm集群

1.2 故障表现

[2026-06-01 09:30:00] 业务系统新功能上线，执行滚动更新
[2026-06-01 09:32:00] 发现订单服务容器无法启动
[2026-06-01 09:35:00] 尝试手动启动多个容器都失败
[2026-06-01 09:38:00] 影响范围扩大到用户中心、支付服务等核心服务
[2026-06-01 09:40:00] 启动紧急故障响应流程

1.3 初始错误信息

# 尝试启动容器
$ docker start order-service-1
Error response from daemon: OCI runtime create failed: container_linux.go:380: starting container process caused: process_linux.go:545: container init caused: rootfs_linux.go:76: mounting \"/var/lib/docker/overlay2/abc123456789/diff\" to rootfs at \"/var/lib/docker/overlay2/abc123456789/merged\" caused: invalid argument: unknown
Error: failed to start containers: order-service-1

# 查看容器日志
$ docker logs order-service-1
Error: No such container: order-service-1

# 查看Docker服务状态
$ systemctl status docker
● docker.service - Docker Application Container Engine
     Loaded: loaded (/usr/lib/systemd/system/docker.service; enabled; vendor preset: disabled)
     Active: active (running) since Wed 2026-06-0109:00:00 CST; 42min ago

二、排查过程

步骤1: 检查Docker系统状态

时间: 2026-06-01 09:45:00

# 检查Docker信息
$ docker info
Client:
 Context:    default
 Debug Mode: false
 Plugins:
  app: Docker App (Docker Inc., v0.9.1-beta3)
  compose: Docker Compose (Docker Inc., v2.12.2)

Server:
 Containers: 35
  Running: 28
  Paused: 0
  Stopped: 7
 Images: 125
 Server Version: 20.10.21
 Storage Driver: overlay2
  Backing Filesystem: xfs
  Supports d_type: false
  Native Overlay Diff: false
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: systemd
 Cgroup Version: 2

关键发现: Supports d_type: false - 这是一个严重问题！

步骤2: 检查文件系统和d\_type

时间: 2026-06-01 09:48:00

# 检查文件系统类型
$ df -Th /var/lib/docker
Filesystem              Type  Size  Used Avail Use% Mounted on
/dev/mapper/vg_docker  xfs   500G  420G   80G  84% /var/lib/docker

# 检查d_type支持
$ xfs_info /var/lib/docker | grep ftype
naming   =version 2              bsize=4096   ascii-ci=0, ftype=0

# 检查挂载选项
$ mount | grep /var/lib/docker
/dev/mapper/vg_docker on /var/lib/docker type xfs (rw,relatime,attr2,inode64,noquota)

重要问题: ftype=0 - XFS文件系统没有启用d\_type支持！

步骤3: 查看系统日志

时间: 2026-06-01 09:52:00

# 查看Docker服务日志
$ journalctl -u docker -n100--no-pager

# 关键错误信息
Jun 0109:32:15 node-1 dockerd[12345]: time=\"2026-06-01T09:32:15.123+08:00\"level=error msg=\"Handler for POST /v1.41/containers/order-service-1/start returned error: OCI runtime create failed: container_linux.go:380: starting container process caused: process_linux.go:545: container init caused: rootfs_linux.go:76: mounting \\\"/var/lib/docker/overlay2/abc123456789/diff\\\" to rootfs at \\\"/var/lib/docker/overlay2/abc123456789/merged\\\" caused: invalid argument: unknown\"

# 查看内核日志
$ dmesg -T | tail -50
[Mon Jun  109:32:15 2026] overlayfs: upper fs does not support xattr, falling back to index=off and inodes=off
[Mon Jun  109:32:15 2026] overlayfs: upper fs missing required features.

步骤4: 检查历史变更记录

时间: 2026-06-01 09:58:00

# 查看yum历史
$ yum history
ID     | Command line        | Date and time    | Action(s)      | Altered
-------|---------------------|------------------|----------------|--------
   150 | install xxx        | 2026-06-0108:00 | Install        |    5
   149 | update system      | 2026-05-3010:00 | Update         |   23

# 查看文件系统变更
$ lsblk-f
NAME             FSTYPE      FSVER LABEL UUID                                   FSAVAIL FSUSE% MOUNTPOINTS
sda
├─sda1           xfs                bbb111-cccc-2222-3333-dddd4444
└─sda2           LVM2_member       eee555-ffff-6666-7777-gggg8888
  └─vg_docker  xfs                hhh999-iiii-0000-1111-jjjj2222  80G   84% /var/lib/docker

# 检查LVM操作日志
$ cat /var/log/messages | grep-i\"lvm\\|vgcreate\\|lvcreate\"

发现线索: 凌晨有人重新创建了Docker存储的LVM卷！

步骤5: 验证Overlay2存储驱动

时间: 2026-06-01 10:05:00

# 检查Overlay2是否正常
$ ls -la /var/lib/docker/overlay2/
total 0
drwx--x--x. 1 root root  386 Jun  109:00 .
drwx--x--x. 1 root root  224 Jun  109:00 ..
drwx--x--x. 1 root root  128 Jun  109:00 abc123456789
drwx--x--x. 1 root root  128 Jun  109:00 def987654321

# 查看现有容器的存储
$ docker inspect order-service-1 | jq -r'.[].GraphDriver'
{
  \"Data\": {
    \"LowerDir\": \"/var/lib/docker/overlay2/abc123456789-init/diff:/var/lib/docker/overlay2/def987654321/diff\",
    \"MergedDir\": \"/var/lib/docker/overlay2/abc123456789/merged\",
    \"UpperDir\": \"/var/lib/docker/overlay2/abc123456789/diff\",
    \"WorkDir\": \"/var/lib/docker/overlay2/abc123456789/work\"
  },
  \"Name\": \"overlay2\"
}

# 尝试手动测试Overlay2挂载
$ mkdir -p /tmp/overlay2-test/{lower,upper,work,merged}
$ echo \"test\" > /tmp/overlay2-test/lower/file.txt
$ mount -t overlay overlay -olowerdir=/tmp/overlay2-test/lower,upperdir=/tmp/overlay2-test/upper,workdir=/tmp/overlay2-test/work /tmp/overlay2-test/merged
mount: /tmp/overlay2-test/merged: wrong fs type, bad option, bad superblock on overlay, missing codepage or helper program, or other error.

手动测试也失败了 - 确认是Overlay2驱动问题！

三、根因分析

3.1 故障根因

核心问题: XFS文件系统缺少d\_type支持，导致Overlay2存储驱动无法正常工作

详细过程:

  1. 凌晨运维人员为了扩容，重新创建了/var/lib/docker的LVM卷
  2. 新创建的XFS文件系统使用了错误的参数：ftype=0（默认在某些旧版本是0）
  3. 而Overlay2存储驱动必须要求XFS文件系统开启ftype=1（d\_type支持）
  4. 当Docker尝试启动新容器时，Overlay2无法创建所需的挂载
  5. 旧容器虽然还在运行，但新容器都无法启动
  6. 滚动更新失败，导致服务中断

3.2 技术细节

  • d\_type: \"directory entry type\"，目录项类型，Overlay2需要此功能来高效处理文件
  • Overlay2: Docker默认的存储驱动，依赖d\_type支持
  • ftype=0: XFS文件系统创建时的参数，表示不支持d\_type
  • ftype=1: 支持d\_type，Overlay2的必需条件

四、解决方案

4.1 紧急恢复方案（临时方案）

时间: 2026-06-01 10:15:00

为了快速恢复业务，先切换Docker存储驱动为devicemapper：

# 1. 停止Docker服务
$ systemctl stop docker

# 2. 备份Docker数据（虽然现在有问题）
$ mv /var/lib/docker /var/lib/docker.backup

# 3. 创建临时的XFS文件系统（用于快速恢复）
$ lvcreate-L 100G -n docker-temp vg_docker
$ mkfs.xfs -nftype=1 /dev/vg_docker/docker-temp
$ mount /dev/vg_docker/docker-temp /var/lib/docker

# 4. 修改Docker配置，暂时使用devicemapper
$ cat > /etc/docker/daemon.json << 'EOF'
{
  \"storage-driver\": \"devicemapper\"
}
EOF

# 5. 启动Docker
$ systemctl start docker

# 6. 重新拉取镜像并启动容器
$ docker pull registry.example.com/order-service:v2.1
$ docker-compose -f docker-compose.yml up -d

结果: 业务在15分钟内恢复！

4.2 永久修复方案

时间: 2026-06-01 14:00:00（业务低峰期）

# 1. 停止所有容器和Docker
$ docker-compose -f docker-compose.yml down
$ systemctl stop docker

# 2. 重新创建正确的XFS文件系统
$ umount /var/lib/docker
$ lvremove -y /dev/vg_docker/docker-temp
$ lvremove -y /dev/vg_docker/docker
$ lvcreate -L 500G -n docker vg_docker

# 关键：使用ftype=1创建XFS
$ mkfs.xfs -n ftype=1 /dev/vg_docker/docker

# 3. 挂载并验证
$ mount /dev/vg_docker/docker /var/lib/docker
$ xfs_info /var/lib/docker | grep ftype
naming   =version 2              bsize=4096   ascii-ci=0, ftype=1

# 4. 恢复Docker配置，改回overlay2
$ cat > /etc/docker/daemon.json << 'EOF'
{
  \"storage-driver\": \"overlay2\",
  \"log-driver\": \"json-file\",
  \"log-opts\": {
    \"max-size\": \"100m\",
    \"max-file\": \"3\"
  }
}
EOF

# 5. 从备份恢复镜像和容器（或者重新拉取）
# 这里选择重新拉取，更干净

# 6. 启动Docker
$ systemctl start docker

# 7. 拉取所有镜像
$ docker-compose -f docker-compose.yml pull

# 8. 启动所有服务
$ docker-compose -f docker-compose.yml up -d

# 9. 设置开机自动挂载
$ blkid /dev/vg_docker/docker
/dev/vg_docker/docker: UUID=\"kkk3333-llll-4444-5555-mmmm6666\"TYPE=\"xfs\"

$ echo'UUID=\"kkk3333-llll-4444-5555-mmmm6666\" /var/lib/docker xfs defaults 0 0' >> /etc/fstab

五、验证测试

5.1 Docker系统验证

# 验证Overlay2和d_type
$ docker info | grep -A 5 -B 5 \"Supports d_type\"
 Storage Driver: overlay2
  Backing Filesystem: xfs
  Supports d_type: true
  Native Overlay Diff: true
  userxattr: false

# 验证文件系统
$ xfs_info /var/lib/docker | grep ftype
naming   =version 2              bsize=4096   ascii-ci=0, ftype=1

# 测试创建容器
$ docker run --rm -it alpine echo\"Test container created successfully\"
Test container created successfully

5.2 业务应用验证

# 检查所有容器状态
$ docker-compose -f docker-compose.yml ps
NAME                      COMMAND                  SERVICE             STATUS              PORTS
order-service-1           \"java -jar /app/ord…\"   order-service       running             0.0.0.0:8080->8080/tcp
user-center-1             \"java -jar /app/user…\"   user-center         running             0.0.0.0:8081->8081/tcp
payment-service-1         \"java -jar /app/pay…\"   payment-service     running             0.0.0.0:8082->8082/tcp

# 检查服务健康
$ curl http://localhost:8080/actuator/health
{\"status\":\"UP\"}

# 验证业务功能
$ curl -X POST http://localhost:8080/api/orders \\
  -H\"Content-Type: application/json\" \\
  -d'{\"userId\":1,\"productId\":1001,\"quantity\":2}'
{\"orderId\":10001,\"status\":\"created\"}

六、预防措施

6.1 技术预防

  1. 创建XFS文件系统标准操作指南

```
# 正确创建Docker存储的XFS文件系统
mkfs.xfs -nftype=1 /dev/your-device

# 验证ftype
xfs_info /mountpoint | grep ftype
# 期望输出: ftype=1
```
2. Docker部署检查清单

  • 检查存储驱动配置
  • 验证文件系统d\_type支持
  • 测试创建和删除容器
  • 配置监控告警
  1. 自动化检查脚本

```
#!/bin/bash
# Docker存储检查脚本

echo \"=== Docker Storage Check ===\"

# 检查Docker信息
docker info > /tmp/docker-check.txt

# 检查d_type
D_TYPE=$(docker info 2>/dev/null | grep \"Supports d_type\" | awk '{print $NF}')

if [ \"$D_TYPE\"=\"true\" ]; then
    echo\"✓ d_type support: OK\"
else
    echo\"✗ d_type support: FAILED!\"
    exit1
fi

# 检查文件系统
FS_TYPE=$(df -Th /var/lib/docker | awk 'NR==2{print $2}')
echo\"File System: $FS_TYPE\"

if [ \"$FS_TYPE\"=\"xfs\" ]; then
    FTYPE=$(xfs_info /var/lib/docker 2>/dev/null | grep -oP 'ftype=\K\d+')
    if [ \"$FTYPE\"=\"1\" ]; then
        echo \"✓ XFS ftype=1: OK\"
    else
        echo \"✗ XFS ftype not equal to 1: FAILED!\"
        exit 1
    fi
fi

echo \"=== All checks passed! ===\"
exit0
```

6.2 流程改进

  1. 变更审批流程
  • 任何生产环境文件系统变更必须经过审批
  • 变更前必须有完整的回滚方案
  1. 运维操作标准化
  • 创建标准操作手册（SOP）
  • 定期进行运维技能培训
  1. 监控告警
  • 监控Docker服务健康状态
  • 监控文件系统使用情况
  • 配置容器启动失败告警

七、经验总结

7.1 关键教训

  1. 存储驱动选择至关重要
  • Overlay2是Docker推荐的驱动，但有文件系统要求
  • 生产环境部署前必须验证存储驱动兼容性
  1. 文件系统参数不可忽视
  • XFS的ftype参数是Overlay2的必需条件
  • 重新创建文件系统时要使用正确的参数
  1. 变更操作风险大
  • 即使是看似简单的扩容操作，也可能导致严重问题
  • 变更前、中、后都要进行充分的测试和验证
  1. 应急预案要常备
  • 准备多个恢复方案（临时方案、永久方案）
  • 定期进行灾难恢复演练

7.2 成功因素

  1. 快速定位问题
  • 从Docker info的输出中立即发现了关键线索
  • 系统日志提供了重要佐证
  1. 分层恢复策略
  • 先用临时方案快速恢复业务
  • 再在业务低峰期进行永久修复
  • 最小化业务影响时间
  1. 充分的验证测试
  • 从Docker系统到应用业务逐层验证
  • 确保问题真正解决

7.3 改进方向

  1. 基础设施即代码(IaC)
  • 使用Terraform、Ansible等工具管理基础设施
  • 避免手动操作导致的人为错误
  1. 存储架构优化
  • 考虑使用更稳定的存储方案
  • 做好存储容量规划和监控
  1. 知识沉淀
  • 将此次故障经验整理成案例
  • 培训团队，避免类似问题再次发生

附录

A. 相关命令参考

命令 说明
docker info 查看Docker系统信息
docker logs <container> 查看容器日志
journalctl -u docker 查看Docker服务日志
dmesg 查看内核日志
xfs_info <mountpoint> 查看XFS文件系统信息
df -Th 查看文件系统信息
mkfs.xfs -n ftype=1 <device> 创建支持d\_type的XFS文件系统
docker inspect <container> 查看容器详细信息

B. 参考文档

  • Docker Overlay2 Storage Driver Documentation
  • openEuler Docker Deployment Guide
  • XFS Filesystem and d\_type
  • Docker Troubleshooting Guide

版权声明

本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。

ZONE.CI 全球网 | 安全领域涉猎者-乌云独行地带
ZONE.CI 全球网
安全领域涉猎者-乌云独行地带
承接中情局MKULTRA计划的核心机构" 网络安全文章

承接中情局MKULTRA计划的核心机构"

本文基于开源情报梳理了中情局MKULTRA心智控制计划的核心执行网络。该计划将极端人体实验外包至全美80余家实体，涵盖哈佛等常春藤学阀、公立大学系统、礼来等医药寡头及德特里克堡等军医惩教机构。文章揭露了西方顶尖学术与医疗体系沦为心理摧毁与生化测试温床的历史真相，为审视美式国家暴力提供了深度情报视角。
10-180 评论
炸裂！这款BurpSuite插件让指纹识别效率提升1000%，实战渗透工程师直呼内行" 网络安全文章

炸裂！这款BurpSuite插件让指纹识别效率提升1000%，实战渗透工程师直呼内行"

本文介绍BurpFingerPrint，一款基于Java9+的BurpSuite被动指纹识别插件。它集成Ehole指纹库，支持OA系统、网络设备等资产识别，具备URL提取、指纹库热更新及Tomcat弱口令爆破功能。采用线程池并发处理与SQLite持久化存储，适用于攻防演练与授权渗透测试的信息收集阶段。文章末尾包含商业推广内容。
10-180 评论
ZONE.CI 全球网 | 安全领域涉猎者-乌云独行地带
安全领域涉猎者-乌云独行地带
ZONE.CI 全球网
评论：0   参与：  0