service 文件必须放对位置才能被 systemd 加载
systemd 只扫描两个目录：/etc/systemd/system/（用户自定义服务）和 /usr/lib/systemd/system/（发行版自带服务）。把 backup-script.service 丢进 /etc/init.d/ 或自己家目录下，systemctl daemon-reload 根本不会理它。
务必把自定义服务文件放在 /etc/systemd/system/，且文件名必须以 .service 结尾。权限建议设为 644，属主属组为 root:root；权限太松（比如 777）会导致 systemd 拒绝加载。
- 错误示例：
/home/user/backup.service、/etc/init.d/backup - 正确路径：
/etc/systemd/system/backup-script.service - 改完文件后，必须运行
systemctl daemon-reload，否则enable或start仍用旧配置
定时执行必须配 timer + service 两套文件
想“每天凌晨2点跑一次脚本”，不能只写 Type=simple 或 Type=oneshot 的 service 就完事——那只是定义怎么跑，不是定义什么时候跑。真正做周期性任务，必须成对创建：xxx.service + xxx.timer，名字前缀一致，后缀不同。
.timer 文件里关键要填 Unit=xxx.service，否则 timer 触发时根本不知道该启哪个 service。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
-
OnCalendar=*-*-* 02:00:00表示每天 2:00:00 执行 -
Persistent=true很重要：机器若在 2:00 关机，开机后会补跑；不加就真错过了 -
WantedBy=timers.target是启用 timer 的必要项，不是multi-user.target
脚本在 systemd 下失败，大概率是环境不对
终端里能跑的脚本，放进 systemd 就报 Failed with result 'exit-code'，90% 是因为环境差异：
- PATH 极简，默认只有
/usr/bin:/bin，脚本里写python3或jq会找不到——得用绝对路径，比如/usr/bin/python3 - 当前工作目录默认是
/，脚本里用./config.json就读不到——加WorkingDirectory=/opt/scripts -
$HOME在User=root时是/root，但 systemd 不自动继承该变量——显式写Environment="HOME=/root" -
ExecStart=/path/to/script.sh > /tmp/log 2>&1这种重定向无效，systemd 不解析 shell 语法；要用StandardOutput=append:/tmp/log等参数
验证和调试别只看 systemctl status xxx.timer
systemctl status 只显示 timer 单元本身是否 active，看不出 service 是否真执行了。真正要看执行结果，得查日志和触发记录：
- 查 timer 下次触发时间：
systemctl list-timers --all - 查 service 实际输出：
journalctl -u backup-script.service -n 20 - 查 timer 触发历史：
journalctl -u backup-script.timer - 如果 service 启动后立刻退出却没报错，可能是
Type=oneshot但漏写了RemainAfterExit=yes（仅当需要标记“已执行”状态时才加）
最常被忽略的是：timer 和 service 名字不一致、daemon-reload 漏执行、Persistent 没开导致错过就永远错过——这三点占实际排障的七成以上。
