reboot 命令详解与参数实测（Ubuntu 22.04）

目标：全面掌握 reboot 的每一个参数与用法——无参数直接重启、--reboot 显式形式、--halt 切换为挂起、-p 的实测真实行为（与帮助文本矛盾的重点踩坑）、-f 强制重启（Rebooting.）、-w 的实测表现（未产生任何 wtmp 记录）、-d 拦不住优雅路径留痕、--no-wall 静默重启，以及从 journal 判定行区分重启/挂起/断电三种结局的方法、非 root 越权的三连报错与 [ARG] 位置参数行为，全部命令与回显已在 Ubuntu 22.04（systemd 249）环境实测通过，其中重启类参数均真实执行并记录了主机重启前后的 wtmp 与 journal 双重证据。

一、环境信息

本文所有命令均在以下环境实测，回显逐字照抄：

• 操作系统：Ubuntu 22.04.5 LTS（PRETTY_NAME="Ubuntu 22.04.5 LTS"）
• 内核：6.8.0-138-generic，x86_64 架构
• init 系统：systemd 249 (249.11-0ubuntu3.23)，systemctl is-system-running 实测返回 running
• reboot 所属软件包：systemd 249.11-0ubuntu3.23
• reboot 真实身份：/usr/sbin/reboot -> /bin/systemctl 符号链接（3.1 节实测确认）
• 系统时区：UTC（date 输出带 UTC 后缀），下文回显中的时间均为系统本地时间
• 执行身份：root
• 演示目录：/root/demo/reboot/

💡 说明：reboot 每次真实执行都会让主机立即停止运行并重新引导，本文所有破坏性命令都真实执行过，并以重启前后的 wtmp 留痕（last -x 输出）与 journal 优雅停机序列双重证据闭环，因此部分小节的回显是「执行命令 → 主机停机 → 重新启动后查看日志」的完整闭环，读者在自己的测试机上复现时请提前保存工作内容。

二、命令概览

2.1 语法与测试数据

reboot 用于立即重启系统，与 shutdown 最大的不同是：没有时间参数、没有广播消息参数、没有取消机制——回车即重启，不存在「计划」。语法（来自实测 reboot --help 首行）：

reboot [OPTIONS...] [ARG]

两部分参数的含义：

• [ARG]：一个历史兼容的位置参数。帮助文本未解释其含义，3.12 节实测确认 reboot 静默接受恰好一个位置参数（无任何可见效果），而同一家族的 halt/poweroff 会以 Too many arguments. 拒绝任何位置参数；
• [OPTIONS...]：动作与行为选项，全部选项见 2.2 节。

不写任何选项时，默认动作为重启（等同 --reboot）。本文测试数据约定：破坏性命令均单独执行、前后用 last -x 留痕对账；非破坏性命令（-w 组合、非法参数、非 root 试探）在确认系统 running 状态下执行。

💡 技术拓展：reboot / halt / poweroff / shutdown 是同一套代码的四个入口（全部是 /bin/systemctl 的符号链接），systemd 收到请求后最终由三个专用服务之一完成收尾，journal 中的判定行一目了然——

动作	对应服务	journal 收尾判定行
重启	systemd-reboot.service	Finished System Reboot. → Reached target System Reboot.
挂起	systemd-halt.service	Starting System Halt...（journal 随系统停止，无 Finished 行）
断电	systemd-poweroff.service	Finished System Power Off. → Reached target System Power Off.

本文 3.4/3.5 节的动作切换验证、以及第五节 Q3 的「日志对账方法」都建立在这三行判定行上。

2.2 --help 全量输出（逐行照抄）

先看完整帮助，是逐参数实测的地图。以下为 reboot --help 的完整实测输出：

$ reboot --help
reboot [OPTIONS...] [ARG]

Reboot the system.

Options:
     --help      Show this help
     --halt      Halt the machine
  -p --poweroff  Switch off the machine
     --reboot    Reboot the machine
  -f --force     Force immediate halt/power-off/reboot
  -w --wtmp-only Don't halt/power-off/reboot, just write wtmp record
  -d --no-wtmp   Don't write wtmp record
     --no-wall   Don't send wall message before halt/power-off/reboot

See the halt(8) man page for details.

关键差异解读：

