执行 reboot 后卡住，本质上不是单一故障，而是关机流程中的某个环节没能正常返回。RHEL 7/8/9 的关机流程由 systemd 统一调度，先停服务、再卸载文件系统、最后调用内核重启。只要任意一个 stop job 或 unmount 操作长时间没有结束，整条重启链路就会挂起。遇到这种情况先别急着断电，因为此时文件系统可能还在写缓存，直接断电容易触发日志丢失甚至元数据损坏。

判断卡在哪里最直接的方式是打开服务器带外控制台或硬件 KVM，看屏幕最后停留在什么内容。如果最后几行是 Stopping Session 5 of user root、Stopped target Local File Systems 之类的消息，说明 systemd 还在处理用户会话或文件系统；如果屏幕上只剩一个黑屏光标，说明内核已经进入 late shutdown 阶段，可能卡在 ACPI、watchdog 或驱动回调里。定位阶段是后续处理的前提。

一、先确认卡住阶段，不要盲目断电

在执行任何强制操作之前，建议先通过控制台确认当前是否能切换终端。如果图形界面或文本登录提示还在，可以尝试按 Ctrl+Alt+F2 切到其他 tty，登录后执行命令。即使 reboot 卡住，内核和 systemd 通常还活着，能登录就还有机会用命令介入。若连 tty 都切不过去，则需要依赖 IPMI、iLO、iDRAC 这类带外管理接口。

有 SSH 的情况下，如果 reboot 命令刚执行、连接还没断，可以立刻新开一个会话查看系统状态。重点看 /run/systemd/shutdown/scheduled 是否存在，以及 journalctl -b -1 -n 50 中最后几条日志。RHEL 8/9 默认使用持久化日志，reboot 卡住时的日志可能在当前启动周期看不到，但可以通过上一次启动的 journal 偏移量读取。

# 查看当前 shutdown 状态
systemctl list-jobs
# 查看上一次启动的最后日志
journalctl -b -1 -n 50 --no-pager
# 查看内核环形缓冲中最后记录
dmesg | tail -n 50

二、分析常见卡住原因，重点看服务和挂载

systemd 关机时会给每个 stop job 设置超时时间，默认 DefaultTimeoutStopSec 为 90 秒。超过这个时间后 systemd 会给对应进程发送 SIGKILL，然后继续向下执行。如果某个服务在 stop 阶段长时间不响应，屏幕上通常会出现类似 A stop job is running for ... 的提示。这种提示本身就说明问题出在服务停止阶段。常见于数据库、杀毒软件、监控 Agent 或第三方备份程序没有正确处理 SIGTERM，或者进程陷入不可中断的 D 状态。

另一类高频原因是网络文件系统卸载失败。NFS 客户端在服务器不可达时，umount 操作可能会一直等待重试，导致 Unmounting /mnt/nfs... 卡住。iSCSI、CIFS、CephFS 等远程文件系统也有类似问题。查看 /proc/mounts 或 mount 输出能确认哪些挂载点仍然存在。若怀疑是 NFS，可以查看内核日志中是否有 nfs: server 未响应的记录。

# 查看当前挂载的远程文件系统
mount | grep -E 'nfs|cifs|fuse|iscsi'
# 检查内核日志中的存储或网络异常
dmesg | grep -iE 'nfs|iscsi|error|timeout'

存储层面也不能忽略。如果根盘所在 RAID 卡、FC HBA 或 NVMe 控制器出现异常，IO 请求无法完成，系统可能在 sync 或 unmount 根文件系统时挂起。此时控制台通常会出现 block device timeout、I/O error 或 sd ... resetting 等内核输出。遇到这种情况要重点检查存储链路、光线、磁盘健康状态，而不是只盯着 systemd 配置。

三、紧急恢复：从 systemctl 到 SysRq 的梯度处理

