Linux 重启命令：reboot、shutdown -r now 与 systemctl reboot

Linux 重启命令：reboot、shutdown -r now 与 systemctl reboot

在当前任何发行版上，下面三条命令重启机器的方式完全一致。请以 root 身份或通过 sudo 执行；通过 SSH 使用非特权账户会得到 Failed to reboot system via logind: Interactive authentication required。

sudo reboot
sudo shutdown -r now
sudo systemctl reboot

这并不是三套不同的实现。在 systemd 发行版上，/sbin/reboot、/sbin/shutdown、/sbin/halt 和 /sbin/poweroff 都是指向 systemctl 的符号链接，systemctl 会根据被调用的名字切换到相应的兼容模式；ls -l $(which reboot) 可以看到该链接。无论你输入哪一种写法，systemd 都会启动 reboot.target，按依赖关系的逆序停止所有单元，卸载文件系统并请求内核重启。通过 SSH 连接会在一两秒内断开；机器离线多久取决于内核、可能的文件系统检查以及服务商的引导流程，因此至少等一分钟再判断是否出了问题。

关机：shutdown -h now、poweroff、halt 以及传统的 init 6

要给机器关机，下面任意一条即可：

sudo shutdown -h now
sudo poweroff          # identical to: sudo systemctl poweroff

在 systemd 下，-h 的含义是"停机或关机，以默认行为为准"，而默认行为就是关机，因此 shutdown -h now 与 shutdown -P now 完全相同。真正容易踩坑的是单独的 halt：它会停止操作系统，却不发出关机请求，于是虚拟机停在 System halted，资源仍被占用、仍在计费，直到你从面板里停止它。请改用 halt -p、poweroff 或 shutdown -h now。

SysV 风格的写法仍然可用，因为 systemd 把运行级别映射到了 target：init 6 和 telinit 6 对应 reboot.target，init 0 对应 poweroff.target。它们出现在旧脚本里无伤大雅，但没有 wall 广播、不能定时、也不会在 journal 中留下说明，所以没必要手动输入。

定时重启、取消重启以及提醒已登录用户

sudo shutdown -r +10 "Kernel update, back in about two minutes"
sudo shutdown -r 02:30
sudo shutdown -c

时间参数可以是 now、表示 m 分钟后的 +m，或 24 小时制的 hh:mm（今天已过的时间点表示明天）。完全不写时间时，shutdown 默认取 +1：单独的 sudo shutdown 会在六十秒后关机。时间参数之后的内容会作为 wall 消息广播到每个已登录终端，临近时间点时 logind 还会重复提醒；--no-wall 可以让它保持安静，shutdown -k 则只发提醒而不排定任何操作。到点前五分钟，logind 会创建 /run/nologin，此后新的登录都会被拒绝。

shutdown -c 会取消待执行的操作、删除 /run/nologin，并告知已登录用户关机已取消。要检查是否有待执行的计划，可查看 /run/systemd/shutdown/scheduled：它只在有关机排队时存在，并记录模式和目标时间。较新的 systemd 版本还支持 systemctl reboot --when=+10m，以及 --when=show 和 --when=cancel（可用 systemctl --help 确认；旧版本没有该选项）。

重启期间服务和 SSH 会话会发生什么

当 reboot.target 被请求时，systemd 会停止与之冲突的一切，也就是几乎所有单元。服务按依赖关系的逆序停止：每个服务先执行自己的 ExecStop 或收到 SIGTERM，如果在 TimeoutStopSec（默认 90 秒，来自 /etc/systemd/system.conf 中的 DefaultTimeoutStopSec=）之后仍未退出，就会收到 SIGKILL。控制台上看到的 A stop job is running for ... 倒计时正是这个超时；通常是某个忽略 SIGTERM 的守护进程，或仍在刷盘的数据库。随后文件系统被卸载或以只读方式重新挂载，内核开始重启。你不需要事先执行 sync。

你的 SSH 会话不会被特殊对待。ssh.service 停止，承载你登录的 scope 收到 SIGTERM，你的 shell 结束，客户端打印 Connection to 203.0.113.10 closed by remote host。tmux 或 screen 只能防止连接中断带来的影响，防不了重启：其中运行的一切同样会消失。

重启后能恢复什么，取决于是否设置了开机自启，而不是重启前正在运行什么。标记为 enabled 的单元会重新启动；用 systemctl start 手动启动的服务、nohup 进程或没有重启策略的 Docker 容器则不会。重启前运行 systemctl list-unit-files --state=enabled，重启后运行 systemctl --failed；用 systemctl 列出和筛选服务的指南说明了如何解读这两条命令的输出。

安全重启 VPS：起飞前检查清单

VPS 没有物理访问途径，因此一次没能重新启动成功的重启，就意味着要绕道服务商控制台。下面五项检查总共不到一分钟，却几乎能避免所有这类麻烦。

1. 确认确实需要重启

