Linux如何使用at命令定时运行任务

P粉602998670

发布时间：2025-09-07 08:08:02

578人浏览过

来源于php中文网

原创

at命令用于在指定时间一次性执行任务，适合非周期性任务。使用时先输入时间如“at 15:30”，再输入命令并按Ctrl+D结束，系统返回任务编号。支持多种时间格式，如HH:MM、now + N minutes、关键词tomorrow等。与cron不同，at处理一次性任务，cron用于周期性任务。通过atq查看待执行任务，atrm加任务编号可删除任务。默认输出通过邮件发送，建议重定向输出到文件以便调试。常见问题包括环境变量缺失、工作目录不明确、权限限制及atd服务重启影响任务执行。解决方法包括使用绝对路径、显式设置环境变量、cd到目标目录、检查/etc/at.allow和/etc/at.deny权限配置，并做好日志记录和错误处理以确保任务可靠运行。

linux如何使用at命令定时运行任务

at

命令在 Linux 中用于安排一次性任务在未来的特定时间运行。它非常适合那些不需要周期性重复，但又必须在特定时刻执行的脚本或命令，提供了一种简洁而强大的任务调度方式。

在 Linux 中使用

at

命令定时运行任务，基本流程是先指定任务执行的时间，然后输入要执行的命令，最后通过

Ctrl+D

结束输入。

比如，我想在今天下午3点半发送一个消息到

/tmp/message.txt

文件，我可以这样做：

at 15:30
# 然后，在 `at>` 提示符下输入命令：
at> echo "这是一条计划在下午3点半执行的消息。" > /tmp/message.txt
at>  # 按 Ctrl+D 键

系统会返回一个任务编号，例如

job 1 at 2023-10-27 15:30

。这个编号是管理任务的关键。

at

命令的时间格式非常灵活，可以接受多种表达方式：

绝对时间：
```
HH:MM
```
(例如
```
14:30
```
)，
```
HH:MM AM/PM
```
(例如
```
3pm
```
)。

相对时间：

now + N units

(例如

now + 10 minutes

now + 1 hour

now + 2 days

now + 1 week

)。

特定日期和时间：
```
HH:MM MMDDYY
```
(例如
```
10:00 122523
```
表示2023年12月25日10点)，或者
```
HH:MM MM/DD/YY
```
。
关键词：
```
midnight
```
,
```
noon
```
,
```
teatime
```
(通常是下午4点)，
```
tomorrow
```
。

例如，我想在明天早上8点执行一个备份脚本：

at 8am tomorrow
at> /usr/local/bin/backup_script.sh
at>

at命令与cron命令有什么区别？我应该选择哪个？

这是一个非常经典的问题，很多人在需要定时任务时，第一反应往往是

cron

。但实际上，

at

和

cron

虽然都用于任务调度，它们的设计哲学和适用场景却大相径庭。

说白了，

at

是为“一次性”任务而生，而

cron

则专注于“周期性”重复任务。

at

命令的优势在于其简单直接。你只需要告诉它“在某个时间点执行这个”，然后输入命令，就完事了。它不需要你去编辑什么配置文件，也不用担心任务执行完后留下冗余的配置。比如，我可能需要在一个系统维护窗口之后，执行一个重启服务的命令，但这个操作只做一次。或者，某个客户要求在下周二上午10点发送一份报告，这个任务也是单次的。这时候，

at

就显得异常优雅和高效。

而

cron

呢，它通过

crontab

文件来管理任务，你需要指定分钟、小时、日期、月份、星期几等非常详细的执行周期。它非常适合那些需要每天、每周、每月，或者每隔几分钟就重复执行的任务，比如每日数据同步、日志清理、系统监控脚本等。如果你想每天凌晨3点备份数据库，那毫无疑问，

cron

是你的不二之选。

我的个人经验是，很多人在面对一次性任务时，也会习惯性地去修改

crontab

，然后等任务执行完再手动删除那一行配置。这不仅增加了操作步骤，也容易忘记清理，导致

crontab

文件变得混乱。所以，当你明确任务只需要执行一次时，别犹豫，

at

命令通常是更简洁、更正确的选择。它让你的任务调度意图更加清晰。

如何查看和管理我提交的at任务？以及如何处理at任务的输出？

管理

at

任务主要包括查看当前排队的任务和删除不需要的任务。同时，理解

at

任务的输出行为对于调试和确保任务成功至关重要。

查看和管理任务： 要查看你当前已经提交但尚未执行的

at

任务列表，可以使用

atq

命令，或者

at -l

。

atq
# 或者
at -l

这两个命令会列出所有待执行的

at

任务，包括任务的编号（job number）、执行日期和时间，以及任务所属的队列（通常是

队列）。任务编号是唯一的，也是你后续管理任务的关键。

如果你需要取消一个已经提交但尚未执行的

at

任务，可以使用

atrm

命令，或者

at -d

，后面跟上任务的编号。

JTBC网站内容管理系统5.0.3.1

JTBC CMS(5.0) 是一款基于PHP和MySQL的内容管理系统原生全栈开发框架，开源协议为AGPLv3，没有任何附加条款。系统可以通过命令行一键安装，源码方面不基于任何第三方框架，不使用任何脚手架，仅依赖一些常见的第三方类库如图表组件等，您只需要了解最基本的前端知识就能很敏捷的进行二次开发，同时我们对于常见的前端功能做了Web Component方式的封装，即便是您仅了解HTML/CSS也

下载

atrm [job_number]
# 例如，要删除任务编号为 1 的任务：
atrm 1

