查看定时器是什么
list-timers 把所有 systemd timer 汇总成一张表：下次触发时间（NEXT）、距离触发还有多久（LEFT）、上次触发时间（LAST）、距上次过去多久（PASSED），以及它拉起的单元（ACTIVATES）。核对「定时任务到底什么时候跑」时，它比逐个 systemctl status 快得多，也是排查「定时任务没跑」的第一入口。
基本信息
| 适用平台 | Linux（systemd） |
|---|---|
| 命令语法 | systemctl list-timers [--all] [模式] |
| 常用选项 | --all 包含未激活的 timer --no-pager 便于管道处理 模式参数按名称过滤 |
| 关键关系 | timer 负责触发，触发后启动同名的 .service；命令写在 service 里 |
| 权限说明 | 普通用户可读 |
典型使用场景
- 盘点机器上有哪些定时任务：避免「谁在凌晨跑任务」这类无人能回答的问题
- 确认下次触发时间：变更窗口前先看 NEXT 是否与预期一致
- 排查任务没跑：对比 LAST 与 PASSED，判断是没触发还是触发了但失败
- 核对单元配对：确认 timer 对应的 service 名称正确、内容符合预期
- 清理陈旧任务：用 --all 找出已停用但仍残留的 timer
常用示例
常用示例
systemctl list-timers --all --no-pager # 含未激活的全部定时器
systemctl list-timers 'backup*' # 按名称过滤
systemctl list-timers --no-pager | head -n 20 # 概览
systemctl status backup.timer --no-pager # 单个 timer 的详细状态
systemctl cat backup.timer # 看它的 OnCalendar 定义
systemctl list-timers --all | grep -c timer # 统计数量看它到底拉起什么
看它到底拉起什么
systemctl cat backup.timer # 确认 Unit= 或同名 service
systemctl cat backup.service # 真正的执行命令在这里
journalctl -u backup.service --since today --no-pager | tail -n 30输出列读法
| 列 | 含义 | 怎么看 |
|---|---|---|
| NEXT | 下次触发时间 | 相对时间显示；--no-pager 后仍是相对值 |
| LEFT | 距下次触发还有多久 | 用于确认变更窗口是否够用 |
| LAST | 上次触发时间 | 长期不变说明没被触发过 |
| PASSED | 距上次触发多久 | 配合 OnCalendar 判断是否漏跑 |
| UNIT | timer 单元名 | 确认是否 enabled 与加载 |
| ACTIVATES | 被拉起的 unit | 通常是与 timer 同名的 .service |
LAST 列过旧而 NEXT 在未来：说明上次执行可能失败或被中断，配合 journalctl -u 对应 unit 一起看；如果 LAST 一直是 n/a，说明这个 timer 从未触发过，通常是没 enable 或 OnCalendar 写错。
timer 与 service 是配对关系，理解这点就不会找错地方：触发条件写在 .timer（OnCalendar、OnBootSec 等），真正执行的命令写在 .service 的 ExecStart。改完 .timer 或 .service 都要 daemon-reload，改 .timer 还要 restart 该 timer 才会重新排期。
写完 OnCalendar 先做静态验证：systemd-analyze calendar 'Mon..Fri *-*-* 03:00:00' 会打印规范化后的表达式、下次与再下次触发时间，比反复 restart timer 再看 NEXT 快得多，也能提前发现星期与月份字段写反这类错误。
用相对条件触发的定时器（OnBootSec、OnUnitActiveSec、OnUnitInactiveSec）要另眼看待：它们的下次触发时间会随系统启动时刻与上一次执行时间浮动，核对时不能用固定钟点去比对，只能确认间隔与顺序是否符合设计。