docker exec 报容器 is paused：命令不会等待解除暂停

容器在 docker ps 中还显示 Up，执行 docker exec 却返回：

Container example-app is paused, unpause the container before exec

继续看状态栏，通常还能看到 (Paused)。这是容器进程被冻结的状态，不是应用已经退出。当前 Docker 的 exec 会直接失败，不会把命令留在队列里等容器恢复。

本文针对 Docker 管理的 Linux 容器。Windows 的暂停支持有额外限制，不能据此推断所有 Windows 容器都能执行相同流程。

先确认同一个容器的状态

下面都是只读检查，example-app 替换为目标容器名称或 ID：

docker ps -a --no-trunc
docker inspect --type container   --format 'status={{.State.Status}} running={{.State.Running}} paused={{.State.Paused}}'   example-app

以目标 ID 和 Paused 字段为准，不要只扫一眼 Up。如果状态已经变成 exited 或 restarting，应按新的状态排查；反复添加 -it、--user root 或 --privileged 不会解除暂停。

Linux 上，docker pause 暂停指定容器中的所有进程，使用 freezer cgroup 机制。它不是让主进程正常退出，也不是让应用完成一次配置重载。连接请求和后台工作可能因此停住，外部客户端也可能已经超时。

解除暂停前确认维护流程已经结束

先检查暂停是否属于备份、快照或其他维护步骤。如果另一个流程仍依赖进程不再写入数据，提前恢复可能破坏它需要的状态。应在那个流程允许恢复后，操作同一个容器，而不是另外启动一个共享数据目录的替代容器。

确认可以继续运行时：

docker unpause example-app

这会恢复已暂停的进程，不是重建容器或重新执行入口。它不修改镜像、环境变量和挂载定义，也不能替代一次配置变更需要的重新部署。

不要为了执行一条诊断命令直接删除容器或重启 Docker 守护进程。那会扩大影响范围，且没有针对 paused 状态本身的必要性。

恢复后重新发出失败的命令

先再次确认状态：

docker inspect --type container --format '{{.State.Status}} paused={{.State.Paused}}' example-app
docker logs --tail 60 example-app

期望暂停标记变为 false，并且主进程继续处于预期状态。日志可能包含业务信息，应在受控终端检查；应用如果本来不写标准输出，空日志不能证明它没有运行。

之前失败的 exec 不会在此时自动补执行。需要诊断时重新发出原命令，并确认该程序确实存在于镜像中。只要主进程后来又退出，exec 仍会失败，因此应按新的报错继续判断，不能把所有失败都归因于暂停。

最后核对应用健康检查、一次受控请求或任务处理状态。解除冻结不保证外部连接仍有效，也不保证客户端没有重试请求；涉及写操作时，应按应用的幂等与重试规则处理，避免手工重复提交业务命令。

如果恢复过程暴露新的应用错误，保留日志并按原维护方案处理。再次暂停会重新中断进程执行，并不是通用回退按钮；只有维护方案明确需要冻结时，才恢复该状态。单纯解除暂停不需要删除数据或重建存储。