宿主机无法关机本质是内核shutdown卡在卸载阶段，因容器进程或内核模块长期持有bind mount、volume或NFS挂载点，导致umount无限等待；需通过systemctl list-jobs定位pending umount任务，用findmnt -D和fuser -v排查busy路径及占用进程，执行umount -l懒卸载、stop docker服务或双force poweroff强制推进，并通过rprivate传播、hard NFS参数及合理stop-timeout预防。
宿主机无法关机，但容器仍在运行或挂载点残留，本质是内核在 shutdown 流程中卡在卸载阶段——尤其是当某个 bind mount、volume 或 nfs 挂载点被容器进程、子进程或内核模块长期持有时，umount 会无限等待，导致 systemd 停在 reached target shutdown 或卡在 unmounting /var/lib/docker 类似位置。
确认是否真由容器挂载点引发死锁
登录 TTY（Ctrl+Alt+F2），避开图形界面干扰后执行：
- 查看关机卡在哪一步：
systemctl list-jobs，若存在umount类 job 长时间 pending，说明卸载阻塞 - 检查哪些路径处于 busy 状态：
findmnt -D | grep -E "(docker|kubelet|bind|nfs)" - 定位占用进程：
fuser -v /var/lib/docker /var/lib/kubelet/pods或lsof +D /var/lib/docker/volumes - 特别注意 D 状态进程：
ps aux | awk '$8 ~ /^D/ {print}'，常见于 NFS 卡死、overlay2 元数据异常或未响应的 mount namespace
快速释放挂载点并推进关机
不重启也能解困，关键是绕过“必须等进程退出”的内核语义：
- 对已停止但挂载未清理的容器 volume：执行
sudo umount -l /var/lib/docker/volumes/<vol-name>/_data（-l 表示 lazy 卸载，立即断开用户空间可见性） - 对 bind mount 路径（如
/host/data）被 shell 或编辑器卡住：先用ls -l /proc/*/cwd 2>/dev/null | grep "/host/data"找出 PID，再kill -9 PID - 若
/var/lib/docker整体 busy，可临时停掉 dockerd：sudo systemctl stop docker，再尝试umount -l /var/lib/docker（部分 overlay2 实例需先echo 1 > /proc/sys/kernel/unprivileged_userns_clone配合） - 强制触发 systemd 关机流程：
sudo systemctl poweroff --force --force（双 force 可跳过服务依赖检查与正常卸载等待）
预防下次再卡在关机环节
核心是让挂载行为“可中断、可感知、可收敛”：
- 所有 bind mount 启动容器时加
--mount type=bind,bind-propagation=rprivate，避免共享传播污染全局挂载表 - 禁用 NFS 的
soft和intr，改用hard,nfsvers=4.1,proto=tcp,timeo=600,retrans=2,noac—— 不可中断比静默失败更可控 - 对关键业务容器，使用
docker run --stop-timeout=10或 Kubernetes 中设置terminationGracePeriodSeconds: 15，给应用留出主动清理挂载的时间 - 定期检查挂载健康：
systemd-run --scope -- bash -c 'findmnt -D | grep -q "busy" && echo "WARNING: stale mounts detected"'
这类死锁不是系统崩溃，而是状态同步断点。重点不在“怎么硬关”，而在“怎么让内核和 Docker 对挂载生命周期有一致认知”。处理得当，通常不用重启就能完成关机。
