服务器重启命令大全

结论：Linux 服务器重启优先用 systemctl reboot，Windows 用 shutdown /r /t 0；需要给在线用户留缓冲时用 shutdown -r +5 "维护"。reboot、shutdown -r now、init 6 都能重启，区别在是否广播通知、是否留缓冲、是否走标准关机流程，而 SysRq echo b 属强制重启，会丢数据，只能作为最后手段使用。

重启看起来是最简单的运维动作，却是事故高发环节：业务正在写库时被重启、重启后服务没设自启导致网站打不开、远程执行 reboot 后 SSH 卡死误以为机器挂了、内核参数改错后强制重启进不了系统。本文把 Linux 与 Windows 上所有常见服务器重启命令、关机命令、远程重启方式与强制重启手段一次讲清，并给出一份可直接照做的重启前检查清单。

服务器重启前先分清：重启、关机、断电三个动作

结论：重启（reboot）会重新引导内核，关机（halt/poweroff）停止系统运行，断电是硬件层面的动作。运维语境里三者混用是很多误操作的源头，先对齐概念再看命令，后面的对照表才不会看错。

一个容易忽略的细节：halt 与 poweroff 在 systemd 上都是标准关机流程（会停服务、卸载文件系统、同步磁盘），区别只在最后一步是否向主板发送 ACPI 断电信号。物理机上 halt 之后屏幕会停在 "System halted"，此时仍需长按电源键才能真正断电；云主机上 halt 通常会导致实例停留在 stopped 状态，需要到控制台再点「开机」。

Linux 重启命令速查：reboot / shutdown -r / systemctl reboot / init 6 的区别

结论：日常运维用 systemctl reboot 即可；要给同事留通知时间用 shutdown -r +5 "维护"；init 6 属于 SysV 兼容写法，不建议在新系统上用。这四个命令在 systemd 系统上最终都会触发 reboot.target，但通知方式与缓冲机制不同。

直接可复制的一组命令：

# 1) 标准重启（推荐）
sudo systemctl reboot

# 2) 计划 5 分钟后重启，并向所有登录终端广播维护消息
sudo shutdown -r +5 "系统将于 5 分钟后重启，请保存工作"

# 3) 取消尚未执行的重启计划
sudo shutdown -c

# 4) 指定具体时间点重启（24 小时制 HH:MM）
sudo shutdown -r 02:30

# 5) 查看当前是否有挂起的关机/重启计划
cat /run/systemd/shutdown/scheduled 2>/dev/null || echo "无计划任务"

init 6 之所以不推荐，是因为它依赖运行级别（runlevel）语义，在非 systemd 的老系统（CentOS 6 等）上是标准做法，但在 systemd 上会被翻译成 reboot.target，属于多一层转换；更重要的是它无法携带自定义广播消息，也无法取消。截至 2026 年主流发行版（Ubuntu 24.04 LTS、Debian 12、Rocky Linux 9、AlmaLinux 9、openEuler 24.03）均已默认 systemd，直接写 systemctl reboot 最清晰。

关机命令对照：halt / poweroff / shutdown -h now 该怎么选

结论：想让机器彻底断电用 poweroff，只想停系统保留通电用 halt，shutdown -h now 在现代 systemd 上等价于 poweroff。三者都会正常停止服务并同步磁盘，区别只在最后一步。

# 关机并断电
sudo systemctl poweroff

# 只停止系统，不断电
sudo systemctl halt

# 10 分钟后关机并广播
sudo shutdown -h +10 "计划内停机维护"

# 关机前确认是否还有重要写入进程
ps -eo pid,etime,cmd --sort=-etime | head -20

延时重启、广播通知与取消：生产环境的正确姿势

结论：生产服务器重启要用 shutdown -r +N "原因"，因为它既广播通知、又给你留出 shutdown -c 取消的窗口。直接 reboot 没有任何反悔机会，一旦敲错机器 IP 就是一次计划外中断。

要点清单：

1. 消息要写清三件事：谁在重启、为什么重启、预计多久。例如 "DBA 将于 23:00 重启以生效内核参数，预计 5 分钟"。
2. 延时不要短于 2 分钟。给正在跑的脚本留出退出时间，也给自己留出发现"敲错机器"的时间。
3. 取消后要确认。shutdown -c 执行后再看一次 /run/systemd/shutdown/scheduled，确认计划真的清掉了。
4. 广播之外再补一层通知。只依赖 wall 广播不够，同一台机器上跑的定时任务（cron）不会因为收到广播而停止，需要提前人工停掉。

# 广播一条纯通知（不关机，用于提醒在线用户）
sudo wall "注意：23:00 将进行计划内重启，请提前保存"

# 查看当前登录用户，确认影响面
who
w

# 取消计划中的重启
sudo shutdown -c

远程重启服务器：SSH、Windows 远程与云平台控制台

结论：远程重启优先走 SSH 执行 systemctl reboot，Windows 用 shutdown /r /m \\host 或 PowerShell Restart-Computer，两者都不通时再用云平台控制台的强制重启。远程重启的关键不是命令本身，而是"执行后连接必然断开"这个预期管理。

