直接查看docker守护进程日志是定位容器启动失败深层原因最有效的方式，它记录引擎拉取镜像、创建容器、挂载文件系统等全过程错误，尤其适用于docker logs为空的场景；linux推荐journalctl -u docker.service，macos/windows通过docker desktop导出日志包；重点grep failed to start container、no such file or directory、permission denied等关键词，并结合docker inspect验证exitcode与state.error。
直接看 Docker 守护进程日志，是定位容器启动失败深层原因最有效的方式之一。它不依赖容器是否成功创建，而是记录了 Docker 引擎本身在拉取镜像、创建容器、挂载文件系统、分配网络、启动进程等全过程中的决策和错误。很多容器“连日志都看不到”（docker logs 报错或为空），恰恰说明问题出在容器尚未真正进入运行阶段——这时守护进程日志就是唯一线索。
守护进程日志在哪？不同系统位置不同
Linux 系统（主流）：
-
/var/log/docker.log（部分发行版单独存在） - 更常见的是整合进系统日志：
journalctl -u docker.service（推荐，实时性强、带时间戳和优先级）
macOS / Windows（Docker Desktop）：
- 通过桌面应用菜单 → Support → Export Logs 获取完整日志包
- 或打开日志查看器：
~/.docker/daemon.json配置后可指定日志驱动，但默认路径需从导出包中查找dockerd.log
重点搜索哪些关键词和模式？
不要通读，用 grep 快速过滤关键信号：
OpenClaw Docker Setup
下载
在 Linux 上通过 Docker 运行 OpenClaw，并使用 Tailscale 实现远程访问。⚠️ 涉及 sudo、Docker、Tailscale和凭证挂载——请先查阅安全章节...
-
failed to start container：明确指出启动失败的容器 ID 和上下文 -
no such file or directory：常指向挂载路径不存在、Dockerfile 中COPY源路径错误、或 volume 主机路径权限/拼写问题 -
permission denied：SELinux/AppArmor 拒绝、用户命名空间冲突、或 bind mount 目录缺少exec权限 -
port is already allocated或address already in use：端口冲突，但注意：这是守护进程层面的绑定失败，比应用层报错更早 -
invalid reference format或pull access denied：镜像名解析失败，可能因私有仓库未登录、标签写错（如latest被删）、或镜像仓库不可达 -
devicemapper/overlay2相关错误：存储驱动异常，常见于磁盘满、inode 耗尽、或文件系统损坏（df -h和df -i必查）
结合 docker inspect 看失败现场状态
即使容器已退出，docker inspect 仍保留其元数据和失败快照：
-
"Status": "exited"+"ExitCode": 127：典型命令未找到（如CMD ["sh", "start.sh"]但脚本不存在） -
"State": {"Error": "..."}：守护进程写入的失败原因，和日志内容高度一致，可交叉验证 -
"Mounts"段检查 hostPath 是否真实存在、"NetworkSettings"看 IP 分配是否卡在waiting for IP
实战技巧：让日志更易读
临时启用详细日志级别（重启 dockerd 后生效）：
- 编辑
/etc/docker/daemon.json，加入：
{"log-level": "debug"} - 重启服务：
sudo systemctl restart docker - 再复现问题，用
journalctl -u docker.service --since "1 minute ago" -f实时跟踪
注意：debug 日志量大，排查完建议调回 info 级别。
