这个坑值得记一笔。CentOS 7 上把任务写成 /etc/cron.d/backup.conf，格式看着没问题，到点不执行，/var/log/cron 里连文件名都没出现过，换成 crontab -e 写就正常。
这类报错背后常见的原因有几处，逐个排除就行。/etc/cron.d 下的文件名只认字母数字下划线和短横，带点会被直接跳过；cron.d 的格式比 crontab 多一列执行用户，漏了这列整行解析失败；文件最后一行没有换行符，末尾那条规则不被解析。
动手时先看目录里的文件名与权限
ls -l /etc/cron.d/然后改成合法名字
mv /etc/cron.d/backup.conf /etc/cron.d/backup补上用户列与结尾换行
printf '0 2 * * * root /opt/backup.sh >/dev/null 2>&1\n' > /etc/cron.d/backup剩下的就是重启 crond 并观察日志
systemctl restart crond && tail -f /var/log/cron报错是间歇性的，我蹲守了半小时才抓到一次完整现场。
别只看报错消失，验证要多做一步。/var/log/cron 里出现 CMD (/opt/backup.sh)，任务在整点后一分钟内产出文件，脚本日志里有当天时间戳。
容易忽略的是，cron.d 的六列格式和 crontab 的五列差一列，复制粘贴最容易出错；文件名带点这个坑没有任何报错，只能靠日志里有没有记录判断。监控比日志更早给出信号，事后回看经常能提前半小时发现异常。