Linux systemd定时器替代cron任务

把cron任务迁移到systemd，可以拆成一份描述“执行什么”的service和一份描述“何时触发”的timer。对每天02:15执行一次的前台脚本，使用Type=oneshot配合OnCalendar即可；需要错过时间后补一次，再设置Persistent=true。迁移时要停用旧cron的对应行，避免两套调度同时执行。

官方手册：https://www.freedesktop.org/software/systemd/man/latest/systemd.timer.html

确定迁移范围与最小配方

本文使用系统级unit，适合以systemd作为服务管理器的Linux。需要管理员权限保存配置；容器里若没有运行systemd，不能直接照用。演示任务只写日志，不操作业务数据，配置与命令供读者操作，没有声称已在本机执行。

先记录旧cron的执行身份、时区、工作目录、环境变量及真实命令。本文演示采用常见的nobody账号；若发行版不存在该账号，应换成已有、权限合适的专用用户。生产任务也应使用自己的服务账号，而不是直接复制演示身份。

保存三份文件：/usr/local/libexec/daily-note.sh、/etc/systemd/system/daily-note.service和/etc/systemd/system/daily-note.timer。文件由管理员拥有，脚本需对执行账号可读，父目录可进入；本文通过/bin/sh读取脚本，无需依赖脚本可执行位。

定义可观察的一次性服务

脚本内容如下，输出进入journal。换成业务脚本时，保持进程在前台，并让失败通过非零退出码返回。

#!/bin/sh
# 演示只向标准输出写一条记录；生产任务应保留失败退出码。
set -eu
printf 'daily-note: %s\n' "$(/usr/bin/date -Is)"

service文件内容如下：

[Unit]
Description=Write a daily journal note

[Service]
# 前台运行一次，退出码交给systemd记录，不设置RemainAfterExit。
Type=oneshot
User=nobody
WorkingDirectory=/usr/local/libexec
ExecStart=/bin/sh /usr/local/libexec/daily-note.sh
StandardOutput=journal
StandardError=journal

WorkingDirectory明确相对路径的基准。ExecStart明确解释器和脚本路径，避免继承交互终端环境的假设。service没有[Install]段，因为日常调度由timer负责，不需要单独设置service开机自启。

不设置RemainAfterExit=yes：该选项可能让任务退出后服务仍保持active，后续定时触发便不会重新启动这份活跃服务。这里需要的是每次前台工作结束后，服务回到非活跃状态。

配置每日触发与错过补跑

[Unit]
Description=Schedule the daily journal note

[Timer]
# 每天本地时间02:15触发，实际启动仍受调度条件影响。
OnCalendar=*-*-* 02:15:00
AccuracySec=1s
# 不活跃期间错过日历触发时，激活后补一次，而非逐次回放。
Persistent=true
Unit=daily-note.service

[Install]
WantedBy=timers.target

OnCalendar使用日历时间。此表达式未显式写时区，按系统本地时间解释，迁移时要核对主机时区。AccuracySec=1s缩小时间合并窗口，但不是“任务必在精确一秒内启动”的实时保证。

Persistent记录上次触发时间。若timer不活跃期间原本至少应触发一次，重新激活时可以补触发一次；它不会根据错过天数自动生成多次任务。需要逐个日期补账的业务，应由脚本根据业务记录判断缺口。

timer也不是持久化业务队列。启用Persistent不等于执行失败后自动重试，不应把“触发过”当作“业务成功”。

启动并查看状态日志

保存文件后，先手动运行service，确认账号、路径和日志正常。演示脚本只输出时间，业务任务则要先确认手动运行是否会产生重复数据。

# 先读取新配置，仅手动运行service，确认脚本与执行身份可用。
sudo systemctl daemon-reload
sudo systemctl start daily-note.service
sudo systemctl show daily-note.service -p Result -p ExecMainStatus
sudo journalctl -u daily-note.service -n 20 --no-pager

# 确认旧cron的对应行已停用且没有旧实例运行，再启用timer。
sudo systemctl enable --now daily-note.timer
systemctl list-timers --all daily-note.timer

Result=success和ExecMainStatus=0反映服务执行结果，journal能看到脚本输出。对于本例，oneshot成功结束后显示inactive并不异常；timer应处于等待状态，并能在list-timers中查看下一次计划。

不要把enable与start混为一谈：这里--now同时启动timer；只enable并不立即启动。修改已运行timer的配置后，先daemon-reload，再重启timer使其采用新安排。

选择间隔变体与处理迁移坑点

若需求是“任务完成后休息五分钟”，替换整个[Timer]段为下面内容，并保留原[Install]段。这与“每五分钟的整点刻度执行”不同。

[Timer]
# 替换原[Timer]段：首次启用一分钟后执行，以后每次任务结束五分钟后再执行。
OnActiveSec=1min
OnUnitInactiveSec=5min
Unit=daily-note.service

用完整替换避免意外保留OnCalendar形成两套触发条件；多个计时条件可以同时存在，不是后写的天然覆盖先写的。该变体属于相对计时，本文的Persistent补跑说明针对日历定时器。

ExecStart不是通用shell命令行：不要直接照搬cron中的重定向、管道和复合逻辑。复杂操作放进脚本里，脚本内再用合法shell语法与错误处理。凭据也不应写成公开命令参数或普通示例环境变量。

回退与相关问题

# 停用后续调度；这不会自动终止已经运行的service。
sudo systemctl disable --now daily-note.timer
# 查看当前任务；需要中断时先确认业务允许，再执行stop。
systemctl status daily-note.service --no-pager

回退到cron前，先停用timer并确认service没有继续执行，再恢复原cron行。避免在旧实例仍运行时启动另一套调度。仅停止timer不等于中断当前任务；若业务允许中断，可另行执行sudo systemctl stop daily-note.service。

关机三天后会补跑三次吗？

不会按天自动回放三次。日历timer的Persistent机制补一次触发；业务补处理范围应由任务自己的状态决定。

任务失败后timer还会等待下一次吗？

通常仍按后续计划触发。失败重试需要单独设计；本例没有设置自动重试策略。

可以直接使用用户级timer吗？

可以，但配置路径、systemctl的--user选项和用户服务管理器生命周期都不同。不要把本文系统级路径与用户级命令混用；退出登录后的持续运行条件也需单独安排。

服务配置参考：https://www.freedesktop.org/software/systemd/man/latest/systemd.service.html

执行环境参考：https://www.freedesktop.org/software/systemd/man/latest/systemd.exec.html