能，但非无条件替代：systemd timer在依赖控制、日志集成上更强，cron对简单周期任务更直接；需配对.timer与.service文件，persistent=true可补运行错失任务，调试须查journal并确保服务名一致、type=oneshot、权限正确。
systemd timer 能不能完全替代 cron
能，但不是无条件替换。systemd timer 在精确控制启动条件、依赖服务状态、日志集成上明显更强；但对简单周期任务（比如每天凌晨 2:17 清理临时文件），cron 的表达更直接，且兼容性零负担。
真正卡住人的不是“能不能”，而是“要不要改”——如果你的 cron 任务没出过问题、没人抱怨延迟或依赖失败，硬切过去反而增加维护成本。
- systemd timer 启动前会检查
WantedBy=和After=，cron 不管这些 - timer 默认受
StartLimitIntervalSec限制，频繁失败的任务可能被暂停，cron 会照常跑 -
systemctl list-timers --all可查所有 timer 状态，但看不到「上次执行是否成功」，得配合journalctl -u xxx.service
写一个 daily backup.timer 的最小完整配置
别只写 .timer 文件，必须配对一个同名 .service —— systemd timer 本质是触发 service，不是直接执行命令。
假设备份脚本在 /usr/local/bin/backup.sh，权限已设为可执行：
[Unit] Description=Daily backup After=network.target <p>[Timer] OnCalendar=<em>-</em>-* 02:17:00 Persistent=true</p><p>[Install] WantedBy=timers.target
对应 backup.service：
[Unit] Description=Run backup script After=network.target <p>[Service] Type=oneshot ExecStart=/usr/local/bin/backup.sh User=backupuser</p>
-
OnCalendar支持hourly、daily，但建议用具体时间格式，避免时区歧义 -
Persistent=true表示机器关机期间错过的时间点，开机后补运行；设为 false 则跳过 - 不要在 .timer 里写
ExecStart，它不认这个字段
timer 触发后 service 却没运行？常见原因
最常踩的坑是：timer 显示 active，但 service 根本没起来，journalctl -u backup.service 一片空白。
- timer 和 service 文件名不一致（比如
backup.timer对应backup.service，不能是backup-run.service） - service 文件里漏了
[Service]段，或Type=写成simple（应该用oneshot） - 用户权限问题：
User=指定的用户不存在，或 home 目录不可读（尤其涉及 ssh key 或环境变量时） - timer 已启用但未启动：
systemctl enable backup.timer≠systemctl start backup.timer
cron 和 systemd timer 日志与调试差异
cron 把 stdout/stderr 直接邮件给用户（如果装了 mailutils），systemd 全部进 journal，不显式重定向就看不到输出。
- 调试阶段务必在 service 里加
StandardOutput=journal+console和StandardError=journal+console - 想保留历史输出？加
RuntimeMaxSec=300防止 long-running service 卡住 timer 下次触发 -
systemctl status backup.timer只显示 timer 状态，systemctl status backup.service才看上次执行详情 - journal 日志默认只存内存或 1–3 天，如需长期归档，得配
/etc/systemd/journald.conf中的Storage=persistent
真正麻烦的是混合场景：旧系统里 cron 和 timer 并存，同一任务被两个机制调起，又没做互斥锁。这种问题不会报错，只会让你某天发现备份文件多了一倍。
