systemd计时器不触发通常源于配置、加载或依赖问题，需先确认是否被识别：运行systemctl list-timers --all查看是否列出，用systemctl is-enabled检查是否启用，用户级timer需loginctl enable-linger，.timer与.service必须同名且配套，OnCalendar表达式需明确，日志应查.service而非.timer单元。
Systemd 计时器不触发，通常不是“没到时间”，而是配置、加载或依赖环节出了问题。它不会像 cron 那样默默失败并留痕迹，反而可能静默跳过——所以排查要从“是否被识别”开始，而不是直接查日志。
确认计时器是否被系统加载并启用
很多问题卡在第一步：文件写了，但 systemd 根本没看到。
- 运行 systemctl list-timers --all，看你的 timer 是否出现在列表中；如果完全没出现，说明未加载或命名/路径有误
- 检查是否启用：systemctl is-enabled your-job.timer，返回 disabled 表示未启用（即使文件存在也不会触发）
- 用户级 timer 必须先登录一次或手动启动 user session：loginctl enable-linger $USER，否则
systemctl --user相关操作无效
验证 .timer 和 .service 文件配对是否正确
这是最常出错的环节。systemd timer 要求两个文件严格配套，缺一不可，且命名、路径、内容逻辑都要对得上。
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 文件名必须一致：
backup.timer必须对应backup.service，不能是backup-job.service - .timer 文件里不能写命令，只允许
OnCalendar=、OnBootSec=、Persistent=true等调度指令；若含ExecStart或命令片段，会加载失败 - .service 文件中
Type=必须为oneshot（默认值可省略），且ExecStart=必须是绝对路径，比如/usr/bin/python3 /opt/scripts/clean.py，不能写python3 clean.py
检查时间表达式与触发逻辑是否合理
OnCalendar 值看起来对，但实际语义可能和你预期不同。
- 用 systemctl show your-job.timer | grep -E "(NextElapse|LastTrigger)" 查看下次/上次触发时间，判断是否符合预期
-
hourly不等于“每小时整点”，它等价于*-*-* *:00:00，但若系统在整点前刚启动，可能错过第一次；建议显式写*-*-* *:00:00并加Persistent=true - 避免模糊写法如
daily或weekly，它们无明确定义；优先用Mon..Fri 09:00:00或*-*-* 02:15:00 - 若用
OnBootSec=5min，需确认系统已进入 multi-user.target（即基本服务就绪），否则可能因依赖未满足而延迟甚至跳过
查日志时盯紧 service 单元，不是 timer 单元
timer 只负责“叫醒”，真正干活的是 service。失败日志全在 service 的 journal 里，查 timer 日志几乎没用。
- 正确命令：journalctl -u your-job.service -n 30 -o short-precise（-n 30 查最近30行，-o short-precise 显示毫秒级时间戳）
- 常见报错直接暴露根因：
Command not found→ PATH 缺失；No such file or directory→ 脚本路径错或没执行权限；Permission denied→ 用户/权限配置不对 - 若 service 日志为空，说明根本没被触发 → 回头检查 timer 状态和 OnCalendar 解析结果
