使用C reboot API重启系统时自定义systemd服务执行失败问题

两类重启操作的本质差异如下：

• system("init 6")、system("reboot")、system("systemctl reboot") 这类命令走的是用户空间systemd init系统的有序重启流程：
  • 命令首先和PID 1的systemd进程通信，通知其执行重启流程
  • systemd会依次完成：停止所有运行中服务、重新扫描所有unit配置确认生效状态、同步所有文件系统、按顺序卸载文件系统，最后才调用内核的reboot系统调用触发实际硬件重启
• 直接调用C语言的reboot(LINUX_REBOOT_CMD_RESTART) 是内核级系统调用，完全跳过systemd的所有用户空间处理逻辑：
  • 内核收到调用后，只会执行最基础的脏页回写、强制结束所有用户进程、直接触发硬件重启，不会执行任何systemd层面的配置校验、持久化操作

服务不生效的直接诱因 #

你动态创建并enable服务后，systemd需要将新服务的启动依赖（/etc/systemd/system/multi-user.target.wants下的软链接）的元数据完全同步，并且确认unit配置的有效性，这一步只有走systemd的重启流程才会自动执行。直接调用内核reboot时，即使你主动调用了sync，仍存在两个隐藏问题：

1. 带日志的文件系统（ext4/xfs等）的日志提交可能未完全完成，即便sync返回，部分元数据变更（比如新建的软链接、服务文件的权限属性）可能还未完全落地到磁盘，重启后systemd扫描unit时识别不到新添加的服务
2. 部分系统默认给/var/tmp配置了开机清理规则，如果跳过systemd的正常关机流程，/var/tmp下的临时文件可能被标记为需要清理，导致你生成的脚本在重启后丢失

重启延迟差异的原因 #

你观察到的rebootAPI调用后延迟更高的现象，是因为内核直接处理重启时，需要强制等待所有块设备的IO队列排空、所有硬件资源复位；而systemd的重启流程会提前做完这些准备工作，最后调用内核reboot时已经没有待处理的IO，所以看起来响应更快。

如果要保留用系统调用触发重启的实现，需要在调用reboot前额外执行以下操作：

• 调用system("systemctl daemon-reload") 让systemd刷新内存中的unit配置
• 确认systemctl enable myservice.service 执行完成，服务的启动软链接已经创建
• 主动调用sync() 2~3次，规避日志文件系统的元数据提交延迟
• 等待1~2秒再调用reboot系统调用

最稳妥的方案是直接调用system("systemctl reboot")，完全符合systemd的运行逻辑，不会出现配置不生效的问题。

内容的提问来源于stack exchange，提问作者Shantanu Shinde