解决 docker engine 常见报错的核心在于区分错误类型并查看对应的日志。遇到报错时，应优先使用 docker logs <container_id></container_id> 查看容器标准输出，使用 journalctl -u docker.service 查看守护进程日志，并根据具体错误码（如权限拒绝、端口冲突、镜像缺失）采取相应措施。
permission denied` 或 `cannot connect to the Docker daemon` 怎么解
这类错误通常是因为当前用户没有权限访问 Docker 守护进程的 Unix Socket，或者守护进程未启动。解决方法是检查 docker.sock 的权限或使用 sudo 提权，同时确保服务正在运行。
systemctl status docker ls -l /var/run/docker.sock docker info
如果 docker info 返回连接被拒绝，说明守护进程未运行。执行 sudo systemctl start docker 启动服务。若权限问题持续，需将当前用户加入 docker 组： sudo usermod -aG docker $USER，然后重新登录生效。
容器启动失败且无日志输出怎么排查
当容器启动后立即退出且 docker logs 为空时，通常是入口点命令执行失败或配置错误。此时需要查看 docker inspect 的输出，重点关注 State 和 LogPath 字段，以确认退出码和日志存储位置。
Docker Hub (hub.docker.com)。此技能适用于所有 Docker Hub 操作，包括读取、创建、更新和删除数据。只要任务涉及 Docker Hub，就使用此技能。
docker inspect <container_id> | grep -A 5 "State"
docker inspect <container_id> | grep "LogPath"
cat $(docker inspect --format='{{.LogPath}}' <container_id>)
通过 inspect 获取的退出码（ExitCode）能指示故障原因。例如，退出码 1 通常表示应用内部错误，而退出码 137 表示被 OOM Kill。结合 LogPath 直接读取底层日志文件，可以绕过 docker logs 的缓冲限制，获取更完整的崩溃现场信息。
如何根据 docker ps 中的状态码定位具体故障
docker ps 显示的状态（如 Exited, Dead, Restarting）是故障分类的关键依据。不同的状态对应不同的诊断路径，例如 Restarting 往往意味着健康检查失败或主进程崩溃重启。
对于 Exited 状态的容器，重点检查退出码；对于 Dead 状态，通常涉及 Docker 守护进程本身的异常或资源耗尽。通过组合使用 docker ps -a 和 docker inspect，可以快速缩小问题范围，避免盲目重启。
