用 systemd Timer 实现服务器定时重启：原理、优势与常见差异

很多人提到“定时重启”，第一反应是写一条 cron：每天凌晨执行 reboot。但在采用 systemd 的现代 Linux 发行版上，用 systemd 的 service + timer 来做计划任务，往往更稳、更可观测，也更符合系统的运行方式。下面基于你给出的配置，拆解这种重启方案的工作机制，并和“普通定时重启”做一次对比。

这套方案到底做了什么？

你的做法由两部分组成：

• reboot-task.service：一个一次性（oneshot）服务，真正执行重启动作
• reboot-task.timer：一个定时器，负责在指定时间点触发上面的 service

它的核心思想是：把“什么时候执行”交给 timer，把“执行什么”交给 service。

1）Service：只负责执行重启

sudo tee /etc/systemd/system/reboot-task.service <<EOF
[Unit]
Description=Scheduled Reboot Service

[Service]
Type=oneshot
ExecStart=/sbin/reboot
EOF

• Type=oneshot：表示这是“一次性任务”，执行完即结束，不会常驻。
• ExecStart=/sbin/reboot：启动时执行重启命令。
• 由于这是系统级 unit（放在 /etc/systemd/system/），通常以 root 身份运行，避免了权限不足的问题。

2）Timer：定义每天 03:00 触发

sudo tee /etc/systemd/system/reboot-task.timer <<EOF
[Unit]
Description=Run Scheduled Reboot Daily

[Timer]
OnCalendar=*-*-* 03:00:00
Unit=reboot-task.service

[Install]
WantedBy=timers.target
EOF

• OnCalendar=*-*-* 03:00:00：每天 03:00:00 触发（使用 systemd 的日历语法）。
• Unit=reboot-task.service：触发时启动指定的 service。
• WantedBy=timers.target：让它可以通过 enable 加入开机启动序列（timer 目标）。

3）加载、启用、验证

sudo systemctl daemon-reload
sudo systemctl enable --now reboot-task.timer

验证：

systemctl status reboot-task.timer
systemctl list-timers --all | grep reboot

停止（临时）：

sudo systemctl stop reboot-task.timer

更彻底的停止方式通常还会再加一句禁用（防止下次开机又自动启动）：

sudo systemctl disable reboot-task.timer

为什么要用 tee 重建，而不是手动编辑？

避免手动打开编辑器引入非法字符，这点非常关键。systemd 的 unit 文件对格式很敏感，常见坑包括：

• 行尾多余空格、不可见字符（尤其从网页/IM 复制后）
• [Section] 标签缺失或拼错
• 文件编码异常（比如带 BOM）
• 误放路径或文件名不匹配（timer 里引用的 Unit 名称不一致）

用 tee + heredoc 的好处是：生成内容更“干净”、可重复、可审计，一旦出问题也更容易回滚和复现。

它和“普通的定时重启”有什么区别？

这里的“普通”通常指 cron 定时任务（例如在 root 的 crontab 里写 0 3 * * * /sbin/reboot）。两者都能达到“每天重启”，但在工程化体验上差别很明显：

1）调度体系不同：systemd 原生 vs cron 外挂

• systemd timer 是 systemd 生态的一部分：统一的启动、依赖、日志、状态管理都在同一套系统里。
• cron 是独立的调度器：任务运行和系统服务是两套体系，排障时经常要跨工具链。

2）可观测性：状态与日志更清晰

• systemd：systemctl status 能看 timer 是否在等待、下一次触发时间；journalctl -u reboot-task.service 能直接查执行记录。
• cron：更多依赖 syslog/邮件输出，或你额外重定向日志；在不少精简系统里日志还可能没配全。

3）错误反馈与“配置正确性”更可控

• systemd：daemon-reload / start 会做语法校验，错了就明确报错，且状态可见。
• cron：语法错/路径错经常是“静默失败”，直到你发现它没重启。

4）执行环境更一致

• systemd unit：你可以显式设定运行用户、环境变量、依赖关系、执行前后动作等（扩展性更强）。
• cron：默认环境很“瘦”，PATH 不同、环境变量缺失是经典问题。

5）错过时间点时的行为更容易“设计”

你当前 timer 没写 Persistent=true，因此它的默认行为更接近：只有在机器运行且到点时才触发。
如果你希望“服务器当时关机/宕机，恢复后也补执行一次”，systemd timer 可以加：

[Timer]
Persistent=true

cron 也有“重启后补跑”的变体方案，但一般要自己写补偿逻辑或借助 anacron；systemd timer 在这类能力上更直接。

实战建议：让它更稳、更好排查

如果你打算长期运行，建议加上两条“运维友好型”增强：

1）执行记录排查（很常用）：

journalctl -u reboot-task.timer --since "7 days ago"
journalctl -u reboot-task.service --since "7 days ago"

2）提前验证日历表达式（避免写错时间）：

systemd-analyze calendar "*-*-* 03:00:00"