1. 与 shutdown 的帮助完全不同——reboot 家族有 -f/-w/-d 三个行为参数，却没有 shutdown 的 -c（取消）、-k（假广播）和 [TIME] 时间参数；
2. 最后一行是 See the halt(8) man page for details.——reboot、halt、poweroff 三个命令共用 halt(8) 手册（同一段代码三个入口）；
3. 帮助声称 -p --poweroff 是 "Switch off the machine"，3.5 节将实测推翻这一描述：在 reboot 名义下 -p 被解析层忽略，执行结果仍是重启，这是本文最重要的踩坑记录；
4. --halt/--reboot 两个长选项则在任何名义下都无条件生效（3.3/3.4 节实测）。

2.3 版本信息

Ubuntu 22.04 的 reboot 属于 systemd 软件包，实测版本信息如下：

$ systemctl --version
systemd 249 (249.11-0ubuntu3.23)
+PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT +GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 -PWQUALITY -P11KIT -QRENCODE +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified

$ dpkg -l systemd | tail -1
ii  systemd        249.11-0ubuntu3.23 amd64        system and service manager

systemctl --version 的第一行就是 reboot 实际运行的版本（249.11-0ubuntu3.23）。版本号很重要：本文 3.5 节（-p 被忽略）与 3.7 节（-w 不写记录）都是针对 systemd 249 的实测结论，其他版本的行为请以现场实测为准。

三、参数逐项实测

3.1 先确认身份：reboot 是 systemctl 的符号链接

systemd 时代的 reboot 不是独立二进制，而是 systemctl 的符号链接。systemctl 运行时按 argv[0]（程序被调用的名字）判定要执行的动作，这是理解四命令行为一致性的关键：

ls -l /usr/sbin/shutdown /usr/sbin/reboot /usr/sbin/halt /usr/sbin/poweroff

实测回显：

$ ls -l /usr/sbin/shutdown /usr/sbin/reboot /usr/sbin/halt /usr/sbin/poweroff
lrwxrwxrwx 1 root root 14 Oct 12 07:44 /usr/sbin/halt -> /bin/systemctl
lrwxrwxrwx 1 root root 14 Oct 12 07:44 /usr/sbin/poweroff -> /bin/systemctl
lrwxrwxrwx 1 root root 14 Oct 12 07:44 /usr/sbin/reboot -> /bin/systemctl
lrwxrwxrwx 1 root root 14 Oct 12 07:44 /usr/sbin/shutdown -> /bin/systemctl

💡 要点：

1. 四个命令全部指向 /bin/systemctl，本质上是同一套代码的不同入口；因此 2.2 节 reboot --help 显示的是 reboot 专属的短帮助，而不是 systemctl 的长帮助——systemctl 按 argv[0] 识别了身份。
2. 这也解释了为什么 systemctl --version 的版本就是 reboot 的版本（2.3 节）。
3. dpkg -S /usr/sbin/reboot 可确认归属（输出 systemd: /usr/sbin/reboot），排障时可用于区分是 systemd 包还是 SysV 兼容包提供的同名命令。

3.2 无参数直接执行：优雅重启（真实执行）

reboot 不带任何参数，走完整的优雅停机流程：通知 systemd 重启 → 依序停止全部服务 → 卸载文件系统 → 写 wtmp 留痕 → 重新引导。命令本身没有输出，回车后系统随即开始停机：

reboot

执行后主机停止运行并重新引导。重启回来后用 last -x 查看留痕（节选头部）：

$ last -x | head -6
runlevel (to lvl 5)   6.8.0-138-generi Fri Oct 16 09:54   still running
reboot   system boot  6.8.0-138-generi Fri Oct 16 09:54   still running
shutdown system down  6.8.0-138-generi Fri Oct 16 09:54 - 09:54  (00:00)
runlevel (to lvl 5)   6.8.0-138-generi Fri Oct 16 09:54 - 09:54  (00:00)
reboot   system boot  6.8.0-138-generi Fri Oct 16 09:54 - 09:54  (00:00)
shutdown system down  6.8.0-138-generi Fri Oct 16 09:54 - 09:54  (00:00)

journal 中本次优雅重启的收尾序列（节选）：

