定时任务的迁移

周五晚上迁完机器，周一早上发现周报没发出来，这类事故十有八九出在 crontab 上。定时任务平时看不见，迁移时最容易被漏掉，值得单独立一个环节。 一、导出旧机器的任务清单 root 和每个业务账号的定时任务要分开导出： ``` crontab -l -u root > root-cron.txt crontab -l -u www > www-cron.txt ls /etc/cron.d/ /etc/cron.daily/ ``` /etc/cron.d 和 /etc/cron.daily 里常藏着系统级脚本，只看 crontab -l 会漏。导出后逐条标注用途、运行账号和依赖，形成迁移清单。导出动作本身也写成脚本放进清单：老机器退租前最后再跑一次，确认退租前夕没有新增任务被漏掉。 二、在新机器上重建并补依赖 重建时最常见的问题是"命令行能跑、定时跑不了"，原因多半在环境变量：手工执行时有完整的 PATH，crontab 里只有 /usr/bin 等默认路径。两个办法：任务里写全路径，比如 /usr/local/bin/python3；或在任务文件开头补一行 PATH 声明。脚本里的相对路径一并改成绝对路径。每条任务重建后先手动触发一次，把缺的依赖库、配置文件补齐。系统自带任务也要比对：日志轮转、证书续期这类任务新环境装完服务会自动带一套，逐条核对执行频率和参数是否与旧机器一致。 三、核对时区 新机器时区要和旧机器一致，否则整点任务会整体偏移。`timedatectl` 看当前时区，不是 Asia/Shanghai 就执行 `timedatectl set-timezone Asia/Shanghai` 修正。有些脚本内部按 UTC 计算，迁完第一个整点任务对照一下实际执行时间，确认没有差出八小时。 四、验证与常见问题 全部重建后把每条任务的执行时间列成表，观察期里等它们各跑一轮。确认方式靠日志：脚本末尾加一行 `echo "$(date '+%F %T') done" >> /var/log/cron-job.log`，有没有按时跑过一目了然。跑没跑、跑成没成功，还可以查 /var/log/cron 里的调度记录，常见报错是权限不足和路径不存在，按报错行逐个修。 定时任务迁移的要点就三个：导全、补齐依赖、对准时区。观察期盯完第一轮执行，这项就算收尾了。