linux Command
systemd timer 定时任务常用命令
systemd timer 定时任务的常用管理命令，systemctl list-timers --all 看所有 timer 的 LAST/NEXT，systemctl status backup.timer/backup.service 分别查触发器与业务日志，systemd-analyze calendar 校验 OnCalendar 表达式，systemctl start 手动触发复现。
timer 排查先 list-timers 看 LAST/NEXT，再查同名 service 的日志；timer active 不代表任务执行成功。
Scenario
什么时候用这组命令
这组命令适合在处理“systemd timer 定时任务常用命令”时作为第一轮检查模板。使用时先替换占位符，再在目标机器或目标 namespace 中执行，避免在错误环境里得到误导结论。
Input
你需要先准备什么
- 先确定故障资源：CPU、内存、磁盘、网络、权限、文件句柄还是 systemd 生命周期。
- 区分当前状态和故障发生时状态，事故恢复后 free/top 可能已经看不出根因。
- 任何清理或 kill 操作前先记录 PID、命令行、日志和影响范围。
Risk Notes
执行风险
- 生产上不要在来源未确认时 rm -rf 大目录，应先确认目录用途和影响范围。
- kill 进程前先确认它属于哪个服务、是否会触发级联重启，优先使用 SIGTERM 而非 SIGKILL。
- 不要忽略 dmesg 中的 OOM Killer 记录，它往往是应用内存泄漏或配置不当的早期信号。
Commands
命令详解
命令 1: 执行 systemctl
用于补充“systemd timer 定时任务常用命令”的排查证据链。systemctl 的输出需要结合上下文其他命令交叉验证，不要单独依赖某一条结果下结论。
- 确认命令运行位置正确。
- 保留关键输出，方便和修复后对比。
- 如果输出为空或权限不足，切换到有权限用户后再判断。
systemctl list-timers --all命令 2: 执行 systemctl
用于确认服务当前运行状态、退出码和最近日志。重点看 Active 行和 Main PID。
- 确认命令运行位置正确。
- 保留关键输出，方便和修复后对比。
- 如果输出为空或权限不足，切换到有权限用户后再判断。
systemctl status backup.timer --no-pager命令 3: 执行 systemctl
用于确认服务当前运行状态、退出码和最近日志。重点看 Active 行和 Main PID。
- 确认命令运行位置正确。
- 保留关键输出，方便和修复后对比。
- 如果输出为空或权限不足，切换到有权限用户后再判断。
systemctl status backup.service --no-pager命令 4: 查看 systemd 日志
用于读取 systemd 或内核在故障时间附近记录的真实错误，比 status 摘要更完整。重点看时间、退出码、权限、路径和依赖失败。
- 确认命令运行位置正确。
- 保留关键输出，方便和修复后对比。
- 如果输出为空或权限不足，切换到有权限用户后再判断。
journalctl -u backup.service -n 100 --no-pager命令 5: 执行 systemd-analyze
用于补充“systemd timer 定时任务常用命令”的排查证据链。systemd-analyze 的输出需要结合上下文其他命令交叉验证，不要单独依赖某一条结果下结论。
- 确认命令运行位置正确。
- 保留关键输出，方便和修复后对比。
systemd-analyze calendar "daily"命令 6: 执行 sudo
用于补充“systemd timer 定时任务常用命令”的排查证据链。sudo 的输出需要结合上下文其他命令交叉验证，不要单独依赖某一条结果下结论。
- 确认命令运行位置正确。
- 保留关键输出，方便和修复后对比。
- 如果输出为空或权限不足，切换到有权限用户后再判断。
sudo systemctl start backup.serviceWorkflow
建议执行顺序
按顺序执行，不要跳过确认类命令
先用只读命令确认状态，再执行会改变状态的命令。timer 排查先 list-timers 看 LAST/NEXT，再查同名 service 的日志；timer active 不代表任务执行成功。
- 查看所有 timer 的触发计划。
- 检查目标 timer 是否 enabled/active。
- 验证 OnCalendar 写法是否符合预期。
- 手动 start 对应 service 复现任务。
- 查看 service 日志确认业务命令是否成功。
systemctl list-timers --all
systemctl status backup.timer --no-pager
systemctl status backup.service --no-pager把命令输出变成结论
命令本身不是结论。每次执行后要回答：目标是否存在、状态是否异常、异常是否能解释用户看到的现象。
- 记录关键字段，而不是整屏复制
- 把正常路径和异常路径输出对比
- 输出为空也要解释：是确实没有，还是权限/过滤条件不对
systemctl status backup.timer --no-pager
systemctl status backup.service --no-pager
journalctl -u backup.service -n 100 --no-pager执行前替换占位符并控制影响范围
包含 <service>、<pod>、<namespace>、<pid>、<container> 的命令必须先替换。涉及 reload、restart、KILL、vacuum、prune 的命令要确认影响范围。
- 优先在测试环境或只读模式验证
- 生产执行前保留回滚路径
- 把最终可用命令写入工单或 runbook
systemd-analyze calendar "daily"
sudo systemctl start backup.serviceVerification
怎么判断命令有效
- 命令已在正确机器、正确用户、正确 namespace 或正确仓库下执行。
- 输出能支撑明确判断：正常、异常、权限不足、目标不存在或需要下一跳排查。
- 对有副作用的命令，已确认执行窗口、影响范围和回滚方式。
Prevention
沉淀到日常流程
- 为关键服务配置日志轮转、资源限制和基础监控，避免等到用户报障才发现问题。
- 把 systemd unit、timer 和环境文件纳入版本管理，确保所有变更可追溯可回滚。
- 对清理动作保留可回滚路径，优先移动/截断/轮转，不盲删。
- 建立系统资源基线监控，一旦 CPU、内存、磁盘或文件句柄超过阈值即可自动告警。
常见问题
为什么 timer 没有日志？
timer 本身日志通常很少，真正的任务输出在对应 .service 单元里。
Long-tail SEO
你可能正在搜索这些报错
下面这些错误原文、场景词和中英文搜索词，都是排查同类问题时常见的入口。
- systemd timer 定时任务
- systemctl list-timers
- systemd timer 替代 crontab
- systemd timer 配置
- systemd 定时器命令
- systemd-timer 管理
Need More Help
这组命令还不够贴合你的场景？
把你的系统环境、目标操作和报错贴过来，我会优先补充更具体的命令模板。