Oct 16 09:54:36 b8307d66e0c6 systemd[1]: Stopping Record System Boot/Shutdown in UTMP...
Oct 16 09:54:36 b8307d66e0c6 systemd[1]: systemd-update-utmp.service: Deactivated successfully.
Oct 16 09:54:36 b8307d66e0c6 systemd[1]: Stopped Record System Boot/Shutdown in UTMP.
Oct 16 09:54:36 b8307d66e0c6 systemd[1]: Reached target Unmount All Filesystems.
Oct 16 09:54:36 b8307d66e0c6 systemd[1]: Reached target System Shutdown.
Oct 16 09:54:36 b8307d66e0c6 systemd[1]: Reached target Late Shutdown Services.
Oct 16 09:54:36 b8307d66e0c6 systemd[1]: systemd-reboot.service: Deactivated successfully.
Oct 16 09:54:36 b8307d66e0c6 systemd[1]: Finished System Reboot.
Oct 16 09:54:36 b8307d66e0c6 systemd[1]: Reached target System Reboot.
Oct 16 09:54:36 b8307d66e0c6 systemd[1]: Shutting down.
Oct 16 09:54:36 b8307d66e0c6 systemd-journald[23]: Journal stopped

💡 要点：

1. wtmp 三类记录的对应关系：shutdown system down 是旧 boot 的结束标记（由 systemd-update-utmp 服务在停机序列中写入，对应 journal 的 Stopping Record System Boot/Shutdown in UTMP），reboot system boot 是新 boot 的开始标记，runlevel (to lvl 5) 是新 boot 进入多用户模式的时间点；
2. journal 收尾的判定行是 Finished System Reboot. 与 Reached target System Reboot.——这是「确认这次停机真的是重启」的权威证据（3.4/3.5 节的动作切换验证全靠它）；
3. 从回显时间戳看，整个优雅停机流程在 1 秒内完成（09:54:36 一秒内走完全部序列），环境内服务极少；生产服务器上有大量服务时通常需要数十秒。

3.3 --reboot：显式指定重启动作

--reboot 是长选项形式，把动作显式声明为重启——效果与无参数的 3.2 节完全相同，意义在于脚本中「自解释」。本节用 -w 组合做非破坏性的解析验证（-w 的实测行为见 3.7 节：不会停机、也不写记录，因此该组合可安全执行）：

systemctl is-system-running
reboot --reboot -w
echo "退出码=$?"
systemctl is-system-running

实测回显：

$ systemctl is-system-running
running
$ reboot --reboot -w
$ echo "退出码=$?"
退出码=0
$ systemctl is-system-running
running

💡 要点：--reboot 被正常接受（退出码 0），系统保持 running 未受影响。两个长选项 --halt/--reboot 与短参数 -p 的关键区别是：长选项无条件覆盖动作（3.4 节实测 --halt 在 reboot 名义下生效），而 -p 在 reboot 名义下被忽略（3.5 节）。

3.4 --halt：把重启切换为挂起动作（真实执行）

--halt 无条件把动作从重启切换为挂起（halt：停止系统，不重新引导、不断电）。真实执行：

reboot --halt

执行后主机停止运行，随后重新启动（在本环境的托管运行时中，系统停止后会被重新拉起，效果见下）。恢复后查看 wtmp（节选头部）：

$ last -x | head -5
runlevel (to lvl 5)   6.8.0-138-generi Fri Oct 16 10:07   still running
reboot   system boot  6.8.0-138-generi Fri Oct 16 10:07   still running
shutdown system down  6.8.0-138-generi Fri Oct 16 10:07 - 10:07  (00:00)
runlevel (to lvl 5)   6.8.0-138-generi Fri Oct 16 10:04 - 10:07  (00:02)
reboot   system boot  6.8.0-138-generi Fri Oct 16 10:04 - 10:07  (00:02)

journal 中的结局判定行：

Oct 16 10:07:19 b8307d66e0c6 systemd[1]: Starting System Halt...

配合 -f 强制路径的动词回显（-f 由 systemctl 自己按解析后的动作打印动词，见 3.6 节）可以交叉确认动作被切换：

$ reboot --halt -f
Halting.

💡 要点：

