docker exec 常因容器内缺失 shell（如 distroless 无 /bin/sh，Alpine 只有 /bin/ash）而失败；应先用 ls 或 cat /etc/os-release 探查可用 shell，对无 shell 容器改用 --volumes-from 调试或导出 rootfs 分析。
docker exec 命令的基本用法和常见失败原因
直接运行 docker exec -it <container_id_or_name> /bin/sh</container_id_or_name> 是最常用方式，但经常卡住或报错，核心原因是容器内没装 /bin/sh 或 /bin/bash。Alpine 镜像默认只有 /bin/ash，而某些极简镜像（如 distroless）甚至完全不带 shell。遇到 OCI runtime exec failed: exec failed: no such file or directory 就是这个原因。
- 先确认容器是否还在运行：
docker ps，停掉的容器无法 exec - 查镜像基础：运行
docker inspect <container_id> | grep -i image</container_id>，看是不是 Alpine、scratch 或 distroless - 尝试更轻量的 shell：Alpine 用
/bin/ash，Debian/Ubuntu 优先试/bin/bash，不行再退到/bin/sh - 如果容器启动时用了
--entrypoint或覆盖了 CMD，exec 仍以原镜像的文件系统为准，和入口命令无关
如何判断容器里到底有没有可用 shell
不能靠猜，得用 docker exec 自身探路。关键是利用 ls 或 cat /etc/os-release 这类几乎必然存在的命令来试探文件系统结构。
- 先快速检查是否存在常见 shell：
docker exec <container_id> ls -l /bin/sh /bin/bash /bin/ash 2>/dev/null</container_id> - 看发行版：
docker exec <container_id> cat /etc/os-release 2>/dev/null | head -n 3</container_id>，输出含Alpine就用/bin/ash - 对 distroless 容器，
docker exec <container_id> ls /</container_id>往往直接报错 —— 此时 exec 不可行，只能改用docker run --volumes-from挂载调试工具临时容器 - 注意权限：有些容器以非 root 用户运行，
docker exec -u root可能因用户不存在或无权限失败
调试时保持环境一致性：-it 和 --user 的实际影响
-it 不只是为了交互，它会分配伪 TTY 并保持 STDIN 打开；缺 -t 可能导致某些命令（如 top、vim）异常退出，缺 -i 则无法输入。但加了 -it 后，容器内进程的 stdin、stdout、stderr 会被重定向到当前终端，可能干扰原进程日志流。
- 调试只读信息（如查日志、看进程）：用
docker exec <container_id> ps aux</container_id>，不加-it更干净 - 需要交互式操作（编辑配置、抓包）：必须
-it，且建议加--user root（如果容器允许）避免权限拒绝 - 若容器启动时指定了
--user 1001，exec 时又不指定--user，则继承容器默认用户，不一定有权限执行apt或写/tmp - 某些安全加固镜像禁用了 TTY 分配，此时
-t会失败，只能用-i+ 单条命令组合
替代方案：当 docker exec 完全不可用时怎么办
exec 失败不等于无法调试。核心思路是复用容器的根文件系统（rootfs），在新容器中加载相同环境。
- 导出容器文件系统：
docker export <container_id> | tar -C /tmp/debug-root -xf -</container_id>，然后chroot /tmp/debug-root /bin/sh（需宿主机有对应架构支持） - 更可靠的做法：启动一个调试镜像，挂载原容器的卷和 rootfs：
docker run -it --volumes-from <container_id> -v /var/lib/docker/aufs/mnt/<id>:/target alpine sh</id></container_id>（路径依存储驱动而异，需先docker inspect <container_id> | grep GraphDriver</container_id>确认） - 对于 Kubernetes 场景，优先用
kubectl debug（需 v1.20+）或ephemeral containers，比硬进节点查 overlay2 更安全 - 长期建议：构建镜像时显式包含调试工具（如
strace、curl、netstat），或用multi-stage build在最终镜像里保留最小调试层
真正麻烦的不是 exec 命令本身，而是容器启动后进程已脱离原始上下文 —— PID namespace、network namespace、mount namespace 都已固化，exec 只是开了个新进程进去，别指望它能重启服务或修改 init 进程行为。
