at 任务的输出去哪了
at 任务的标准输出与错误默认通过邮件发给任务属主，加 -m 时即使没有输出也会发；系统层面由 atd 记录任务的启动与执行痕迹。所以排查「任务为什么没有结果」要三处一起看：邮件、atd 日志、以及任务自身的重定向。
基本信息
| 输出去向 | 邮件（默认）、atd 日志、任务内的重定向 |
|---|---|
| 日志位置 | 系统日志或 journalctl -u atd（视发行版） |
| 稳妥做法 | 任务内显式重定向到日志文件 |
| 前置条件 | 邮件通知依赖本机有可用的 MTA |
典型使用场景
- 确认某个一次性任务是否真的执行过
- 任务没有输出，怀疑执行失败
- 把输出统一落到固定日志文件便于归档
- 排查邮件未送达造成的信息丢失
- 为一次性任务留下可审计的执行痕迹
- 把任务执行时间与实际业务变化对齐
查执行痕迹
查执行痕迹
sudo grep atd /var/log/syslog | tail -n 10 # Debian 系系统日志
sudo journalctl -u atd --since today --no-pager | tail -n 20
mail -u $USER 2>/dev/null | head # 本机 MTA 存在时查看邮件
journalctl -u atd -n 50 | grep -i 'cmd' # 找执行记录
# 更稳妥的做法：任务内自带重定向
exec >>/var/log/maint.log 2>&1
date -Is && /opt/scripts/maintenance.sh三种去向
| 去向 | 内容 | 排查方式 |
|---|---|---|
| 邮件 | 标准输出与错误 | 查看本机邮箱或 MTA 日志 |
| atd 日志 | 任务调度与启动记录 | journalctl -u atd 或系统日志 |
| 任务重定向 | 脚本自身写出的日志 | 直接查看目标日志文件 |
| 退出状态 | 通过邮件或脚本内记录 | 脚本内显式记录退出码 |
| 无 MTA 场景 | 输出可能静默丢失 | 必须改为任务内重定向 |
与 cron 一样，默认的邮件通知依赖本机有可用 MTA；生产环境应统一改成任务内重定向到日志文件，不要把结果押在邮件链路上。
没有 MTA 时 at 任务的输出可能静默丢失，任务看起来执行成功却没有任何结果可查，排查时容易误判成任务根本没有运行。
at 任务在机器关机期间不会补跑：错过的时间点不会自动补上，需要重新提交，这一点与 anacron 的补跑机制正好相反。