1. wtmp 层面 reboot --halt 与优雅重启长得一样（都有 shutdown system down 结束标记与新 boot 记录），journal 才是区分点：优雅重启的结局是 Reached target System Reboot.，而 reboot --halt 的结局是 Starting System Halt...（挂起动作的服务启动了）；
2. 挂起路径的 journal 特征是「只有 Starting 没有 Finished」——systemd-halt.service 是停机序列的最后一个单元，它的完成回执来不及写入 journal，journal 就随系统停止了；
3. 在物理机上，挂起（halt）后主机保持通电、停在内核停止状态，需要现场按电源键才能恢复；本实测环境没有可控电源域，系统停止后由外部重新拉起，因此「挂起」与「断电」的最终表现一致，但两者的执行路径在 journal 中可严格区分（对照 3.5 节 halt -p 的 Reached target System Power Off.）。

3.5 -p：帮助说「Switch off」，实测仍是重启（重点踩坑）

这是本文最重要的实测发现。帮助文本声称 -p --poweroff Switch off the machine，直觉上 reboot -p 应该「关机断电」。真实执行：

reboot -p

journal 中的结局判定行（动作切换实验序列，时间戳 10:04:17 对应本次 reboot -p）：

Oct 16 10:04:17 b8307d66e0c6 systemd[1]: systemd-reboot.service: Deactivated successfully.
Oct 16 10:04:17 b8307d66e0c6 systemd[1]: Finished System Reboot.
Oct 16 10:04:17 b8307d66e0c6 systemd[1]: Reached target System Reboot.

systemd-reboot.service 与 Reached target System Reboot. 表明：reboot -p 走的是重启流程，断电根本没有发生。再配合 -f 强制路径的动词回显（该动词由 systemctl 自己按解析结果打印，最能反映参数解析层的行为）：

$ reboot -p -f
Rebooting.

打印的是 Rebooting. 而不是 Powering off.——解析层就把 -p 忽略了，动作仍是重启。

💡 要点：

1. 在本环境 systemd 249 (249.11-0ubuntu3.23) 上，-p 只在 reboot 这一个名义下被忽略；对照实测：halt -p -f 打印 Powering off.（生效）、poweroff -p -f 打印 Powering off.（本就是默认动作）。即 -p 的语义是「把 halt 名义切到断电」，对 reboot 名义无效——这与 2.2 节帮助文本「Regardless of which command was invoked」式的通用描述不符；
2. 想用 reboot 家族关机断电，两条实测有效的路径：halt -p（journal 判定行为 Reached target System Power Off.，见 halt 篇 3.4 节）或直接 poweroff；
3. shutdown -P now 也能断电（shutdown 有自己独立的参数解析，-P 实测有效，见 shutdown 篇 3.12 节）；
4. 该结论为 systemd 249 实测，升级 systemd 后请重新验证（判定方法就是本文的 journal 结局行 + reboot -p -f 动词回显）。

3.6 -f：强制立即重启（跳过优雅停机）

-f --force 跳过 systemd 的优雅停机流程，由 systemctl 自己直接执行重启系统调用。它会先打印一行动词再执行：

$ reboot -f
Rebooting.

执行后主机立即重启，不等待服务停止。对比执行前后 last -x 的记录条目（节选）：

执行 reboot -f 前的头部（上一次优雅测试后）：

runlevel (to lvl 5)   6.8.0-138-generi Fri Oct 16 09:54   still running
reboot   system boot  6.8.0-138-generi Fri Oct 16 09:54   still running
shutdown system down  6.8.0-138-generi Fri Oct 16 09:54 - 09:54  (00:00)

执行 reboot -f 并恢复后的头部：

runlevel (to lvl 5)   6.8.0-138-generi Fri Oct 16 09:54   still running
reboot   system boot  6.8.0-138-generi Fri Oct 16 09:54   still running
runlevel (to lvl 5)   6.8.0-138-generi Fri Oct 16 09:54 - 09:54  (00:00)
reboot   system boot  6.8.0-138-generi Fri Oct 16 09:54   still running
shutdown system down  6.8.0-138-generi Fri Oct 16 09:54 - 09:54  (00:00)

💡 要点：

