在生产环境中，重启操作最稳妥的方案是 sudo shutdown -r now 或 sudo systemctl reboot。前者功能更完善，支持广播通知、设定延迟重启时间，甚至能在最后一刻取消操作；后者则是 systemd 的原生接口，虽然效率直接，但不会广播消息。两者都遵循优雅的关机流程，而直接调用 reboot 命令则可能跳过清理步骤，从而引发数据丢失的风险。

为什么 reboot 看似简单却容易出问题

这个命令本质是向 init 发送信号，跳过大部分 systemd 的优雅关闭流程。常见后果包括：

• 远程 SSH 会话突然断开，没机会发通知给其他登录用户
• systemd 不触发 Before= 或 WantedBy= 关联的清理服务（比如未 flush 的日志缓冲、未 sync 的 NFS 写缓存）
• 某些依赖 orderly shutdown 的服务（如数据库、集群节点）可能残留状态或报错
• 系统日志里只有一条 reboot: System rebooted，缺乏前序 shutdown trace，排障困难

shutdown -r now 和 systemctl reboot 的实际差异

两者都走 systemd 的 reboot.target，但行为路径不同：

• shutdown -r now：先广播 Wall message（所有 TTY 显示“System going down...”），再调用 systemctl start reboot.target；支持延迟（如 shutdown -r +5）和取消（shutdown -c）
• systemctl reboot：直连 reboot.target，不广播 Wall message，也不写 /run/nologin（即不会阻止新 login）；适合脚本中调用，但不适合多用户交互场景
• 二者都会等待服务超时（默认 90s）后强制 kill，可通过 DefaultTimeoutStopSec= 在 /etc/systemd/system.conf 中调整

重启前必须检查的三件事

不是敲完命令就完事，尤其在生产服务器上：

• 确认无关键进程在运行：ps aux | grep -E "(mysql|postgres|redis|kubelet)"
• 检查是否有用户登录：w 或 who；若有人在线，用 sudo shutdown -r +2 给 2 分钟缓冲
• 验证磁盘状态：df -h 看根分区是否快满（/ 或 /var 占用 >90% 可能导致 reboot 过程卡在 journal 刷盘阶段）

遇到 “Failed to reboot system via logind” 怎么办

遇到 systemctl reboot 报错？这通常是因为当前用户权限不足，且系统未配置相应的 polkit 规则。解决思路其实很直接：

• 普通用户想免密码执行，需添加 polkit 规则：/etc/polkit-1/rules.d/50-allow-reboot.rules，内容为：

  polkit.addRule(function(action, subject) {
  if (action.id == "org.freedesktop.login1.reboot" && subject.isInGroup("wheel")) {
  return polkit.Result.YES;
  }
  });

• 临时绕过：改用 sudo shutdown -r now，它不经过 logind，而是直接调用 systemd 的 manager 接口
• 注意：不要用 echo 1 > /proc/sys/kernel/sysrq + echo b > /proc/sysrq-trigger，这是强制硬重启，跳过所有 shutdown 流程，等同于拔电源