如果系统还能接受命令，优先尝试让 systemd 跳过所有 stop job 直接重启。systemctl reboot --force 会跳过服务停止阶段，直接进入重启流程；systemctl reboot --force --force 则进一步跳过文件系统卸载和清理阶段，直接调用 reboot(2) 系统调用。后者的风险更高，仅在文件系统已经只读或确定缓存已落盘的情况下使用。

# 跳过服务停止，直接重启
systemctl reboot --force
# 跳过服务停止和文件系统卸载，直接重启
systemctl reboot --force --force

当 SSH 已经断开、控制台也无法输入命令时，可以尝试 Linux 的 SysRq 魔术键。先确认 /proc/sys/kernel/sysrq 的值不是 0。若为 1，表示全部 SysRq 功能可用。通过物理键盘或带外虚拟键盘按住 Alt+SysRq，然后依次按 r、e、i、s、u、b，可以将文件系统重新挂载为只读并重启。紧急情况下直接执行 echo b > /proc/sysrq-trigger 也能立即重启，但不会同步磁盘，仅作为最后手段。

# 查看 SysRq 是否启用
cat /proc/sys/kernel/sysrq
# 紧急触发立即重启
echo b > /proc/sysrq-trigger

对于带外管理卡，还可以使用 ipmitool chassis power cycle 做电源循环。不过这种方式等于直接断电再上电，会让没有落盘的数据全部丢失，只适合在 SysRq 也失效时执行。执行前尽量通过控制台确认根文件系统没有被写入大量脏页。

四、从根因上修复，避免重启再次卡住

确认是某个服务导致 stop job 超时后，可以单独优化该服务的停止行为。先通过 systemctl show 服务名 -p TimeoutStopUSec 查看该单元的超时设置，再根据实际情况在 unit 文件中加入 TimeoutStopSec=10s 等参数。不要让所有服务都依赖默认的 90 秒，尤其是一些已知需要更长时间才能完成优雅关闭的数据库服务。与此同时，检查服务的 ExecStop 脚本是否调用了可能阻塞网络的命令，比如等待一个已经不可达的 IP 或域名。

如果是挂载问题，建议在 /etc/fstab 中为远程文件系统加上 _netdev 和 x-systemd.automount 参数。这样 systemd 会在网络可用后自动挂载，并在关机时先处理网络文件系统。对于 NFS，还可以在挂载选项中增加 soft 和 timeo=30，避免客户端无限重试。若某台 NFS 服务器已经下线，应先在 /etc/fstab 中临时注释掉对应条目，再执行 umount -l 强制解除挂载。

# 示例：/etc/fstab 中远程 NFS 挂载
server:/data  /mnt/data  nfs  defaults,_netdev,soft,timeo=30,x-systemd.automount  0 0

硬件兼容问题导致的内核重启挂起，通常需要在 grub 配置中加入特定参数。比如某些服务器执行 reboot 时需要指定 reboot=efi 或 reboot=acpi，否则会在调用内核重启时黑屏。不同厂商的机器表现不同，可在 /etc/default/grub 的 GRUB_CMDLINE_LINUX 中加入参数后执行 grub2-mkconfig -o /boot/grub2/grub.cfg 重建配置。若使用 kexec 进行快速重启，也可能因内核新旧不一致导致卡住，可以暂时关闭 kexec 观察。

# /etc/default/grub 示例
GRUB_CMDLINE_LINUX="crashkernel=auto rd.lvm.lv=rootvg/rootlv reboot=acpi"

最后，建立重启前的检查习惯比任何恢复命令都重要。生产主机执行 reboot 前确认没有正在写入的备份任务，远程存储服务器可用，NFS 挂载点可以正常卸载，必要情况下先执行 sync 把脏页写回磁盘。把这些检查纳入日常变更流程，可以显著减少 reboot 卡住的概率。真遇到卡住时，按控制台判断、梯度强制、日志定位、根因修复的顺序处理，基本能覆盖大部分 RHEL 环境下的重启故障。