Linux 定时器如何确认是否按时触发：状态命令、日志与下次运行时间

服务器上的定时备份“看起来没报错”，并不等于 systemd timer 真的按时执行。确认这件事最稳妥的办法，是先看下次触发时间，再看 timer 自身状态，最后沿着它关联的 service 检查日志和退出状态。

先用 systemctl list-timers 判断调度时间，再用 systemctl status 和 journalctl -u 判断是否实际执行；只看到 timer 处于 active，不能证明备份服务成功。

先确认定时器指向哪一个服务

假设定时器单元名是 nightly-backup.timer。先列出系统当前管理的 timer，避免把同名但未启用的旧文件当成正在运行的任务：

systemctl list-timers --all
systemctl list-timers nightly-backup.timer

第二条命令会把范围收窄到目标单元。重点看四列：NEXT / LAST 是调度时间对，NEXT 是下次触发时间，LEFT 是距离触发的剩余时间，LAST 是最近一次触发，UNIT 是 timer 名称。输出末尾的 nightly-backup.service 则是它实际启动的服务，不要只盯着 .timer 后缀。

用状态信息判断它是在等候还是已经失效

接着查看 timer 单元：

systemctl status nightly-backup.timer --no-pager
systemctl show nightly-backup.timer -p OnCalendar -p LastTriggerUSec -p NextElapseUSecRealtime

正常等待中的 timer 通常显示 Active: active (waiting)。OnCalendar 能确认日历表达式，LastTriggerUSec 和 NextElapseUSecRealtime 用于核对实际触发点。如果 N/A 或下次时间为空，先检查单元是否加载、是否被手工停止，再判断配置本身。

这里有一个容易误判的地方：timer 处于 active (waiting)，只说明调度器还在等待，并不代表关联的 nightly-backup.service 上一次执行成功。服务状态需要单独查询。

沿着 service 和日志确认上一次执行结果

查询关联服务的最近状态：

systemctl status nightly-backup.service --no-pager
journalctl -u nightly-backup.service -n 80 --no-pager

如果看到 active (exited)，通常表示一次性服务已经正常结束；还要在日志中找到本次运行的开始时间和业务结果。看到 failed 时，优先查看同一时间段的错误行，而不是重启 timer 来掩盖现场。

journalctl -u 按 service 单元筛选执行记录，能把“调度发生”和“任务成功”区分开。若 timer 的 LAST 已更新，但 service 日志只有权限、路径或挂载错误，说明调度正常、任务本身失败。

三种常见结果分别怎么处理

还没有到下一次触发时间

NEXT 有明确时间且 Active: active (waiting) 时，先不要手动启动服务。对照 OnCalendar 检查时区和日历表达式，等待到点后再看 LAST 是否更新。

timer 触发了，但 service 是 failed

这类问题不在调度链，而在 service 的执行环境。把 systemctl status nightly-backup.service 的错误摘要和 journalctl -u nightly-backup.service 的完整相关行放在一起看，常见边界包括挂载点尚未出现、运行用户无权写入目标目录，以及脚本返回非零状态。

有 service 状态，却找不到日志

先确认查询的单元名完全一致；nightly-backup.timer 和 nightly-backup.service 是两个不同的日志对象。再用 journalctl --since 限定时间范围，避免旧日志把判断带偏：

journalctl -u nightly-backup.service --since "today" --no-pager

把一次核对结果留成可复查记录

排查结束时至少记录四项：timer 的 NEXT、LAST、OnCalendar，以及 service 的最终状态和日志错误。这样下次出现“没跑”的反馈时，可以快速判断是时间尚未到、调度未加载，还是任务启动后失败。

最小核对顺序可以固定为：

systemctl list-timers nightly-backup.timer
systemctl status nightly-backup.timer --no-pager
systemctl status nightly-backup.service --no-pager
journalctl -u nightly-backup.service -n 80 --no-pager

这四步分别覆盖计划、调度状态、任务状态和执行证据。确认 service 成功后，再考虑是否需要调整日历表达式或失败重试策略。

相关问题

为什么 timer 是 active，但备份文件没有更新？

因为 active (waiting) 只代表 timer 正在等待调度。检查 nightly-backup.service 的状态和日志，才能知道任务是否执行以及是否有权限或路径错误。

手动启动 service 会更新 timer 的 LAST 吗？

通常不会把手动启动等同于 timer 触发。手动运行只能验证 service 本身，调度证据仍应以 timer 的 LAST 和日志时间为准。

总结

systemd 定时任务的核对要沿着“计划时间—timer 状态—service 结果—journal 日志”走完一条链。只查其中一个单元，容易把“已经排队”误判成“已经成功”。