报错是这么冒出来的。CentOS 7 上用 echo ‘/opt/job.sh’ | at 02:00 排了一次任务，atq 能看到编号，第二天什么都没发生，/var/log/cron 里连一条 atd 的记录都没有。
这类报错背后常见的原因有几处，逐个排除就行。atd 服务根本没启动，最小化安装默认不装 at 的守护进程。少数情况下是/var/spool/at 的属主或 SELinux 上下文不对，atd 读到任务也不执行。
不容易想到的是，任务里用的是相对路径，atd 执行时的工作目录是用户家目录。
第一件事是看服务与自启状态
systemctl status atd; systemctl is-enabled atd然后启动并设开机自启
systemctl enable --now atd接着用一分钟后的任务验证链路
echo 'echo ok > /tmp/at_test' | at now + 1 minute末了检查 spool 目录属主
ls -ld /var/spool/at && restorecon -Rv /var/spool/at同样的操作我在测试机上先走了一遍，线上只做验证过的部分。
怎么算真的好了，看的是同一批现象。/tmp/at_test 里出现 ok，/var/log/cron 里有 atd 执行该 job 的记录，atq 列表里这条任务被移除。
at 适合一次性任务但要依赖 atd，容器和精简系统里经常没有；脚本里一律写绝对路径，atd 不会继承你登录时的 shell 环境。这类问题最好一次改到位，反复小改反而容易把原因搅混。