1. 对比可见 reboot -f 之后没有新增 shutdown system down 记录（本文全部破坏测试共执行了 4 次强制路径，wtmp 里的 down 记录条数始终等于优雅路径次数）——因为写这条记录的 systemd-update-utmp 服务只在优雅停机序列中运行，-f 直接绕过了它；
2. 还有一个更隐蔽的痕迹：强制重启后，旧 boot 的 reboot system boot 记录停留在 still running 状态（上面第 4 行）——正常优雅路径会把它闭合为「起点 - 终点 (时长)」格式，-f 没有执行任何 utmp 收尾，留下一条永远不会闭合的「僵尸 boot 记录」，用 last -x 审计时看到连续两条 still running 就要怀疑发生过强制停机；
3. Rebooting. 这行输出由 systemctl 自己打印（强制路径不再经过 systemd 停机序列），同族动词还有 Halting.（halt -f）与 Powering off.（poweroff -f），三个动词正好对应三种动作，是验证动作解析结果的直接手段；
4. -f 的使用场景是系统已卡死、优雅路径无响应时的最后手段：数据库、文件系统日志、排队中的写入都可能来不及落盘，使用前请确认真无其他选择。

3.7 -w：声称「只写 wtmp」，实测什么都没写（真实踩坑#2）

帮助文本声称 -w --wtmp-only 是 "Don't halt/power-off/reboot, just write wtmp record"。前半句实测成立（确实不停机），后半句实测不成立。第一次验证（执行前后 last -x reboot 对比）：

$ last -x reboot
reboot   system boot  6.8.0-138-generi Thu Oct 15 18:07   still running

wtmp begins Thu Oct 15 18:07:39 2026
$ reboot -w
$ echo "退出码=$?"
退出码=0
$ last -x reboot
reboot   system boot  6.8.0-138-generi Thu Oct 15 18:07   still running

wtmp begins Thu Oct 15 18:07:39 2026
$ systemctl is-system-running
running

第二次验证（md5 直接对比文件字节）：

$ md5sum /var/log/wtmp
46978aa93d26974e9218682781c94ae4  /var/log/wtmp
$ reboot -w
$ md5sum /var/log/wtmp
46978aa93d26974e9218682781c94ae4  /var/log/wtmp

💡 要点：

1. 在 systemd 249 上，reboot -w 退出码 0、无任何输出、系统保持运行，但 /var/log/wtmp 一个字节都没变——帮助文本描述的「write wtmp record」行为在本版本上不存在（halt -w 与 poweroff -w 同样实测无变化，md5 与上文完全一致）；
2. -w 因此成为 reboot 家族里唯一绝对非破坏的参数：即使与 -f 组合（reboot -w -f）系统也不会停止——本文所有参数解析类实验都借助它安全完成；
3. 如果目的是「构造一条 wtmp 记录」用于测试审计工具，本版本该参数不可用，需要另寻途径；写运维文档时请不要照抄老教程的 -w 行为描述。

3.8 -d：声称「不写 wtmp」，优雅路径拦不住（真实踩坑#3）

帮助文本声称 -d --no-wtmp 是 "Don't write wtmp record"。真实执行 reboot -d 后恢复，查看头部：

$ last -x | head -5
runlevel (to lvl 5)   6.8.0-138-generi Fri Oct 16 10:07   still running
reboot   system boot  6.8.0-138-generi Fri Oct 16 10:07   still running
shutdown system down  6.8.0-138-generi Fri Oct 16 10:07 - 10:07  (00:00)
runlevel (to lvl 5)   6.8.0-138-generi Fri Oct 16 10:07 - 10:07  (00:00)
reboot   system boot  6.8.0-138-generi Fri Oct 16 10:07 - 10:07  (00:00)

第 3 行的 shutdown system down 10:07 - 10:07 正是本次 reboot -d 结束的那个 boot 的留痕——-d 没有拦住它。journal 同时确认动作本身正常（仍是重启）：

Oct 16 10:07:38 b8307d66e0c6 systemd[1]: systemd-reboot.service: Deactivated successfully.
Oct 16 10:07:38 b8307d66e0c6 systemd[1]: Finished System Reboot.
Oct 16 10:07:38 b8307d66e0c6 systemd[1]: Reached target System Reboot.

💡 要点：

1. 原因在架构：优雅路径的 wtmp 留痕由停机序列中的 systemd-update-utmp 服务写入（3.2 节 journal 序列里的 Stopped Record System Boot/Shutdown in UTMP.），-d 是 systemctl 进程自己的开关，而优雅路径下写记录的活根本不经过 systemctl 进程，所以参数无效；
2. -d 唯一能影响的是强制路径（reboot -d -f）——但强制路径本来就什么都不写（3.6 节），等于无处可拦；
3. 结论：想「悄悄重启、不留 down 记录」在本版本上做不到，审计时 last -x 的记录是可信的。