执行

atrm

后，该任务就会从队列中移除，不再会在预定时间执行。

处理at任务的输出： 这是一个非常重要的点，也是新手容易忽略的地方。默认情况下，

at

命令会将其执行的命令的标准输出（stdout）和标准错误（stderr）通过电子邮件发送给提交任务的用户。如果你的系统配置了邮件服务，你可能会在任务执行后收到一封邮件，里面包含了任务的输出内容。

然而，在很多服务器环境中，邮件服务可能没有配置，或者你根本不希望收到大量的邮件通知。更常见的情况是，你希望任务的输出能够被记录到特定的日志文件中，以便于后续审计和调试。

为了避免默认的邮件行为，并更好地控制输出，你需要在提交

at

任务时，显式地将命令的输出重定向到文件。

at now + 5 minutes
at> /path/to/my_script.sh > /var/log/my_at_job.log 2>&1
at>

这里的

> /var/log/my_at_job.log

将标准输出重定向到日志文件，而

2>&1

则表示将标准错误也重定向到标准输出指向的同一个文件。这样，无论任务成功还是失败，所有的输出信息都会被写入

/var/log/my_at_job.log

，方便你检查。

我曾经遇到过一些情况，任务在

at

中执行失败，但因为没有重定向输出，也没有邮件通知，导致问题被默默地掩盖了。直到很久之后才发现任务根本没有正常工作。所以，养成重定向输出的习惯，对于任何非交互式的脚本执行都是一个好习惯。

at命令有哪些常见的陷阱或权限问题？如何确保at任务安全可靠地执行？

at

命令虽然方便，但在实际使用中，确实存在一些常见的陷阱和权限问题，如果处理不当，可能导致任务执行失败或出现安全隐患。

1. 环境变量问题： 这是

at

任务最常见的“坑”。

at

任务执行时，通常会在一个非常精简的环境下运行，这意味着很多你在交互式 shell 中习惯的环境变量（比如

PATH

）可能并不存在或者值不同。你的脚本或命令可能因此找不到依赖的可执行文件，从而执行失败。

解决方案：

使用命令的绝对路径： 永远不要假设
```
PATH
```
变量是完整的。例如，不要只写
```
python myscript.py
```
，而应该写
```
/usr/bin/python /home/user/myscript.py
```
。

在任务中设置必要的环境变量： 如果你的脚本依赖于特定的环境变量，可以在

at

任务中显式地设置它们。

at now + 10 minutes
at> export MY_VAR="some_value"
at> PATH=/usr/local/bin:/usr/bin:/bin:/home/user/bin; /home/user/my_script.sh
at>

source
配置文件：如果脚本需要加载用户特定的环境（比如
```
.bashrc
```
或
```
.profile
```
），可以在任务中
```
source
```
这些文件，但这需要谨慎，因为它可能会引入一些不必要的复杂性。

2. 工作目录问题：

at

任务默认在提交任务时的当前工作目录执行。如果你的脚本需要访问相对路径的文件，或者需要在特定的目录下执行，你必须确保任务在正确的目录中启动，或者在脚本中显式地

cd

到目标目录。

解决方案：

在

at

任务中先

cd

到目标目录：

at 10:00 tomorrow
at> cd /path/to/my/project
at> ./run_task.sh
at>

在脚本中使用绝对路径：这是最稳妥的方式，避免任何关于工作目录的假设。

3. 权限问题（

at.allow

和
at.deny
）：并非所有用户都可以使用

at

命令。系统管理员可以通过

/etc/at.allow

和

/etc/at.deny

文件来控制哪些用户有权使用

at

。

如果
```
/etc/at.allow
```
存在，只有其中列出的用户才能使用
```
at
```
。
如果
```
/etc/at.allow
```
不存在，但
```
/etc/at.deny
```
存在，那么所有用户都可以使用
```
at
```
，除了在
```
/etc/at.deny
```
中列出的用户。
如果两个文件都不存在，通常只有
```
root
```
用户可以使用
```
at
```
，或者所有用户都可以（这取决于具体的 Linux 发行版配置）。

解决方案：

如果你无法使用
```
at
```
命令，首先检查这两个文件，并联系系统管理员。

4. 任务持久性问题：

at

任务通常由

atd

服务管理。在大多数现代 Linux 系统中，

atd

服务在系统重启后会尝试重新加载并执行那些在重启前尚未执行的

at

任务。但这不是100%保证的，尤其是在系统非正常关机的情况下。对于那些绝对不能丢失、必须在特定时间执行的任务，

at

的可靠性可能不如

cron

或

systemd timer

。

解决方案：

对于关键的一次性任务，可以考虑在脚本中加入幂等性检查，确保即使任务重复执行也不会造成副作用。
如果任务对系统重启非常敏感，且必须在特定时间执行，可以考虑更高级的调度器，或者在系统启动脚本中加入检查机制。

5. 调试困难： 由于

at

任务是非交互式执行的，如果任务失败，调试起来可能比手动执行命令更复杂。

解决方案：

详细的日志记录： 这是最重要的。确保你的脚本有详尽的日志输出，并且如前所述，将所有输出重定向到文件。
错误处理： 在脚本中加入适当的错误检查和处理机制，例如使用
```
set -e
```
在脚本中遇到错误时立即退出，或者使用
```
trap
```
来捕获信号。
模拟环境： 在调试时，尝试在与
```
at
```
任务类似的环境下手动执行脚本，例如使用
```
sudo -u your_user /bin/bash -c "your_command_here"
```
来模拟特定用户的非交互式执行。

确保