Linux 通过 SSH 远程重启：

# 最常用：直接远程执行
ssh root@192.0.2.10 'systemctl reboot'

# 计划式远程重启（更安全，留 3 分钟缓冲）
ssh root@192.0.2.10 'shutdown -r +3 "远程计划重启"'

# 避免 SSH 会话卡死的写法（把重启放到后台并立即返回）
ssh -o ServerAliveInterval=5 root@192.0.2.10 'nohup systemctl reboot >/dev/null 2>&1 &'

# 批量重启多台服务器（配合 servers.txt，一行一个 IP）
for ip in $(cat servers.txt); do
  echo "== $ip =="
  ssh -o ConnectTimeout=5 -o StrictHostKeyChecking=no root@"$ip" 'systemctl reboot' || echo "$ip 失败"
done

需要注意：SSH 远程执行 reboot 后，服务端的 sshd 会在系统关闭时终止连接，客户端常见返回 255 或 "Connection closed by remote host"。这是正常现象，不代表命令没执行成功。判断是否真重启，等 60 秒后重新 ssh 或 ping 即可，不要用 && echo ok 去判断结果。

Windows 远程重启：

# 本机立即重启
shutdown /r /t 0

# 本机 60 秒后重启并提示原因
shutdown /r /t 60 /c "计划内维护重启" /d p:2:4

# 取消尚未执行的重启
shutdown /a

# 远程重启另一台 Windows 服务器
shutdown /r /m \\192.0.2.20 /t 30 /c "远程维护重启"

# PowerShell 等价写法（可批量）
Restart-Computer -ComputerName 192.0.2.20 -Force -Wait -For PowerShell -Timeout 300

Windows 远程关机最常见的报错是「拒绝访问（5）」。原因是远程关机需要对目标机拥有关机权限，且用本地非管理员账号发起时 UAC 会剥离令牌。解决办法二选一：使用目标机的管理员账号先建立 IPC 连接（net use \\192.0.2.20\ipc$ /user:administrator *），或在目标机注册表 HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System 下把 LocalAccountTokenFilterPolicy 设为 1。同时要放行目标机防火墙的「Windows Management Instrumentation (WMI)」与文件和打印机共享相关规则（涉及 TCP 135、445 及动态 RPC 端口）。

云平台控制台：阿里云、腾讯云、华为云、AWS 等控制台都提供「重启」与「强制重启」两个按钮。前者会向实例内部下发 ACPI 关机信号，走正常关机流程；后者相当于硬件复位，等同于拔电源，仅在系统完全无响应时使用。

强制重启的最后手段：SysRq 与它的代价

结论：echo b > /proc/sysrq-trigger 会跳过所有清理动作直接复位 CPU，正在写入的数据会丢失、文件系统可能损坏，只在系统彻底卡死且带外管理不可用时使用。更安全的做法是先走 REISUB 顺序，让内核有机会同步磁盘。

# 0）确认 SysRq 功能已开启（返回值为 1 或大于 1 的位掩码）
cat /proc/sys/kernel/sysrq
# 若为 0，需先开启（临时）
sudo sysctl -w kernel.sysrq=1

# 1）更安全的顺序：依次执行 R-E-I-S-U-B（每一步之间间隔几秒）
echo r > /proc/sysrq-trigger   # 把键盘从 X/raw 模式夺回
echo e > /proc/sysrq-trigger   # 向除 init 外所有进程发 SIGTERM
echo i > /proc/sysrq-trigger   # 向除 init 外所有进程发 SIGKILL
echo s > /proc/sysrq-trigger   # 同步所有已挂载文件系统
echo u > /proc/sysrq-trigger   # 以只读方式重新挂载文件系统
echo b > /proc/sysrq-trigger   # 立即重启（最后一步）

# 2）单步强制重启（不做任何同步，风险最高）
echo b > /proc/sysrq-trigger

SysRq 的风险必须写清：它不会等待磁盘写回，也不会通知数据库刷 redo log。MySQL/PostgreSQL 这类有自身缓冲的程序，最坏情况下重启后需要走崩溃恢复，甚至出现表损坏需要 mysqlcheck --repair。因此执行前如果还有任何一丝可能，优先选择：通过带外管理（IPMI/iDRAC/iLO）发送软关机 → 控制台正常重启 → 最后才是 SysRq 或强制断电。

重启前检查清单：五件事确认完再敲回车

结论：重启前必须确认「已通知业务方、无写入任务、已备份、关键服务已设自启、有带外兜底」这五件事。这张表建议打印或写进运维手册，每次计划内重启逐项打勾。

自启检查这一步值得单独强调。服务器重启后网站打不开，绝大多数不是重启命令用错了，而是服务压根没配开机自启：

# 批量检查关键服务是否为 enabled
for s in nginx mysqld php-fpm redis docker sshd; do
  printf "%-10s %s\n" "$s" "$(systemctl is-enabled $s 2>/dev/null || echo '未安装')"
done

# 若为 disabled，立即开启
sudo systemctl enable --now nginx

# 老系统（SysVinit）用 chkconfig
chkconfig --list | grep -E 'nginx|mysqld'