3.9 --no-wall：不发广播消息（优雅路径实测）

--no-wall 只控制停机前的 wall 广播，不影响停机动作本身。真实执行：

reboot --no-wall

journal 确认动作正常完成（时间戳 10:07:44 对应本次执行）：

Oct 16 10:07:44 b8307d66e0c6 systemd[1]: systemd-reboot.service: Deactivated successfully.
Oct 16 10:07:44 b8307d66e0c6 systemd[1]: Finished System Reboot.
Oct 16 10:07:44 b8307d66e0c6 systemd[1]: Reached target System Reboot.

💡 要点：

1. 与 shutdown 不同，reboot 家族没有接受自定义消息正文的位置参数（[ARG] 不是消息，见 3.12 节），系统广播的固定文案（如 "The system is going down for reboot NOW!"）由 logind 在调度时生成，--no-wall 的作用就是连这条固定广播也省去；
2. 本实测环境无交互登录会话，广播文案差异不作为本文的实测结论；在多用户生产机上，摘掉广播等于用户毫无预警被踢线，维护窗口外请勿使用；
3. 需要自定义广播内容的延时重启，用 shutdown -r +m '消息'（shutdown 篇已实测 WALL 消息机制）。

3.10 非 root 执行：logind 拒绝 + 报错三连

普通用户执行 reboot 会被拒绝。实测（演示用户 pwuser 通过 useradd -m -s /bin/bash pwuser 创建）：

$ su - pwuser -c "reboot"
Failed to reboot system via logind: Access denied
Failed to open initctl fifo: Permission denied
Failed to talk to init daemon.
$ echo "退出码=$?"
退出码=1

halt 与 poweroff 在非 root 下的报错形态完全相同，仅第一行动词不同（Failed to halt system via logind: Access denied / Failed to power off system via logind: Access denied），退出码同为 1。测试后清理演示用户（userdel -r pwuser）。

💡 要点：

1. 三连报错暴露了 systemctl 的降级尝试链：先问 systemd-logind（被 polkit 拒绝，Access denied）→ 再尝试 SysV 兼容的 /run/initctl fifo（Permission denied）→ 最后尝试直接和 init daemon 通话（失败）——三层全被拒后才放弃，退出码 1；
2. 与 shutdown 的非 root 报错形态不同（shutdown 报 Failed to call ScheduleShutdown in logind, no action will be taken: Access denied，因为 shutdown 走的是「调度」方法）——reboot 走的是「立即执行」方法，报错更短；
3. 授权普通用户重启的正道是 polkit 规则或 sudo /usr/sbin/reboot，而不是给用户组乱七八糟的设备权限。

3.11 非法选项：unrecognized option 退出码 1

$ reboot --bogus
reboot: unrecognized option '--bogus'
$ echo "退出码=$?"
退出码=1

💡 要点：报错前缀是 reboot:（argv[0] 名义），退出码 1。监控脚本里可以用退出码区分「参数错误」与「执行成功」，但要记住 reboot 成功时调用方通常会随主机一起消失，退出码检查更多用于 -w 这类非破坏组合。

3.12 [ARG] 位置参数：reboot 独静默接受一个

三个命令的帮助首行都有 [ARG] 位置参数（halt 的帮助例外，见 halt 篇），但实测接受度不一致。用 -w 组合保证非破坏：

$ reboot -w foo
$ echo "ARG foo 退出码=$?"
ARG foo 退出码=0
$ halt -w bar
Too many arguments.
$ echo "ARG bar 退出码=$?"
ARG bar 退出码=1
$ poweroff -w baz
Too many arguments.
$ echo "ARG baz 退出码=$?"
ARG baz 退出码=1

💡 要点：

1. 同样的 [ARG] 语法，三种行为：reboot 静默接受恰好 1 个（无任何可见效果），halt 与 poweroff 直接拒绝（Too many arguments.，退出码 1）；
2. 帮助文本没有解释 [ARG] 的用途，本环境实测它也不产生任何可观察效果——写脚本时不要往这个位置传任何有意义的参数，各版本行为不保证一致；
3. 这个不对称是「同一套代码、按 argv[0] 分派后各自再校验」的典型产物，遇到类似「帮助相同、行为不同」的情况，以实测为准。

