Linux下Docker安装后无法启动，常见原因有哪些？

Question

Linux下Docker安装后无法启动，常见原因包括：1）系统内核版本过低（<3.10）或未启用cgroups、namespaces等必需特性；2）SELinux或AppArmor策略限制容器运行（如CentOS/RHEL中SELinux enforcing模式冲突）；3）Docker服务依赖的`containerd`或`runc`二进制缺失/损坏；4）`/var/lib/docker`目录权限异常或磁盘空间/Inode耗尽；5）systemd服务配置错误（如`docker.service`中`ExecStart`路径指向不存在的二进制）；6）与已运行的其他容器引擎（如Podman、cri-o）端口或套接字冲突；7）防火墙或安全模块拦截`dockerd`监听的`unix:///var/run/docker.sock`。排查建议：执行`sudo systemctl status docker`查看即时错误，结合`journalctl -u docker -n 50 -f`定位日志关键报错，再针对性验证内核参数、存储驱动兼容性及依赖服务状态。

Answer 1

```html

一、现象确认：基础服务状态诊断

首次排查必须跳过“直觉修复”，先获取权威状态快照：

sudo systemctl status docker --no-pager
sudo systemctl is-active docker
sudo systemctl is-enabled docker

若显示 inactive (dead) 或 failed，立即捕获实时日志流：

journalctl -u docker -n 100 -o short-precise --no-hostname | tail -n 20

注意识别首行报错关键词（如 cgroups not mounted、permission denied、containerd: command not found），这将决定后续排查路径。

二、内核与运行时基石验证

Linux容器依赖内核原语，非可选特性。执行以下原子级检测：

检测项	命令	预期输出
内核版本 ≥ 3.10	uname -r	5.10.0-28-amd64 或更高
cgroups v1/v2 挂载状态	mount | grep cgroup	至少含 cgroup2 on /sys/fs/cgroup 或多个 cgroup 子系统
namespaces 支持检查	grep -w "namespaces\|user_namespaces" /proc/config.gz 2>/dev/null || zcat /proc/config.gz 2>/dev/null | grep -i namespace	输出含 CONFIG_NAMESPACES=y 等关键条目

若内核过旧或关键配置为 =n 或未编译，需升级内核或启用 GRUB_CMDLINE_LINUX="cgroup_enable=memory swapaccount=1" 并更新 grub。

三、安全模块冲突深度分析

SELinux（RHEL/CentOS）与 AppArmor（Ubuntu/Debian）常静默拦截 dockerd 的 socket 绑定与 capability 请求。验证路径：

• SELinux：运行 sudo sestatus；若为 enforcing，临时切换为 permissive：sudo setenforce 0，再启动 Docker 测试
• AppArmor：检查 aa-status 输出是否加载 dockerd profile；缺失则执行 sudo apparmor_parser -r /etc/apparmor.d/usr.bin.dockerd
• 日志线索：journalctl -t audit -n 50 | grep -i 'avc.*docker\|apparmor.*denied'

生产环境不可长期禁用 SELinux/AppArmor，应生成定制策略：ausearch -m avc -ts recent | audit2allow -a -M docker_local，再 sudo semodule -i docker_local.pp。

四、容器运行时依赖链完整性审计

Docker 已演进为 dockerd → containerd → runc 三层架构。任一环节断裂即导致启动失败：

# 验证二进制存在性与权限
ls -l /usr/bin/{dockerd,containerd,runc}
# 检查 containerd 是否运行（Docker 启动前必须就绪）
sudo systemctl status containerd
# 手动触发 runc 自检
sudo runc --version 2>/dev/null || echo "runc missing"
# 强制重载 containerd 配置
sudo systemctl daemon-reload && sudo systemctl restart containerd

若 containerd 报 failed to load plugin io.containerd.grpc.v1.cri，需检查 /etc/containerd/config.toml 中 disabled_plugins 是否误禁了关键插件。

五、存储层健康度与权限拓扑

/var/lib/docker 是 Docker 的“心脏组织”，其异常直接阻断初始化：

1. 磁盘空间：df -h /var/lib/docker —— 要求 ≥ 2GB 可用
2. Inode 耗尽：df -i /var/lib/docker —— 若 Use% 达 100%，执行 find /var/lib/docker -xdev -type f | head -1000 | xargs ls -la 定位小文件风暴源
3. 权限拓扑：sudo ls -ld /var/lib/docker /var/run/docker.sock 应为 root:root 且目录权限 ≤ 711，socket 权限为 660
4. 存储驱动兼容性：docker info | grep "Storage Driver"；若为 overlay2 但内核 < 4.0，需在 /etc/docker/daemon.json 显式指定 "storage-driver": "vfs"（仅调试用）

严重损坏时，可安全迁移数据：sudo systemctl stop docker && sudo mv /var/lib/docker /var/lib/docker.bak && sudo mkdir /var/lib/docker && sudo chown root:root /var/lib/docker，再启动验证基础功能。

六、服务声明与生态共存性校验

systemd 单元文件错误或容器引擎“生态竞争”是高阶故障源：

graph LR A[docker.service] --> B{ExecStart=/usr/bin/dockerd
--containerd=/run/containerd/containerd.sock} B --> C[/run/containerd/containerd.sock exists?] B --> D[/usr/bin/dockerd binary exists?] C -->|No| E[Start containerd first] D -->|No| F[Reinstall docker-ce-cli package] A --> G[Is Podman running?] G -->|Yes| H[killall podman && rm -f /run/podman/podman.sock]

检查 sudo systemctl cat docker 输出的 ExecStart 路径是否真实存在；同时运行 ss -ltnp | grep ':2376\|2375' && ls /run/*.sock | grep -E 'podman|crio|containerd' 排查 Unix socket 冲突。Podman 默认监听 /run/podman/podman.sock，但若用户手动启用了 podman system service，其 TCP 端口会与 Docker 冲突。

```