at任务不触发主因是系统物理时钟倒退导致atd调度逻辑失效，需检查timedatectl状态、系统日志时间跳变、hwclock与date差异，并重启atd重建调度；根本解法是禁用手动调时、启用chronyd平滑同步、设rtc为utc。
at 任务不触发，表面看是“提交成功却没执行”，但若系统物理时钟发生倒退（比如手动调早后又调回、NTP强制校正、虚拟机挂起恢复等），会导致 atd 守护进程内部调度逻辑失效——它依赖单调递增的系统时间判断任务是否到期，时间跳变会令已排队任务被跳过或永久挂起。
确认物理时钟是否发生过倒退
检查系统时间变化痕迹：
- 运行 timedatectl status，重点关注 System clock synchronized 是否为 yes，以及 NTP service 状态是否 active
- 查看系统日志中时间相关告警：journalctl -u systemd-timesyncd --since "2 days ago" | grep -i "time.*jump\|back\|step" 或 dmesg | grep -i "time.*adj"
- 比对硬件时钟与系统时间差异：hwclock --show 和 date 输出是否相差异常（如数小时以上且方向反复）
检查 atd 是否因时间跳变进入异常状态
atd 不会自动重载或重排任务队列，一旦系统时间向后大幅跳变（如从 15:00 回拨到 14:00），它可能仍认为“刚过某个时间点”，错过本该执行的任务；若向前跳变（如从 14:00 跳到 15:30），则尚未到达的未来任务可能被判定为“已过期”而丢弃。
- 用 systemctl status atd 查看服务是否仍在运行，有无 “Failed to schedule job” 类报错
- 执行 atq：若队列为空但你确定刚提交过任务，极可能是时间倒退导致任务被 silently 丢弃
- 重启 atd 强制重建调度上下文：sudo systemctl restart atd（注意：重启后原队列中未执行任务全部丢失）
验证任务是否因时间异常被标记为“过期”
atd 内部使用系统 uptime 或单调时钟辅助判断，但主要依赖 wall-clock 时间。若提交任务后系统时间被人工回拨，该任务的触发时间戳可能变成“过去式”，atd 启动扫描时直接跳过。
- 用 sudo at -c
查看任务详情（需 root 权限），检查输出中 Execution time: 是否明显早于当前 date 输出 - 若发现 Execution time 是昨天或更早，说明任务已被视为过期，不会执行
- 此时只能重新提交：echo 'your-command' | at
预防时间倒退影响 at 任务的核心措施
根本解法不是修 at，而是稳住系统时间源：
- 禁用任何手动 date -s 操作，一律改用 chronyd 或 systemd-timesyncd 做平滑同步
- 确保 timedatectl set-ntp true 已启用，且 NTP 服务器可用（chronyc tracking 查 offset 应在 ±0.1s 内）
- 虚拟机用户需开启 host 时间同步支持（如 VMware Tools 中的 “Synchronize guest time with host”）
- 硬件时钟设为 UTC：sudo timedatectl set-local-rtc false，避免双系统切换引发冲突