3.13 技术拓展：四命令对比与动作切换矩阵

reboot/halt/poweroff/shutdown 四命令的完整实测对照（本表所有结论均出自本环境实测，细节见各篇对应小节）：

动作切换矩阵（名义 × 选项，括号内为 journal/动词回显证据）：

💡 要点：

1. 长选项 --halt/--reboot 无条件生效（矩阵中三行全部命中）；短选项 -p 只在 halt/poweroff 名义下有意义，在 reboot 名义下被忽略——这是四命令家族最反直觉的一个角落，也是「看帮助写脚本」会翻车的实证；
2. halt 与 poweroff 的差别只在最后一步（是否请求断电），在无可控电源域的环境里两者最终表现一致，只有 journal 判定行能区分；
3. 生产建议一句话版：定时/带广播/可取消的重启用 shutdown -r，立即重启用 reboot，关机用 poweroff，halt 留给真正需要「停在那里」的物理机场景。

四、实战示例

4.1 重启后用 wtmp 对账（审计闭环）

重启是高频运维动作，重启后第一时间对账能确认「这次重启是计划内的、干净的」。重启前先记下当前 boot 时间：

who -b
reboot

实测回显（重启前，who -b 显示当时 boot 时间为 10:59）：

         system boot  Oct 16 10:59
--- 执行 reboot ---

恢复后执行：

who -b
last -x reboot | head -3
last -x shutdown | head -3

实测回显：

$ who -b
         system boot  Oct 16 11:12
$ last -x reboot | head -3
reboot   system boot  6.8.0-138-generi Fri Oct 16 11:12   still running
reboot   system boot  6.8.0-138-generi Fri Oct 16 10:59 - 11:12  (00:12)
reboot   system boot  6.8.0-138-generi Fri Oct 16 10:59 - 11:12  (00:12)
$ last -x shutdown | head -3
shutdown system down  6.8.0-138-generi Fri Oct 16 11:12 - 11:12  (00:00)
shutdown system down  6.8.0-138-generi Fri Oct 16 10:56 - 10:56  (00:00)
shutdown system down  6.8.0-138-generi Fri Oct 16 10:07 - 10:08  (00:00)

解读：

1. who -b 从 10:59 更新为 11:12，与 last -x reboot 第一行的 still running 吻合——本次重启的「新 boot」已登记；
2. 第二行 10:59 - 11:12 (00:12) 是刚被本次重启结束的旧 boot（时长 12 分钟）；本机此前实测过多次强制停机，wtmp 中留下了重复的 boot 记录条目（第 2、3 行内容相同），属多次非优雅/优雅混合停机的叠加痕迹——审计时若看到成对重复记录，优先查强制停机历史；
3. last -x shutdown 最新一条 11:12 - 11:12 正是本次优雅重启写下的 down 记录——它与 last -x reboot 的新 boot 记录成对出现，说明本次是干净的优雅重启而非强制重启。

4.2 需要「延时重启」时怎么办

reboot 家族没有时间参数，延时或定时重启属于 shutdown 的能力域。用 -r 组合延时格式的实测：

date
shutdown -r +5 'pw-test: reboot in 5 minutes'
echo "退出码=$?"
shutdown -c 'pw-test: cancel reboot'
echo "取消退出码=$?"

实测回显：

$ date
Fri Oct 16 11:12:42 UTC 2026
$ shutdown -r +5 'pw-test: reboot in 5 minutes'
Reboot scheduled for Fri 2026-10-16 11:17:42 UTC, use 'shutdown -c' to cancel.
$ echo "退出码=$?"
退出码=0
$ shutdown -c 'pw-test: cancel reboot'
$ echo "取消退出码=$?"
取消退出码=0

延时格式的完整行为（now/+m/hh:mm 三种时间、计划覆盖、/run/nologin 拦截登录、wtmp 证据）见 shutdown 篇 3.2/3.3/3.4 节。reboot 的正确定位是「立即重启」：不需要预告、不需要取消、马上执行。

4.3 系统无响应时的强制重启

优雅路径无响应（服务卡死、D 状态进程堆积）时，reboot -f 是最后手段：

$ reboot -f
Rebooting.

