at任务不执行或“消失”主因是调度失败、环境缺失或系统限制，需从队列状态（atq）、atd服务（systemctl status atd）、执行环境（绝对路径、显式变量、权限）及系统限制（at.allow/deny、发行版默认策略）四方面排查。
at 任务在安排后不执行或“消失”，通常不是任务被删除，而是调度失败、环境缺失或系统限制导致未触发。关键要从队列状态、执行环境、系统配置三方面快速定位。
确认 at 队列中任务是否真实存在
使用 atq 查看当前待执行的 at 任务列表（含任务号、时间、队列名）：
- 若任务不在输出中，说明已执行完毕、被取消，或提交时因语法/权限问题根本未入队
- 若任务存在但时间已过却未执行，大概率是 atd 服务异常或任务运行时环境不满足
- 注意：不同用户需用 atq -u 用户名 查看，root 可查全部；普通用户只能看到自己的任务
检查 atd 服务状态与日志
at 依赖后台服务 atd 轮询调度，服务停止或崩溃会导致所有任务挂起：
- 运行 systemctl status atd（或 service atd status）确认服务处于 active (running)
- 若服务未运行，启动它：sudo systemctl start atd，并设为开机自启：sudo systemctl enable atd
- 查看 atd 日志：sudo journalctl -u atd -n 50 --no-pager，重点关注 “error”、“failed”、“cannot execute” 类提示
验证任务执行时的环境与权限
at 任务默认以提交时的用户身份、在最小化 shell 环境（通常是 /bin/sh）中运行，极易因路径、变量、权限失败而静默退出：
- 避免使用相对路径——脚本、文件必须用绝对路径（如 /home/user/script.sh 而非 ./script.sh）
- 不要依赖当前 shell 的环境变量（如 PATH、HOME），应在 at 命令中显式设置，例如：
echo '/usr/bin/python3 /opt/myscript.py' | at now + 1 minute - 确保目标用户对脚本和所有依赖文件有读取+执行权限，且 atd 服务未被 SELinux/AppArmor 限制（常见于 CentOS/RHEL 或 Ubuntu Server）
排查系统级限制与特殊场景
某些发行版或安全策略会主动禁用或限制 at 功能：
- 检查 /etc/at.allow 和 /etc/at.deny：若存在 at.allow，只有其中列出的用户可用 at；若不存在 at.allow 但存在 at.deny，被列用户禁用；两者都无则默认开放（但部分新版系统默认拒绝）
- Ubuntu 22.04+ 默认禁用 atd，需手动启用；macOS 不原生支持 at（需安装 brew install at 或改用 launchd）
- 任务时间设为过去时刻会被 at 忽略（不报错也不入队），建议用 date -d "now + 2 minutes" 校验时间表达式是否合理
