at 任务不执行的 atd 服务状态与 /var/spool/at 权限检查

at命令不执行的首要原因是atd服务未运行，需用systemctl status atd确认；其次检查/var/spool/at权限（属主daemon、755）、绝对路径与显式解释器、日志配置（-l参数）及环境变量缺失问题。

at 命令不执行：先确认 atd 服务是否真在运行

很多人输完 at now + 1 minute 回车、输入命令、Ctrl+D，结果等半天没反应——第一反应是“配置错了”，其实大概率是 atd 根本没跑。systemctl status atd 看到 inactive (dead) 或 failed 就别往下查权限了。

常见错误现象：at 提交成功但无日志、/var/log/syslog 里完全搜不到 atd 字样、ps aux | grep atd 返回空。

• atd 默认不随系统启动（尤其 ubuntu/debian 新装机、centos 8+ 后 systemd 默认禁用）
• 即使手动 sudo atd 启动，若没加 -f 参数，它会前台运行；关掉终端就退出
• 某些发行版（如 Alpine）压根不装 atd，只装 at 客户端，得先 apk add at

/var/spool/at 权限被改过？直接看 ls -ld /var/spool/at

atd 只读 /var/spool/at，且严格检查属主和权限。不是“只要能写就行”，而是必须满足两个硬条件：目录属主是 daemon（或 at 用户，视系统而定），权限为 755 或更严格（不能是 777）。

常见错误现象：at 提交时无报错，但任务永远卡在 queued 状态；atq 能看到任务，at -c <jobid></jobid> 却提示 No such file or Directory。

• CentOS/RHEL 系统通常要求属主 daemon:daemon，权限 drwxr-xr-x
• Debian/Ubuntu 多用 daemon:daemon 或 at:at，但权限若变成 775 或含 sticky bit，atd 会静默拒绝加载队列
• 不要用 chmod 755 /var/spool/at 一刀切——先 ls -ld /var/spool/at 看原样，再比对同环境正常机器的输出

任务脚本里用了相对路径或未声明 shell？at 执行时根本找不到东西

at 启动子进程时工作目录是 /，环境变量极简（几乎只有 PATH=/usr/bin:/bin），不会加载 ~/.bashrc。你写的 ./backup.sh 或 python3 ~/script.py 在 at 里全失效。

使用场景：定时压缩某个目录、调用 Python 脚本发通知、执行带 source 的环境初始化逻辑。

• 所有路径必须绝对：用 /home/user/script.py，别用 ~/script.py 或 ./script.py
• 显式指定解释器：写 /usr/bin/python3 /path/to/script.py，别只写 python3 script.py
• 需要环境变量？要么在 at 输入时用 export VAR=value 开头，要么把整个命令包进 bash -c '...'
• 测试方法：手动模拟 atd 行为——sudo -u daemon bash -c 'cd / && /your/absolute/command'

日志没开或位置不对，atd 出错只能靠猜

atd 默认不写详细日志，出问题时 systemctl status atd 只显示一行“Started ATD Daemon”，实际失败原因藏在黑盒里。

性能 / 兼容性影响：加日志参数不耗资源，但能省下 80% 的排查时间；某些老版本 atd（如 RHEL 6 自带）不支持 -l，得换包或升级。

• 启动时加 -l /var/log/atd.log：修改 /etc/systemd/system/multi-user.target.wants/atd.service，在 ExecStart= 行末尾追加
• 确保 /var/log/atd.log 属主是 daemon，权限 644，否则 atd 启动失败且不报错
• 日志里最常出现的是 Can't open /var/spool/at for reading（权限错）、Job XXX removed: No such file（脚本路径错）

真正麻烦的不是权限或服务开关，是 atd 静默失败——它不报错、不写日志、不提醒，只让任务躺在队列里慢慢发霉。