执行后主机立即重启。结合 3.6 节实测，强制重启的代价清单：服务无优雅关闭、文件系统缓存未回写、wtmp 不产生 down 记录且旧 boot 记录留僵尸态。恢复后建议立即检查文件系统日志（journalctl -b -1 -p err，本环境 journal 分组受运行环境影响，物理机上此命令可用）与 fsck 计划。

4.4 脚本中安全重启的前置检查

把 reboot 写进自动化脚本时，两个前置检查实测有效：

#!/bin/bash
# 前置检查 1：系统处于可停机状态
state=$(systemctl is-system-running)
if [ "$state" != "running" ]; then
    echo "系统状态异常（$state），拒绝重启" >&2
    exit 1
fi
# 前置检查 2：权限试探（借用 -w 组合，非破坏）
reboot -w
if [ $? -ne 0 ]; then
    echo "重启权限不足（非 root 或 polkit 拒绝）" >&2
    exit 1
fi
reboot

实测依据：systemctl is-system-running 在本环境返回 running（一、环境信息）；reboot -w 非破坏（3.7 节）且非法参数/权限问题的退出码均为 1（3.10/3.11 节）。

💡 要点：-w 权限试探在 249 上因「不写记录」而变得纯粹——它只走参数解析与权限链路，不产生副作用，正好适合当探针。

五、注意事项与常见问题

Q1：reboot -p 为什么没有关机，反而重启了？

这是本环境 systemd 249 的实测行为：-p 在 reboot 名义下被参数解析层忽略（reboot -p -f 的动词回显是 Rebooting. 而非 Powering off.，journal 结局行是 Reached target System Reboot.）。帮助文本的 -p --poweroff Switch off the machine 描述与该版本实现不符。要断电请用 poweroff 或 halt -p（后者实测生效，journal 结局行为 Reached target System Power Off.）。

Q2：reboot -w 为什么没有生成 wtmp 记录？

实测（last -x 前后对比 + /var/log/wtmp md5 前后一致）确认 249 上该参数什么都没写。-w 的价值仅剩「绝对非破坏」：配合任何选项都不会停机（含 -f），可作为参数解析探针使用（4.4 节）。老教程中「-w 用于构造 wtmp 记录」的说法在本版本上不成立。

Q3：怎么从日志确认上次到底执行的是重启、关机还是挂起？

看 journal 的收尾判定行（3.2/3.4/3.5 节实测归纳）：

wtmp 层面只能区分「优雅（有 down 记录）」与「强制（无 down 记录 + 僵尸 boot 记录）」，区分不了动作类型，必须看 journal。

Q4：非 root 执行 reboot 的三行报错是什么意思？

Failed to reboot system via logind: Access denied（logind 的 D-Bus 方法被 polkit 拒绝）→ Failed to open initctl fifo: Permission denied（降级尝试 SysV 兼容的 /run/initctl 管道）→ Failed to talk to init daemon.（最后的降级也失败）→ 退出码 1。三层全失败才放弃，说明系统三层停机通道都在且都被权限拦住，属正常防护，不是故障。

Q5：reboot 与 shutdown -r now 有什么区别？

两者最终都走 systemd 的优雅重启序列，journal 结局行相同（Reached target System Reboot.）。区别全在入口层：shutdown 支持 [TIME] 延时（+m/hh:mm）、支持自定义广播消息、有 -c 取消机制、会写 /run/nologin 拦截后续登录；reboot 一概没有，回车即重启。多人使用的生产机选 shutdown -r，单人维护窗口用哪个都是同一结局。

六、参考链接

• reboot/halt/poweroff 共用手册：man halt（man 8 halt；本实测环境未安装 man 手册页，可在装有 man-db 的系统上查看）
• systemctl 手册：man systemctl（man 1 systemctl）
• reboot(2) 系统调用：https://man7.org/linux/man-pages/man2/reboot.2.html
• systemd 官方文档（systemctl / systemd-halt.service / systemd-poweroff.service）：https://www.freedesktop.org/wiki/Software/systemd/
• Ubuntu systemd 软件包页（249.11-0ubuntu3.23 源码与变更记录）：https://launchpad.net/ubuntu/+source/systemd
• 同族姊妹篇：《shutdown 命令详解与参数实测（Ubuntu 22.04）》《halt 命令详解与参数实测（Ubuntu 22.04）》《poweroff 命令详解与参数实测（Ubuntu 22.04）》