记录一下那天晚上的排查过程。用 @reboot 让一个采集脚本开机自启，机器维护重启后脚本没起来，手动执行 crond 重启才不会补跑，日志里一条记录都没有。
刚开始盯着「root 的 crontab 和 /etc/cron.d 里写法不同，账号字段漏了」，折腾了半个多小时，排掉了。
把日志和配置对完，能解释这个现象的基本就这几处。@reboot 只在 crond 启动时触发一次，触发时依赖的目录还没挂上。还有一种是@reboot 任务执行时网络尚未就绪，脚本第一行就失败退出。
不容易想到的是，任务输出没有重定向，错误信息进了邮件没人看。
上来先确认 crontab 里的写法
crontab -l | grep -n reboot然后看 crond 启动日志和任务输出
journalctl -u crond -b | grep -i reboot接着改成等网络就绪后再执行
crontab -l | sed 's/@reboot/sleep 30 \&\&/'末了重启验证任务确实跑过
systemctl restart crond && grep -i cron /var/log/messages | tail -5别只看报错消失，验证要多做一步。重启后两分钟内采集脚本开始运行，日志里有本次启动的时间戳，cron 日志里能看到该任务的执行记录。
@reboot 不适合做依赖较多的启动任务，系统服务用 systemd 的 After=network-online.target 更可靠；脚本输出一定要重定向到文件。拖得越久，排查成本越高，因为现场状态会被后续操作覆盖。