并非每次更新都需要重启。在 Ubuntu 上，当某个软件包要求重启时会出现 /var/run/reboot-required，而 /var/run/reboot-required.pkgs 会列出是哪些包；Debian 和 Ubuntu 上的 needrestart，以及 RHEL 系中来自 dnf-utils 的 needs-restarting -r，可以做同样的检查。新内核、glibc 或 systemd 值得重启；只是打了补丁的 nginx 只需 systemctl restart nginx。先装完待处理的更新，这样只需重启一次而不是两次；用命令行更新 Ubuntu 的教程介绍了 apt 的操作顺序和 reboot-required 标记。

[ -f /var/run/reboot-required ] && cat /var/run/reboot-required.pkgs
uname -r; ls /boot/vmlinuz-*     # running kernel vs. newest installed

2. 确认没有正在写入的操作

打断包管理器是把系统弄成半配置状态的最快方式，而中途被终止的备份，日后很容易被误当成完好的副本。先找出这类进程，并看看还有谁登录着：

pgrep -a 'apt|dpkg|dnf|yum|unattended'
pgrep -a 'rsync|mysqldump|pg_dump|restic|borg'
w

3. 校验必须挺过重启的配置

有三个文件能把一次例行重启变成把自己锁在门外。sshd_config 里的语法错误会让 sshd 无法启动，你也就进不去了：文件有效时 sudo sshd -t 不会输出任何内容，如果你最近加固过 SSH 守护进程，现在就跑一遍。/etc/fstab 中指向已不存在设备的条目，若没有 nofail，会让系统启动进入紧急模式；sudo findmnt --verify 能发现大部分此类问题。/boot 占满可能留下装了一半的内核，所以要检查它的剩余空间。直接用 iptables 或 nft 写下、却从未保存的防火墙规则会在重启后消失；UFW 和 firewalld 的规则则会持久保留。

sudo sshd -t
sudo findmnt --verify
df -h / /boot

4. 记录一份基线

systemctl --failed
systemctl list-units --type=service --state=running > ~/services-before.txt

5. 重启，然后验证

sudo systemctl reboot --message="post-update reboot"
# after reconnecting:
uptime -s; systemctl --failed
systemctl list-units --type=service --state=running | diff ~/services-before.txt -

uname -r 与预期一致、systemctl --failed 没有报错、diff 为空，就说明这次重启一切正常。

重启卡住时：如何强制重启，以及何时改用服务商控制台

如果 reboot 已经返回但机器迟迟不关，说明有停止作业卡住了；systemctl list-jobs 能看出是哪一个。systemctl reboot --force 会跳过有序的单元停止流程：进程被直接杀掉，但文件系统仍会卸载，所以虽然粗暴，还算相对安全。--force --force 会立即重启且不卸载任何东西，可能丢数据；把它当成直接拔电源看待。当 systemd 本身都不再响应时，内核的 SysRq 接口是最后手段。无论 kernel.sysrq 这个 sysctl 如何设置，root 总是可以写入 /proc/sysrq-trigger，但重定向本身必须以 root 身份执行，因此请使用 root shell 或 sudo sh -c：

echo s > /proc/sysrq-trigger   # sync dirty buffers
echo u > /proc/sysrq-trigger   # remount filesystems read-only
echo b > /proc/sysrq-trigger   # reboot right now

当虚拟机自身已无力回天时，就该用服务商的面板或控制台了：改动网络或防火墙后 SSH 不可达、内核启动时 panic、fstab 有错导致进入紧急模式提示符、忘记 root 密码。面板中的 Reboot 或 Shutdown 通常会发送一个 ACPI 电源事件，由虚拟机通过 logind 处理（logind.conf 中的 HandlePowerKey=），因此服务仍会干净地停止。Reset、Force stop 或 Power cycle 则毫无预警地切断虚拟电源：下次启动时文件系统日志会重放，但尚未写入的数据都会丢失。VNC 或串口控制台能让你看到 GRUB、内核消息以及紧急 shell，这些是 SSH 永远看不到的。

查看运行时长与上次重启时间

uptime -p                      # up 3 days, 4 hours, 12 minutes
uptime -s                      # 2026-08-31 02:31:07
who -b                         # system boot  2026-08-31 02:31
last -x reboot shutdown | head
journalctl --list-boots

uptime -s 和 who -b 会直接打印启动时间。last -x 读取 /var/log/wtmp，同时列出 reboot 和 shutdown 记录：某条 reboot 之前没有对应的 shutdown，说明机器上次是非正常关机（panic 或硬重置）。journalctl --list-boots 会给 journal 已知的每次启动编号，0 是当前这次，-1 是上一次；journalctl -b -1 -e 则显示上次关机前的最后几行日志，停止作业超时或内存不足被杀的痕迹就留在那里。如果只列出当前这次启动，说明 journal 是易失的：创建 /var/log/journal 并重启 systemd-journald。

上面所有命令都基于一个前提：当虚拟机拒绝重新启动时，你仍然能够触达它。带控制台访问的 KVM Linux VPS 正好提供这一点：一台拥有独立内核、专用 CPU 与内存、完整 root 权限的真正虚拟机，并在 SSH 无能为力时提供控制台。rdp.monster 在付款确认后约 10 秒交付，带宽无限制（合理使用），无需 KYC，支持银行卡与加密货币付款，每月 $8.99 起。