crontab 定时任务不执行的常见原因：环境变量、百分号转义与重叠运行

背景

在云服务器上用 crontab 跑备份、清理、同步脚本时，经常遇到“手动执行正常，定时却没跑”或“跑了但结果不对”。本文整理几类最常见的原因和对应的写法。

一、先确认任务有没有被触发

# 查看当前用户的任务
crontab -l

# 查看 cron 服务状态
systemctl status cron || systemctl status crond

# 查看触发记录（Debian/Ubuntu 在 syslog，CentOS 系在 /var/log/cron）
grep CRON /var/log/syslog | tail

日志里有触发记录但没有效果，说明问题在命令本身；完全没有记录，则检查服务是否运行、语法是否正确、文件权限是否合规。

二、环境变量与 PATH 不同

cron 以非交互、非登录的方式执行，环境非常精简，PATH 通常只有 /usr/bin:/bin，不会加载 ~/.bashrc 或 /etc/profile。手动执行能找到的 node、python3、docker，在 cron 里可能找不到。

解决办法：

1. 命令中使用绝对路径，可用 which 命令 查出。
2. 在 crontab 顶部显式设置：

SHELL=/bin/bash
PATH=/usr/local/bin:/usr/bin:/bin

1. 脚本里依赖的环境变量，在脚本开头显式 export 或 source 配置文件。

三、百分号需要转义

在 crontab 行中，未转义的 % 会被当成换行符，% 之后的内容会作为标准输入传给命令。这会让 date +%F 之类的写法出问题：

# 错误：% 被截断
0 2 * * * tar czf /backup/data-$(date +%F).tar.gz /data

# 正确：转义百分号
0 2 * * * tar czf /backup/data-$(date +\%F).tar.gz /data

更省事的办法是把逻辑放进脚本，crontab 里只写脚本路径。

四、工作目录和相对路径

cron 任务默认工作目录是用户家目录，脚本里的相对路径会指向错误位置。在脚本开头 cd 到固定目录，或全部使用绝对路径。

五、一定要保留输出

默认情况下 cron 会尝试把输出发邮件，服务器未配置邮件时输出就丢了。建议重定向到日志：

*/5 * * * * /opt/job/sync.sh >> /var/log/sync.log 2>&1

2>&1 要写在重定向之后，否则错误输出不会进入文件。

六、避免任务重叠运行

上一次还没跑完，下一次又启动，容易造成数据重复处理或资源耗尽。可以用 flock 加非阻塞锁：

*/5 * * * * flock -n /var/lock/sync.lock /opt/job/sync.sh >> /var/log/sync.log 2>&1

-n 表示拿不到锁就直接退出。脚本异常退出时锁会随进程结束自动释放，比手写 pid 文件可靠。

七、时区与 day-of-month/day-of-week 的规则

• cron 使用系统时区，云服务器默认可能是 UTC 或北京时间，用 timedatectl 确认，不要想当然。
• 当“日”和“星期”两个字段都不是 * 时，满足任意一个就会触发，而不是同时满足。比如 0 3 1 * 1 表示每月 1 号和每个周一都会运行。

八、排查清单

1. crontab -l 与日志确认有触发。
2. 命令和脚本使用绝对路径，PATH 已设置。
3. % 已转义，或逻辑已移入脚本。
4. 输出已重定向到日志。
5. 长任务用 flock 防重叠。
6. 确认系统时区。