第03章：AI生成的crontab任务，会悄悄失败

“crontab 任务失败了，没有人知道——直到某天你发现日志没清、备份没做、报告没发。”

ℹ️ 版本说明：本章基于 Ubuntu 26.04 LTS、Bash 5.2、systemd 257+（推荐用 systemd timer 替代 crontab）。

3.1 AI默认会生成什么

你让 AI 帮你设置一个每天凌晨2点备份数据库的定时任务：

0 2 * * * /home/deploy/backup.sh

这个 crontab 配置会在大多数情况下工作，但它有一个根本性的问题：你不知道它有没有成功运行。

backup.sh 脚本报错了？crontab 可能发了一封邮件给 root，但没有人看
任务运行时间超过了24小时？下一次任务也开始了，两个任务同时运行
服务器在凌晨2点重启中？这次任务直接跳过，无法补跑
你改了 backup.sh 的路径？crontab 还是执行旧路径，静默失败

AI 给你的 crontab 是"能配置"的，但不是"生产就绪"的。

3.2 AI通常遗漏的4个坑

⚠️ 坑1：环境变量与交互式 shell 不同

crontab 运行的环境和你手动 SSH 进去的环境完全不同：

PATH 只有 /usr/bin:/bin，没有 /usr/local/bin、/home/deploy/.local/bin 等
没有加载 ~/.bashrc、~/.bash_profile
没有 conda activate、nvm use 等你在 shell 里手动执行的初始化

结果：你手动跑 /home/deploy/backup.sh 没问题，但 crontab 运行时 python3 找不到（因为 PATH 不含 virtualenv 路径），脚本静默失败。

⚠️ 坑2：任务失败没有告警

默认情况下，crontab 任务失败时：

如果系统配置了 sendmail，会给 root 发一封邮件
如果 sendmail 没配置（大多数现代服务器没有），错误消失在虚空里

你发现问题的方式是：数周后意识到"等等，那个备份脚本真的在跑吗？"

⚠️ 坑3：任务重叠运行

如果一个任务比下次触发时间还长，两个实例会同时运行：

* * * * * /usr/bin/python3 /home/deploy/process.py

如果 process.py 需要90秒，那1分钟后第二个实例就启动了，两个实例同时修改数据库，可能导致数据损坏。

⚠️ 坑4：时区混乱

AI 生成的 crontab 时间是服务器本地时区的时间。但：

云服务器默认时区通常是 UTC
你以为"0 2 * * *"是北京时间凌晨2点，实际是 UTC 凌晨2点 = 北京时间早上10点

如果你的服务器在上午10点做"维护窗口"，用户会很困惑。

3.3 更好的提示词

提示词 P01：用 systemd timer 替代 crontab（推荐）

使用时机：新的定时任务，特别是重要的业务任务

比默认多了什么：

失败自动重试
日志记录（journalctl 查看）
任务状态可查（systemctl status）
防止重叠运行

帮我用 systemd timer 实现一个每天凌晨2点（北京时间 CST）运行数据库备份的定时任务。

任务脚本：/home/deploy/backup.sh

要求：
1. 创建两个文件：
   - /etc/systemd/system/db-backup.service（定义任务）
   - /etc/systemd/system/db-backup.timer（定义触发时间）

2. service 文件要求：
   - 以 deploy 用户运行（不用 root）
   - 设置工作目录和完整的 PATH 环境变量
   - 失败时自动重试（最多3次，间隔5分钟）
   - 防止重叠运行（Type=oneshot）

3. timer 文件要求：
   - 北京时间 02:00（使用 Asia/Shanghai 时区）
   - 服务器重启后如果错过了触发时间，开机5分钟后补跑一次

4. 管理命令：
   - 启用和启动 timer 的命令
   - 查看 timer 状态和下次触发时间的命令
   - 查看上次运行日志的命令（journalctl）
   - 手动触发一次任务的命令（不等 timer）

基于 Ubuntu 26.04 LTS + systemd 257+。

提示词 P02：为 crontab 任务添加监控和告警

使用时机：已有的 crontab 任务，无法迁移到 systemd timer

比默认多了什么：

任务运行时间记录
失败 Webhook 告警
Heartbeat 监控（任务没有运行时告警）

我有以下 crontab 任务，帮我为它添加监控和告警：

0 2 * * * /home/deploy/backup.sh

要求：
1. 包装脚本（wrap.sh）：
   - 记录任务开始时间、结束时间、耗时
   - 捕获任务的退出码和 stderr 输出
   - 如果退出码非0，发送 Webhook 告警到飞书/钉钉（用 curl 发 POST 请求）
   - 告警内容包含：任务名、时间、错误输出的最后20行

2. Heartbeat 监控（"deadman's switch"）：
   - 任务成功运行后，向 Healthchecks.io 或自建 URL 发 HTTP GET 请求（心跳）
   - 如果超过 26 小时没有心跳，Healthchecks.io 会主动告警（邮件/Webhook）
   - 告诉我如何用 cURL 实现这个心跳，以及 Healthchecks.io 的免费账号配置步骤

3. 修改后的 crontab：
   - 将原任务改为调用 wrap.sh
   - 设置完整的 PATH 环境变量
   - 将 stderr 重定向到日志文件

基于 Ubuntu 26.04 LTS + Bash 5.2。

提示词 P03：排查 crontab 任务失败的完整指南

使用时机：crontab 任务"应该在跑"但不确定是否真的在运行

比默认多了什么：

系统化的排查步骤
模拟 crontab 环境

我的 crontab 任务手动运行没问题，但好像 crontab 没有自动运行。帮我排查问题。

任务：0 2 * * * /home/deploy/backup.sh

排查步骤（帮我一步步确认）：
1. 确认 cron 服务是否运行：systemctl status cron
2. 确认 crontab 是否被正确加载：查看 /var/log/syslog 中的 cron 日志
3. 确认权限：/home/deploy/backup.sh 是否有执行权限，用 deploy 用户是否能执行
4. 模拟 crontab 环境：
   - 展示如何用最接近 crontab 的环境手动运行脚本（空 PATH、无 shell 初始化）
   - 帮我找出"手动能跑，crontab 不能"的原因
5. 时区验证：crontab 使用的时区和我预期的时区是否一致

同时，给我一个"crontab 调试 checklist"，以后遇到类似问题可以复用。

基于 Ubuntu 26.04 LTS。

3.4 验收清单

检查项	验证方法	AI辅助
任务有失败告警	手动让任务失败，验证收到通知	让 AI 写 Webhook 告警包装
PATH 已设置	任务脚本开头有完整 PATH 或 env -i 测试	让 AI 在 crontab 里加 PATH=
时区已确认	`date` 命令确认服务器时区	让 AI 检查 /etc/timezone
防止重叠运行	systemd Type=oneshot 或 flock	让 AI 添加防重叠机制
有 Heartbeat 监控	每次成功运行后有心跳请求	让 AI 集成 healthchecks.io
任务日志可查	journalctl -u taskname 或日志文件	让 AI 添加日志记录

3.5 本章小结

如果你只记一件事：把重要的定时任务从 crontab 迁移到 systemd timer。systemctl status 一目了然，journalctl 有完整日志，失败重试、防重叠都内置了——这些 crontab 都需要额外实现。

定时任务可靠性的三个层次：

任务能运行：PATH 正确、权限正确、语法正确
任务失败有通知：不依赖 sendmail，用 Webhook 主动推告警
任务没运行也有通知：Heartbeat 监控——比失败告警更重要，因为你不知道你不知道什么

→ 第4章：AI帮我管用户权限，但最小权限原则在哪？