写在前面

幽灵容器现象本质上是 Docker 内存状态、磁盘元数据目录与内核挂载点 三者之间失去同步导致的“逻辑死锁”。
如果容器频繁进行大量的 IO 操作（比如写日志、写传感器数据），而刚好遇到一次意外断电或系统 OOM（内存溢出），文件系统的 Journal（日志） 可能会损坏

解决方案总结如下：

0. 先查看幽灵容器的完整id

守护进程关了就看不了了，需要先看一眼

# 查看目标幽灵容器的简写id
docker ps -a
# 查看完整id
docker ps -a --no-trunc | grep <填写简写id>

1. 彻底切断守护进程

只停止 docker.service 是不够的，必须同时停掉 socket 激活器，防止手动删除时文件被占用。

systemctl stop docker.socket
systemctl stop docker

2. 定位并物理删除元数据

Docker 所有的容器定义都存储在 /var/lib/docker/containers/。直接删除对应 ID 的文件夹即可强行抹除它的存在证据。

# 替换为你的完整 Container ID
rm -rf /var/lib/docker/containers/<CONTAINER_ID>

3. 清理残留挂载点（可选但重要）

有时容器退出了，但 OverlayFS 挂载点还在内核里。如果重启 Docker 后依然报错，需检查：

mount | grep <CONTAINER_ID>
# 如果有输出，执行卸载
umount /var/lib/docker/overlay2/<ID>/merged

4. 重启并同步状态

重新启动 Docker，它会扫描本地目录并重建内部索引。

systemctl start docker.socket
systemctl start docker

番外 (针对嵌入式linux)

由于嵌入式linux开发板经常使用 SD 卡或 eMMC 存储，这种“幽灵容器”的频繁出现往往是底层预警：

• 异常掉电：ARM 开发板如果直接拔插电源，极易导致 Ext4 文件系统日志损坏，建议增加 UPS 或养成 shutdown -h now 的习惯。
• IO 瓶颈：如果程序写日志非常频繁，建议将日志目录挂载到 内存（tmpfs） 或外接的 SSD 上，减少对 SD 卡元数据区的损耗。
• 健康检查：

定期执行 dmesg -T | grep -i "error"。如果看到 I/O error 字样，说明存储介质临近损毁，需趁早备份数据。