- 使用 systemd 定时器实现服务定时重启需创建 .service 和 .timer 两个单元文件；2. 将 my-app.service 放入 /etc/systemd/system/ 并定义启动、停止命令及运行用户；3. 创建 my-app.timer 文件，设置 oncalendar=–* 03:00:00 实现每日凌晨 3 点触发，unit=my-app.service 指定目标服务，persistent=true 确保错过的任务在系统恢复后执行；4. 执行 sudo systemctl daemon-reload、enable 和 start 命令激活定时器；5. systemd 定时器优于 cron 的主要体现在：与服务系统无缝集成，日志和状态可通过 systemctl 和 journalctl 统一管理；支持环境变量、依赖关系和资源控制；具备 persistent 机制避免任务遗漏；6. 调试时使用 systemctl list-timers –all 查看所有定时器状态，systemctl status my-app.timer 检查具体定时器信息，journalctl -u my-app.service 分析服务执行日志；7. 高级功能包括：randomsec 实现随机延迟以分散集群负载，onbootsec 设置开机后延迟执行，onunitactivesec 基于服务运行时长触发，path/mount 单元实现文件或挂载点变化触发，oncalendar 支持灵活日历表达式如 mon..fri 18:00 或 weekly。通过这些机制，systemd 定时器提供了比 cron 更可靠、可维护和功能丰富的定时任务解决方案。
实现服务定时重启，使用
systemd
定时器（
timer
单元）是比传统
cron
更现代、集成度更高且管理更便捷的选择。它能与
systemd
服务单元无缝协作，提供更精细的控制和更清晰的状态报告。
解决方案
要通过
systemd
定时器实现服务的定时重启，核心在于创建两个文件：一个
systemd
服务单元（
.service
）来定义要执行的操作，以及一个
systemd
定时器单元（
.timer
）来定义何时执行该操作。
假设我们要定时重启一个名为
my-app
的服务。
步骤：
-
创建或确认服务单元 (
.service
) 如果你的服务已经有
systemd
服务单元，那很好。如果没有，你需要为它创建一个。这个文件通常放在
/etc/systemd/system/
目录下，例如
my-app.service
。
# /etc/systemd/system/my-app.service [Unit] Description=My Custom Application After=network.target # 确保网络就绪后启动 [Service] ExecStart=/usr/local/bin/my-app-start.sh # 你的服务启动脚本或命令 ExecStop=/usr/local/bin/my-app-stop.sh # 你的服务停止脚本或命令 (可选，但推荐) Restart=on-failure # 服务失败时自动重启 User=myuser # 运行服务的用户 Group=myuser # 运行服务的用户组 [Install] WantedBy=multi-user.target
-
创建定时器单元 (
.timer
) 接下来，你需要创建一个与服务单元同名的定时器单元，但后缀是
.timer
。这个文件也放在
/etc/systemd/system/
目录下，例如
my-app.timer
。
假设我们希望每天凌晨 3 点重启
my-app.service
。
# /etc/systemd/system/my-app.timer [Unit] Description=Daily restart timer for My Custom Application RefuseManualStop=true # 可选，防止意外手动停止这个定时器 [Timer] OnCalendar=*-*-* 03:00:00 # 每天凌晨 3 点执行 Persistent=true # 如果系统在 3 点关机，开机后会立即执行错过的任务 Unit=my-app.service # 当定时器触发时，激活这个服务 AccuracySec=1min # 定时器的精度，默认 1 秒，1 分钟通常足够 [Install] WantedBy=timers.target
-
OnCalendar
是核心，它定义了触发时间。
-
Unit
指向要触发的服务单元。
-
Persistent=true
是一个非常实用的功能，它确保即使系统在预定时间离线，任务也会在系统恢复后立即执行。
-
-
激活并启动定时器 创建完文件后，需要让
systemd
重新加载配置，然后启用并启动你的定时器。
sudo systemctl daemon-reload # 重新加载 systemd 配置 sudo systemctl enable my-app.timer # 设置定时器开机自启动 sudo systemctl start my-app.timer # 立即启动定时器
通过这些步骤，你的
my-app.service
就会在每天凌晨 3 点被
systemd
定时器触发，从而实现定时重启。
为什么说systemd定时器是更好的选择？
我觉得，相比
cron
，
systemd
定时器确实提供了更现代、更集成化的解决方案，用起来也更舒服。
首先，它与
systemd
服务管理体系的无缝集成是最大的优势。
cron
是一个相对独立的系统，你配置一个
cron
任务，它和你的
systemd
服务是割裂的。而
systemd
定时器直接就是
systemd
生态的一部分，它能直接激活或停止
systemd
服务单元，这意味着所有相关的日志、状态报告都能通过
journalctl
和
systemctl
命令统一管理。当服务出问题时，你不用再去
syslog
里翻找
cron
的输出，或者检查邮件，所有信息都在
journalctl -u your-service.service
或
journalctl -u your-timer.timer
里，排查问题效率高多了。
其次，可控性和灵活性也远超
cron
。
systemd
定时器可以精确控制定时任务的运行用户、环境变量，甚至可以设置复杂的依赖关系。比如，你可以指定某个定时任务必须在某个服务启动后才能运行。
cron
在环境变量管理上就有点麻烦，有时候你写个脚本，在
cron
里跑不起来，就是因为环境路径不对。
还有就是它的持久性（
Persistent=true
）功能，这在服务器运维中非常实用。如果你的服务器在定时任务应该执行的时候关机了，
cron
默认是不会补执行的，这个任务就错过了。但
systemd
定时器有了
Persistent=true
，系统开机后，它会检查是否错过了任务，如果错过了，就会立即执行。这对于确保关键的维护任务（比如数据备份或日志清理）不会因为意外停机而遗漏，非常重要。
最后，
systemd
定时器提供了更细致的精度控制（
AccuracySec
）和资源管理。你可以设置定时器的触发精度，避免不必要的频繁唤醒或资源竞争。并且，由于它运行在
systemd
的 CGroup 机制下，对任务的资源消耗管理也更透明、更可控。我觉得，这些特性加起来，让
systemd
定时器在可靠性、可维护性和功能性上都远胜
cron
。
如何调试和查看systemd定时器的运行状态？
在实际运维中，能够快速调试和查看
systemd
定时器的运行状态非常关键。毕竟，配置写好了，但它是不是真的按预期工作，总得验证一下。
最直接的方法是使用
systemctl list-timers --all
命令。这个命令会列出所有已加载的定时器，包括下次触发时间、上次触发时间、以及对应的服务。我经常用它来快速浏览一遍，看看有没有定时器没启用，或者下次触发时间是不是我预期的。
如果你想深入了解某个特定定时器的状态，比如
my-app.timer
，你可以用
systemctl status my-app.timer
。它会显示这个定时器的详细信息，包括它的加载路径、是否激活、是否启用自启动，以及上次和下次的运行时间。如果定时器没按预期触发，这里通常能找到线索，比如它可能根本没被
enable
或
start
。
日志是排查问题的黄金标准。当定时器触发服务时，服务的输出都会被
journalctl
捕获。所以，查看
journalctl -u my-app.service
可以看到服务被定时器触发后的具体运行情况，有没有报错，或者有没有正常重启。有时，我也会看
journalctl -u my-app.timer
，虽然定时器本身的日志相对较少，但如果定时器自身有问题（比如配置错误），这里也会有记录。这比
cron
的日志分散在
/var/log/syslog
或者邮件里，真的方便太多了。
如果我想测试服务本身能不能正常启动，而不想等待定时器触发，我可以直接用
systemctl start my-app.service
。这在开发和调试阶段特别有用，可以快速验证服务单元的配置是否正确。
另外，如果定时器没有触发，除了检查
systemctl status
，我还会看看
journalctl -u systemd
或者
journalctl -b
（查看本次启动以来的所有日志），里面有没有
systemd
自身关于定时器处理的错误信息。有时候，权限问题或者服务单元本身的问题会导致定时器虽然触发了，但服务却没能成功启动或重启。
systemd定时器在实际应用中还有哪些高级用法？
systemd
定时器除了基本的定时功能，还有一些非常实用的高级用法，这些功能在
cron
里要么没有，要么实现起来非常复杂。
一个我觉得非常棒的功能是随机延迟（
RandomSec
）。在
[Timer]
段里加上
RandomSec=300
（表示 300 秒，即 5 分钟），那么定时器会在指定时间点后的 5 分钟内随机一个时间点触发。这对于大规模部署的服务器集群来说，简直是救星。想象一下，你有一百台服务器，都要在每天凌晨 3 点执行一个 CPU 密集型的备份任务，如果都同时开始，瞬间的网络和存储压力会非常大。有了
RandomSec
，它们就会错开一点时间，避免了瞬时峰值，大大缓解了系统压力。
另一个很有用的场景是开机后延迟（
OnBootSec
）。比如，
OnBootSec=10min
表示系统启动 10 分钟后执行一次任务。这对于那些需要系统完全稳定、所有服务都跑起来之后才能执行的任务非常有用，避免了在系统启动初期资源紧张或服务未就绪时就强行启动任务。
还有基于服务状态的触发，比如上次执行后延迟（
OnUnitActiveSec
或
OnUnitInactiveSec
）。
OnUnitActiveSec=1h
意味着在关联的服务单元活跃了 1 小时后再次触发。这比
cron
的固定时间点灵活多了，可以实现基于服务运行状态的调度。比如，你可以设置一个任务，在你的应用服务持续运行一段时间后进行一次健康检查。
虽然不是直接的
timer
，但
systemd
生态中还有
Path
单元和
Mount
Path
单元可以在特定文件或目录发生变化时触发服务，比如当一个新的日志文件出现时，触发一个日志分析服务。
Mount
单元则可以在特定的文件系统挂载点可用时触发服务。这些都是
systemd
提供的高度集成的自动化工具，可以替代一些传统上需要复杂脚本才能实现的监控和触发逻辑。
最后，
OnCalendar
的日历表达式其实非常灵活和强大，远不止
*-*-* 03:00:00
这么简单。你可以用
Mon..Fri 18:00
来表示工作日晚上 6 点，或者
weekly
、
monthly
这样的关键字，甚至
*-*-* 00:00:00/2
来表示每隔两天午夜。我觉得，这些丰富的表达式，让定时任务的定义变得更加直观和精确，比
cron
的五个星号要好理解得多。
